RoseOnRails – a lot of things


These last days have been difficult and full of work! Since this weekend we have been fully “immersed” in the Python code for the intelligence part of the game on the one hand, and the communication part on the other.

First of all, for what regards the positioning mechanism, as Yan explained, we won’t use any absolute positioning simply because we don’t need it 🙂 Instead, we’ll use magnets that, when detected (by the two latches one in the front and another at the rear of the train), let us update the “position” to “position + 1”, roughly. In other words, it’s no more a matter of detecting the position of the train at all time but rather keep track of its position and time t relative to where it was at time t-1. Fortunately, this conclusion that we have made after discussion with Alexis&Sam has considerably facilitated our task for what regards the positioning mechanism.

The other question was the intelligence architecture which we discussed about with Sam. Yann and Noémie have started coding it, but there are regulary questions that are raised… Today, we’ll continue working on it again and I hope we’ll be able to have a first “draft” done by tonight.

On my part, I dealt with the communication part. Below is a diagram of how I have so far structured the code:


RoseOnRails – Communication scheme

So far, I can manage to have the different threads work as expected, however as long as the interface with the intelligence part is not made.. well it’s pretty useles! Today , I’ll complete the code to put in place the interface with the intelligence module so that we can make some tests.

For what regards the PCBs, due to a “small” hardware problem with the boards, Alexis&Sam spent a lot of time yesterday to solve it on the already soldered PCBs (namely those of the DropsNRoses). Fortunately, it’s now solved and we shall have ours soon. Then we can flash the tests and check that everything works (yes, we believe it will 🙂 !)

Another task we have to do before testing the BLE code is to make our code compatible with the correct SDK version (which is different from the one we have used for our code flashed on the Evaluation Kit so far). I’ll talk about later when we’ll have done it… which means very soon!

See you guys

RoseOnRails – code


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 🙂


RoseOnRails – Python… and ledstrip testing


Today, I continued “playing” a bit with PyCharm trying to get used to Python. Then I wrote a small program that does the client role in a TCP socket connection with my C program where I have implemented the server part. Now I can send the commands through the Python client and see the results on the nrf Eval Kit board (by writing values in the characteristic of an LED in the BLE app running on the nrf).

Unfortunatey, I couldn’t go further in this since we had to test the “pieces” of ledstrip we had soldered. The thing is that this turned out to be waaaay longer and tougher than I thought. In fact, while some ledstrips were perfectly functional (we tested them with a program sending random RGB values to the LEDs in loop, through the stm32f2103’s SPI bus). However, on some others, we observed total random behavior: for instance, some LEDs blinked on the first pieces of the ledstrip, and then the rest of the LEDs were off, or sometimes, all LEDs blinked except one or two! Sometimes, this was due to our soldering (some pieces of wire weren’t well soldered, or sometimes some wires touched…), in which case we resoldered them correctly. But the most disconcerting situtations were those where we had made sure all connections were ok (with the multimeter) but still, some LEDs were off for no obvious reason! Several ideas came into our mind: maybe we had damaged some LEDs in a way that we had changed their electrical characteristics (typically the required voltage for a high state for instance), maybe the voltage drop by the LEDs was too important, in  way that the first LEDs blinked correctly whereas from a certain position on, the voltage was not necessary for the other LEDs to blink anymore, maybe the voltage provided at the SPI output of our mircontroller is too low (3,658 according to our measures with the oscilloscope) compared to what is specififed as the minimum voltage required for a high state for the LEDs…. we discussed about this also with ph and Félix and they gave us some ideas, encouraging us before all to check the voltage drop of the LEDs on some pieces of our ledstrips, as well as check the output voltage of the SPI. It was unfortunaly a bit late (midnight..) to carry out the tests so we will have continue tomorrow. I strongly hope we will solve this “problem” soon, since we have a lot of work to do on the software part too!

See you soon.