Categories

RoseOnRails – WIP

Hello all!

Yesterday and today I “lost” a lot of time dealing with out Hall effect sensors. More precisely, yesterday, I tried to test that the sensors detected the magnets when the latter where put on the table. To do this, I activated BLE notifications that informed the state of the pin (after a pin read) in loop. The sensors where placed in the configuration that you can see in Yann’s post. The result was that they were detected on the table with no problem, but when put under the rails, the value of the pin read was always 0, in short no magnet detection. I then tested the same model of latch (our Hall effect sensors are A1221 latches) with our Nodic Evaluation Kit (in case the problem was due to out PCB) but still obtained the same result.

Since Gleison had previously done some experiences with the Hall sensors (another model though), I asked him some help. He suggested I don’t activate notifications in loop, but rather use an event-driven detection. We searched and found out about app_gpiote event handlers in the Nordic SDK. I then implemented one that after each pin state toggle increments a counter (one for eahc latch). That way, we can know how many latches we detected. This seemed to work well, but still not with the magnets under the rails. The worse was when we switched on the motor: the counter went up to 2xxx without any magnet (in fact, it’s because the sensor detects the magnetic field created by the wire loops around the motor)!!!! Since “the oscilloscope is your friend” is my new rule of ROSE, I suggested we use it to better see what really happens at the pin. Gleison started to do this and I rather switched to another task which was the completion of our Central Station code. Gleison said he obtained very weird results…. yesterday afternoon, he told me that there was an error in the way we had soldered the hall sensors (in fact we had connected the GND and Vcc of our PCB to the rails…!!). This led the nrf to burn when Gleison mistakenly switched GND and Vsupply when supplying the board…. I’m so sad+nervous about this “event” that I don’t really want to talk more about it… now, while waiting that Alexis kindly solders another loco PCB, we can’t do much else 🙁

As I mentioend above, I also completed the code of the Central Station to control the switches, and improved some little things in the code. Yesterday afternoon, since we couldn’t work on our dead PCB anymore, we coded the intelligence part. I completed the code of what I have called the “gateway”, i.e. the interface between the player, the Intelligence module, and the circuit of the train. Now, it seems to be complete. I have implemented the functions to be called by the Intelligence module and compelted the part requiring me to ask the user his choice of section (the section where he wants to move to) through the websocket, and (wait to) receive the answer to transmit it to the Intelligence module. Today (or maybe tomorrow) we might have the time to test the whole code (gateway + Intelligence module).

Yesterday, we also completed the Trello – a useful tool for organizing our tasks until the (very near) end of the project.

Humm, I think I have said everything for now! See you!

RoseOnRails – code

Hi.

This weekend, I continued the Python tutorial and reviewed what I had already learned. We’re all going to badly need Python for the intelligence part of the game.

I also carried out some tests with the code of the central station, since I felt there was a considerable latency in the characteristics being written through my code compared to when I wrote them directly with gatttool. I activated all DEBUG print options in BlueLib and tried to dive as deep as I could in the sources of BlueLib and BlueZ to figure out what was responsible for that latency. Well, (fortunately!!) it was simply due to the fact that I “got primary services” and “got characteristics” each time a user wanted to write a value to a charactertistic of the train. But since we already know the (only) service and the (few) charactersitics that we use, it’s wiser to just stock them in an array at the beginning of the code (when I connect to all of the trains and start the notification) and then simply use the struct that I have stocked in this array to write to the desired characteristc. It’s way faster now! Ouf!

On Sunday, Yann and I started thinking about how to structure the intelligence of the game. But first, we had to determine how, precisely, we were going to detect the position of our locomotive with the magnets on the circuit and believe me, it was much less obvious that we thought! In fact, given that we had seen on Friday that the Hall sensors we currently use, detected only the South pole, we woud have a problem to encode ones and zeroes according to North or South… more simply put, there is South or nothing for the Hall sensor switch we use, so we can’t do any encoding based on the pole of the magnet, as we had thought we could do.

In short, we thought of using a combination of a Hall switch (the one I described above) and a Hall latch (which detects the North pole too). However, there’s still a problem since we won’t know if we have ran over one or N North poles (becuase the switch simply doesn’t detect North and the latch does detect it but it changes state the first time it sees an N after having seen S, and that’s it, it’ll stay to N as long as there’s no S). So, we simply had to do a type of encoding that flipped one bit each time, I mean encodings of type NSNS or SNSN, or SSS, etc. in short no code with two or more consecutive Ns… However, we’re still not fully certain, we have to discuss with Alexis & Sam about it, which I guess we will do today.

As mentioned above, we then started to think about the intelligence itself and how we would implement it in Python (what classes, attributes, modules, how many threads, what type of security for simultaneous access to the shared arrays of LEDs and turnout, etc.). We already have an idea that Yann started to implement last night, however, I won’t describe it here now. I will do so when we will have talked about it to the other members of the group and will agree on the architecture.

Last night, I changed again some things on the code of the central station (added some metadata to the notification in order to know which train notified, parsed commands in Python in order not to have to type MAC address each time but rather the number of the train, etc.).

Hopefully, we will soon have the PCBs with the components soldered and will be able to implement all these codes “for real” and see what happens!

Stay tuned 🙂