RoseOnRails – Annnnnnnnnnnnd …. it rolls!!

See by  yourselves !!

RoseOnRails – Rails are shinning

Hi everyone !

Yesterday, we’ve finished sticking our leds under our rails.

All our rails are now shinning !!!WP_000528
We’re going to add wires around our track in order to supply equally our leds.

Yesterday, Valeh and I have made some tests in order to change the color of our leds via BLE, however we’ve seen they may have a problem with our UART-TX pin (on the nrf51822 side). What we’ve note is that when we toggle another we’ve slot with an amplitude of 3.3V (as expected) but when we toggle the UART-TX one we’ve the same slot but with an amplitude of 0.5V..

We’ve also tried to find the component on our second locomotive PCB which was preventing the advertising. Unfortunately, we didn’t find it on our own and it was the nrf51822’s quartz which wasn’t well soldered.

After Alexis change this problem, we’ve made a very clean wiring on our locomotive PCB, in order to be able to test it on rails and with a generator without desoldering.



We’ve tested our PWM on our track but it seems that our motor isn’t strong enough on the rails. Because for a full duty cycle (however it wasn’t the same voltage) commanded via BLE the locomotive is running on the table but doesn’t run on the track. We’ve even put two rails on the table and this time the locomotive was running  (see Noémie’s video). We’re looking at the acceleration curve in order to solve this problem.

RoseOnRails – Let’s continue

Hi everyone !

As announced in my previous yesterday. We stick our led strips under our rails. It took us lot of time because we made sure our soldering were strong. However, there were another which cost us some time too. I’ll upload a picture very soon, in order for you to understand. We’ve ordered only one kind of led strip however there were two kinds indeed I will call then Majuscule and Minuscule because on one it’s written this way “DIN” “DOUT” while on the other it’s written “Din” “Dout”. The problem is following when a Majuscule kind is followed by a Minuscule kind the first led of the minuscule kind isn’t shinning while the other after her are shinning the proper way (but this doesn’t happen all the time sometimes it works well). But, now our code and solder are clean and strong, just yesterday we identify four times this phenomenon (So that’s not a soldering problem). A few weeks ago , after some measurements with an oscilloscope, we understood the reason of this phenomenon is that the width of the slot signal isn’t the same at the output of a Majuscule kind and a minuscule kind, not a lot but enough to disturb. The unexplain things is that the microprocessor under the first led seems to be able to recognize the “large” width signal and convert it in the Minuscule kind of signal.

You’ve seen Valeh pictures of our work. We’re going to stick the last ledstrip today which is currently properly working and we’ll add a generator because we’re already above 3A and not all the led are shinning equally.


RoseOnRails – a little bit of beauty

Hey hey!

Hot news… and beautiful photos.

ledstrip4 ledstrip7

Well, as you can see, this weekend we spent a lot of time on our ledstrips (once again!). On Friday, Alexis helped us a whole lot by properly soldering connectors to our beloved PCB so that we can easily test our ledstrips by simply connecting and disconnecting the power supply and/or the ledstrip itself. After having prepared the correct boards, we could then test our three SPIs and make sure all worked fine. However, the UART still doesn’t seem to properly work (as a reminder, we use it for the communication between the STM32F103RE and the nRF51822). We hacen’t much ahd the time to see where the problemt might come from yet, due to all we had to do with the ledstrtps.. but we’re going to have a look at it today for sure.

Yesterday, we spent the whole day testing our 22x LED-ledstrips, re-soldering the broken wires, and replacing the defectuous LEDs… It took much longer than we thought and was way more tiring. Once we were (almost..) sure that all was ok, we decided to paste them below the rails, which we did in the afternoon. It’s not fully finished yet. Hopefully, today we’llfinish this and then kindly ask Alexis to help us with the PCB of the loco which seems to have a defectuous capacitor, as well as the PCB of the turnouts that we need to place on the circuit a soon as possible. Then we can test everythig with the little BLE apps we have already prepared, hoping that all’ll work fine 🙂

See you very soon !

RoseOnRails – Almost there

Hi everyone !

On Wenesday morning, I supplement our database with the data I needed in order to update the current position (because we don’t detect an absolute position when we are on a magnet). I’ve also implemented the function in order to update the position, another one to propose to the gamer to change the turnout as he wants when he is near enough of the turnout taking into account the other turnouts after this one. In the middle of the afternoon, we asked Sam some advice about how the previous group who were working on the train were doing. He gives us precious advice which are going to make our work easier. Unfortunately, most of this means erasing all my code but it will probably lead to a better implementation, easier to code and easier to understand. During, the afternoon Alexis with Noémie and Valeh help soldered two of our locomotive PCBs while I was updating (more exactly downgrading our SDK and softdevice) in order they fit the nrf51822 version we have. He takes some times (I’d better working local rather than on the NFS) and Valeh continued this adaptation with me.

On Thursday, morning I finished the adaptation of our old code concerning the use of the uart for our led PCBs and the one for the test turnout. Then, I soldered the wire on our second locmotive PCB. I tested the PWM in order to power the motor with the program Valeh made worked on the first PCB. In the beginning of the afternoon, I wanted to communicate through BLE in order to be able to change his speed. Unfortunately, this PCB wasn’t advertising at all. We made some tests and conclude there should be a soldering problem on it. Noémie has probably identified it yesterday and we’re going to talk about it with Alexis. During, the afternoon we wanted to run our locomotive on the track. But we had shorting (rails are powered with 22V) and we had to postpone it to another day. A bit depressed, I started soldering the ledstrip we had left (we hadn’t wired the strip through the turnouts.

On Friday morning I continued, to solder and we started with Valeh to test these very long led strip. There were bad wiring problems in the output of our spi and transistor. Quentin gives us useful advice to test more properly. Then, Alexis helped us to make our spi output very clean on our new led pcb. There were a lot of problems during the afternoon we tried to solve. I did not see the time passing.. I’ve tried to make most of our soldering stronger and cleaner.

Before leaving yesterday night, we noticed there were a problem with data output of our second spi. This morning, Valeh measured this output with the oscilloscop this morning and doesn’t see any data. Now we’re going to investigate this problem I continue to correct the solderings which broked and those which aren’t clean. In this beginning of afternoon, we’re going to stick our ledstrip under our rails in order they don’t move anymore.

RoseOnRails – PCBs, tests, good news, bad news!

Hello world!

Yesterday, in the morning, we started to do the interfacing between the intelligence module and the commuication module I was in charge of. I changed some things in the architecture (described in the scheme in my prevoious post). I will do another diagram to summarize the new architecture, but I wait a bit so that we can make a little test with the intelligence module first.

Talking of the intelligence module… we discussed about it with Sam on Wednesday and he gave us some very precious advice. Instead of dealing with “position”s, we now rather deal with “section”s of the circuit that the player reserves when he wants to go from one point to another. See Noémie’s post for more info.

On Wednesday, we also soldered our first PCB loco. Noémie and I helped Alexis by giving him the right components. Then Noémie continued and I went back to code in a406 since one person seemed to be enough for this task. I therefore continued what Yann had started namely the adaptation of our programs to the new version of SDK we’re using (4.4.2 instead of 5.1.0). It was mainly a matter of files/folders/paths to change and deal with uncompiling programs for a while… When Noémie came back, we first placed the PCB on the loco and flashed our simple application to command the H-bridge in PWM on it. Well it didn’t work immediately since we had forgotten to comment the use_softdevice line!!

The day after, I re-tested the app without softdevice and the wheels turned (with PWM command) 🙂 Then I flashed another app doing BLE advertising. While discussing with Adèle, she told me they had the same “problem” and that it was necessary to generate an internal low frequencey (32kHz) clock (we already have an external 16MHz clock), which I simply added to the code and initialized the softdevice with. The loco then did advertise and by writing the value of the speed characteristic we could control the speed in PWM.

In the afternoon though, when we wanted to try and supply the loco with our 22V rails, some unfortunate measuring led to our nrf51822 being seriouly damaged 🙁 The other PCB also seems to have a “problem” with the balun. We of course have to test it.. which we’ll do today.

Yesterday night, Yann also soldered the remaining ledstrips and we re-tested them with the stm32f103 SPI.

See you


RoseOnRails – WIP – Locomotion

Hi everyone,

This morning, Yann Valeh and continued working on the intelligence.

This afternoon, we had the occasion to talk about how we were going to model the circuit, the train position and how trains would be able to book a part of the circuit. As Sam has worked at least three times on this circuit in the past, we benefited from his experience on the subject a lot. Whereas we had designed the circuit in a too complex way,Sam proposed to us a simpler, more adaptable and more general model.

Later in the day, I helped Alexis solder components on two of the Locomotives PCBs. It took quite some time but was really rewarding in the end!

In the evening, I installed a PCB in one of the locomotives. After some time testing it, we managed to have the locomotive work… However, it does only work in one direction right now… 20140417_002544

Good night,
Electronically Yours,



RoseOnRails – Threads

Hi everyone,

Two days ago, Valeh ,Yann and I decided to allocate the tasks for the week.
I was assigned with coding the locomotive thread in Python. I had quite a few problems with that as I didn’t know how to communicate with the rest of the code (notably the part which receives the notifications from the BLE). Therefore, I spent quite some time reading docs on how to implement even handlers and interruptions in Python.

Valeh, Yann and I have finally decided that we would tackle the communication later and focus on the content of our threads.

Electronically yours,


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 – WIP

Hi everyone !

Short sum up of my work since Saturday

On Saturday, I look how to implement our BEMF. I already had some useful explanations from Gleison and Valeh were chosing the component in order to use for our motor. But, on Saturday I got a clear picture (See these useful links 1  2  3 on the way we’re going to implement it  (simple implementation in C). I’ve also looked through Valeh’s of our central station to understand how it was implemented. Unfortunately, I had lend my BLE dongle to Gleison. So I couldn’t make any test to improve the code. Luckily he had gave it to Valeh, so I got it back on Sunday and I started trying to improve the way the code was working. On Saturday night, I realized something was wrong with the suggestion made in my previous post to detect the absolute position of the train.

On Sunday, we’ve met with Valeh the whole afternoon in order to discuss the way we think the intelligence of our game is going to be implemented. Unfortunately, the resolution of the problem of the detection of our absolute took us a very long time (like two or three hours) each time coming up with a solution and then realizing it couldn’t work a few minutes later. We were taking into account the following constraints of our hall sensors and the fact that we had magnet (turn either north or south below our rails).

Hall-effect switches are most commonly used in sensing absolute position, because they require a south pole of sufficient strength to turn the output on and then removal of that field to turn the output off. ”

Hall-effect latches are most commonly used in sensing multi-pole ring magnets for motor commutation, because they require a south pole of sufficient strength to turn the output on and a north pole of sufficient strength to turn the output off. ”

Finally, we came up with a solution I tried to explain it on the rose2014 mailing list but it seems it was way to complicate. So, on Monday we’ve decided to abandon the detection of an absolute position (which was a question raised during our Friday presentation) and we’re just going to detect the change of the kind of pole.

Then still on Sunday, we’ve started to define our architecture and I started to code our classes before midnight.

On Monday, we’ve discussed our architecture with Noémie some questions and doubts were raised. We’ve also discussed our solution to detect an absolute position with Alexis and Sam. But as I said, we’ve eventually abandoned this ambition. We had to make some tests in order to be sure that the electro-magnet use to turn the turnouts weren’t disturbing our hall sensors. We’ve seen that their magnetic (active only when we’re turning a turnout) doesn’t disturb our hall sensors on a distance superior to 8mm. So their will be no problem. We’ve also divided our work between Valeh, Noémie and I. I’ve started to implement our database according to our classes.

Today, I’ve finished to enter all the data we need (I hope) in our database and I’m now implementing the serial thread which is going to change the direction of our turnout.

See you soon