RoseOnRails – Day minus four

Hi everyone,

Even though I have not posted on the blog for quit  along time, I have not been idle ….

Over the past few days, I have worked on several issues:

– tyding up the repository
– installing the alimentation for the LEDs
– migrated the sockets which are used to communicate between the BLE and the python part of the central station from c to node.js
– updated the sections and LEDs database

Two days ago, our demo didn’t work because our locomotives didn’t receive any notifications.nommunication Even thought the notifications worked with gatttool, they didn’t work with our intelligence. While discussing with Alexis&Sam we supposed our problem came from bluelib. As we are the only group – and probably the only people in the world – using bluelib right now, we had no way of checking if this was truly the problem.

We have just discovered a bug in our code …. there is probably a problem in the communication between the TCP server written in C and the TCP client in python. The messages don’t seem to be well parsed.

As we still don’t know if the bug in our system comes from the parsing of messages in our TCP sockets or from bluelib. We are going to try and debug in parallel.
I am in charge of continuing with node.js asValeh wil come back on the parsing of messages written in C.

Electronically yours,

RoseOnRails – Annnnnnnnnnnnd …. it rolls!!

See by  yourselves !!

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 – Last week

Hi everyone,

Last week, I mainly worked on the ADC on nrf51822.
Indeed, if we want to measure the BEMF of the locomotives’ motors, we will need the ADC to convert the voltage coming from the motor into a numeral signal. I spent quite some time reading docs on nrf51822’s ADC and understanding and adapting examples. Finally, Yann and Valeh managed to have the adc work on the nrf … apparently I had forgotten to mention the reference we were to use.

As Valeh explained earlier, we had to present our project on Friday. The presentation tackled both technical and commercial points.
From a commercial point of view, we are willing to sell two main products:
1. The BLE decoders for locomotives and railway switches. This part is quite innovative as it will be the first time model trains and railway will be controlled thank to BLE and not DCC.
2. The railway portions we have equipped with controllable LEDs. TAs this product will be used in our game and will obviously not represent reality,  it is to be sold to families and children rather more than to modelists and train amateurs.

We were also able to present what e had done from a technical point of view, and what were still to be done.

Subsequently to the presentation and Alexis&Sam’s feedback, we took some decisions and realised some points were to be tackled asap:
1. Regarding the train’s position, as we have not found a specific optical sensor for the trains, and we have focused more on the hall effect sensors, we have made up our minds to use hall effect sensors only.
2. We need to start coding our game

Our programme for the next days:
1. Find a suitable way to set position references in our circuit thank to magnets. – WIP
2. Precisely design our game – WIP
3.  Install the PCBs we received in the locomotives, under the LEDs, under the railway switches – ASAP
4. Finish soldering the LEDs – As soon as the controller is installed and tested.

Electronically yours,


RoseOnRails – Using the drill

Hi all,

After Yann, Valeh and I finished soldering the rail bends LEDs strips yesterday, we tackled the rails drilling.
We borrowed Telecom Robotics’ drill and got down to  work.

Here is a pic of Yann drilling … We drilled more than on hundred rails sections with 5 holes per section on average.


This operation was not easy to achieve, as we needed to drill holes precisely on the LEDs positions.
Hopefully, we will finish drilling and start setting the train circuit again today.

Electronically yours,


RoseOnRails – Railway worker mode ON !


Yesterday after I finished routing the components on our LEDs PCB, Yann and I decided it was time to take the railway to pieces in order to put the LEDs.
Here is a few pics of the roadworks:
Raiway worker

We will pierce the rails sections, put the LEDs strips under them and build the train circuit all over again on Sunday!
We’ll keep you posted.

Electronically your,


RoseOnRails – PCB night!

Hi all,

Yesterday night I worked on the PCB for the LEDs.
Alexis had told us that regarding PCB conception, placing the components should take 90% of the time while routing should only take 10%… After several trials, I figured out that the more time I took on placing the components, the easier the routing was. So much so that after several hours, I finally had an easy-to-route PCB … and went to bed.

Alexis had the time to look at my work in the night, and it appears that I had quite a few problems regarding the balun and antenna placement and routing. I reviewed all the product specifications this morning and discovered that I had to completely modify the placement of half my components. After two hours I finally managed to place and route my components in a simingly appropriate way. I merely hope that no new issue will arise this morning, and wish to be able to send the plans this afternoon.

Electronically yours,


RoseOnRails – WIP LEDs strips

Hi everyone,

Yesterday afternoon and yesterday night, Valeh and I worked on the LEDs strip controller.
We wrote a programme on our STM32 development board, in order to control the LEDs. For some time, I thought that we would control the LEDs thank to SPI and DMA, but after having discussed with Samuel, It appears that it will be much more convenient for us to control our LEDs thank to a timer.

Yesterday afternoon, Valeh and I firstly tried to control our LEDs thank to a simple bit banging programme. This did kind of work, but some LEDs blinked in a strange manner, which made us believe we had a timing problem. We then decided to light the LEDs thank to a timer – as Samuel had told us to do – in order to have a quite precise timing. We have thus written  a programme using ChibiOS GPT (General Purpose Timer) Driver, which enables us to call a  callback every N cycle.
We are now using a 168MHz timer (corresponding to  our microcontroller’s frequency) which calls a callback every 67 cycle (i.e. every 0.4us). So that every 0.4us we can choose to set or clear the Ledstrip GPIO. This method will enable us to code 0 or 1 bits for the WS2812b.

Debugging in progress ….

RoseOnRails – Oh My Doc!

Hi everyone,

In the past few days I have tried coding something to control a LEDs strip….. by coding, I mean reading one million pages of doc for one line of code written.

For instance, in order to configure the SPI baud rate, I had to read a ludicrous amount of pages in the doc … only to find out that the default baud rate was the one I needed and had nothing to change in my code.

According to my calculation, I indeed needed a 20MHz frequence and the SPI on my development board was already configured at 21MHz … By the way, according to the precision required for the LEDs timing in the ws2812b doc, this 1MHz difference between the frequency we needed and the frequency we obtained shouldn’t have any negative impact on the functionning of our LEDs strips.

My SPI and DMA are now well configured and I hope to be able to light the LEDs really soon now even if that means reading one million more doc pages 🙂