RoseOnRails -WIP

Hi everyone !

Today, during the morning, I worked on detecting the magnet with the hall sensors we’ve soldered yesterday. I’ve also Th soldered in some wired on the turnout PCB in order to test it. Then I’ve tried the new patch for the UART connection between our nRF51822 and our STM32F103RE. During the TH of the afternoon we made a Trello, it took us way more time than expected. Then, I tried to identify the origin of the problem on our UART connection, unfortunately my minicom doesn’t print the right characters (I’ve checked all the parameters I put in our STM32 serial port and made it correspond to my minocom parameters..). I measured with the oscilloscop what was at the output of the new pin we use when I toggle it. I obtained the same signal (slot with amplitude 0.5V instead of 3.3V..) that we got with the previous pin we were using for our UART-TX. Maybe we’re going to soldered another LED PCB.

Tonight I’ve worked again on the hall sensor but with Valeh, but we’ve noted that the motor was interfering with the hall sensor when we put it under the motor. And when we put it at the extremity of our train it’s too high. Moreover the hall sensor must be right above the magnet in order to hope a detection from around 1cm of the magnet. We’ve reached a catch 22 situation and asked Gleison what he thinks about it. Because more than two people on this task wasn’t productive, I’ve exchanged of task with him, continued solder the wire on our PCB and tested it with the rails powered. It worked perfectly.

Let’s see the music :



LEDzep – Viderose

Hi all,

Friday we eventually managed to fix most of our issues, which allowed us to have a working prototype with a very rudimentary control system, even though it was a first draft it was rather cool 😀

Saturday I spent all day (and night) soldering with Alexis and Daniel, and was rather happy to discover that I was able to solder 0402 components (even there was a lot of free space around the components), we now have our 10 PCB soldered !

Later I tried to improve the barometer measurements, as they were not very good …

I also helped Daniel adapt the Invensense library for the mpu9150 for ChibiOS and STM32.

From now I will spend all my time on improving the altitude measurement and flight control until I consider they are good enough 😉

LED strip, turnout PCB

Long time no see, hein?

Initially we thought the LED strips would be a piece of cake, it is just a matter to weld everything together and it should work, right? NOOOOOOOOOOO, and that’s a huge no. We spent lots of time making things work. We had all sorts of problems, some with the connection itself, wires that were too fragile, strips which had tracks physically damaged. For the software, we had a problem with the SPI, which according to the LED’s datasheet was irrelevant, but it was not. For the electronics, we had two types of strips and the incompatibility between them was not documented. Nightmares, days spent to debug all the problems we had.

Consequently, our turnout PCB software PSSC had to be postponed, and worse, we had a very short deadline to code it. Well, I finished it one week ago and we have just received the PCBs, hopefully we will get them working today. The code is basic and based in an example, but I spent sometime getting familiar with the code, specially commands related to the BLE stack. Additionally, the drivers are protected from overheating by a sequential switching with a cool down sleep.


Open quiz !

Today, following Allegrem’s tradition, here a musical quiz on our students projects. Will you recognize to which project each following hit belongs ?

Warning : to make things a tiny little bit harder, some lyrics may have sightly changed…
2nd Warning : to make things even harder, some project might have two songs ! Or none.

1. Je ne veux pas travailler
Je ne veux pas déjeuner
Je veux seulement oublier
Et puis je fume


2. What you want, what you make,
Everybody knows it’s only what you take
And now what you see, and what you hear,
When it comes around again it’s not gonna be the same thing
Because you’re gonna say yes, and they’re gonna say no
And everybody’s gonna talk, and talk,
And bla bla everywhere you go…


3. Volare,
Oh oh,
Oh oh oh oh oh


4. At first I was afraid I was petrified
Kept thinking I could never live with this damn project by my side
But then I spent so many nights
Thinking how I did things wrong
And I grew strong
And I learned how to get along

And now I’m back, from hacker space
I just walked in to find you here with that sad look upon your face
I should have changed that solder bond
I should have had far more concern,
If I had known for just one second
That else I’d make ev’rything burn


5. And so how am I ever to know?
You only tell me
Perhaps, perhaps, perhaps.
A million times I ask you,
And then I ask you over again.
You only answer
Perhaps, perhaps, perhaps…


6. Ground Control to Major Tom
Commencing countdown,
Engines on
Check ignition
And may God’s love be with you
[Ten, Nine, Eight, Seven, Six, Five, Four, Three, Two, One, Liftoff]


7. F… you, I won’t do what you tell me
F… you, I won’t do what you tell me
F… you, I won’t do what you tell me
F… you, I won’t do what you tell me
F… you, I won’t do what you tell me

First to give the good answer wins a bottle of Champagne (to drink with moderation of course !). One answer per person (IP logged), real name mandatory 🙂
Leave response in the comments below.

RoseOnRails – the train is on!

Hi all.

Well as you have seen in my teammates’ posts, a whole lot of thigns have been going on lately in our project: the LEDs are shining everywhere in the circuit now, and the little loco is running 🙂

As Yann explained, yesterday, we finished to complete the circuit with LEDs and tried to command them through BLE, which we unfortunately didn’t manage to achieve, since the UART communication betweeen our nRF and our STM32 failed to work. It might be because of an error in the pin decalarations in the board.h file (which would lead to the nRF TX pin connected to the STM32 TX pin, both configured as output!) The thing is that now when we measure the TX pin on the nRF we have an anormally low amplitude (0.5V when the pin is set). According to Alexis, this is very probably due either to a shirt circuit between this pin and GND (which I verified wasn’t the case) either the nRF’s internal P transistor which is damaged, which we therefore think is the case. In short, we decided to use another pin for the TX on the nRF (since on the nRF we can choose the pin we want to use for TX and RX, contrary to the STM32 where it’s imposed by hardware). The nRF RX pin got damaged too but it doesn’ matter because we only use TX (nRF) -> RX (STM32). So Alexis kindly soldered 2 other nRF pins (too smal to be soldered invidually) to the RX pin on the STM32. We still have to test it but haven’t had the time this afternoon.

This afternoon, we also dealt with the “problem” of the motor on the locomotive. More precisely, we noticed that the motor couldn’t start up when directly supplied wuith 22V (which is the voltage of the rails). However, when supplied with 10V then progressivley up to 21V, the motor did continue to turn. We tried to “simulate” this progressiveness with progressively rising our PWM’s duty-cyle, but still, the motor didn’t want to work. We then thought it might come from the OCP (Over Current Protection) of our HBridge which might just deactivate the output when the current drawn was above 3.5A. But, when trying to verify this with the oscilloscope, we found out that the soldering of the motor’s wires on the PCB was far from being perfect, which led to the motor randomly stop working when tilted to one side for instance…!! In short, after having discussed with PHH and Olivier and having read the datasheet of the HBridge, still without any rational explanation, we went to see “doctor Alexis” who “cured” our loco by replacing the HBridge (which was damaged because of an over current and a lack of decoupling capacitor) and adding another decouplig capacitor to the power supply pin. Furthermore, he advised us not to supply the rails with 22V any more but rather with a maximum of 15-18V. After having done all this, we now manage to control the motor thourgh BLE. See Noémie’s post for the fabulous video 🙂 or rather, come see us in a406 for the stunning live demo (@Sam)

Next step(s) -> Test the Hall captors (we soldered them tonight on the loco), test the turnout PCBs (Alexis kindly finished to solder them all 5 today), control everything in BLE.

Then of course, we have to finish the intelligence code for the game…

See you very soon!


RoseOnRails – The locomotive runs !!!

Hi everyone !!

Excellent news today our PCB locomotive runs on the track. With Valeh this morning we’ve made some tests changing the duty cycle of our PWM, increasing it slowly but the motor didn’t wanted to turn. We’ve measured the voltage which was going in our motor the difference between the two outputs of our bridge. We’ve read the datasheet of our  H bridge. If they were peak of intensity, the output then would be disabled. But it wasn’t the only problem. We’ve seen weird thing, we asked PHH some help, same conclusion… Then Alexis looked at it more precisely and our H bridge was dead. He changed it and add a decoupling capacitor that we had forgotten. Indeed the one we had put wasn’t active in case of high intensity because there is a diode and the H bridge and the decoupling capacitor we had put.

Yesterday, after measuring the voltage when we were toggling the pin we were going to use for our the UART-TX of our nRF51822 (we measured only 0.5V of amplitude). We conclude the P-transistor could be dead and we asked Alexis to patch our PCB  by connecting an other pin (indeed two because nRF51822 are very small) on the track to the pin UART1-RX of our STM32F103RE.

Then we change the way our rails were powered because Alexis warned us not to use more than 15-18V. So we tried to put a safe connection trying to prevent short cut. As you’ve seen in Noémie’s post our train runs on the track. The record is 10 laps !! But even with our cautiousness this when our train derailled on a turnout he litterraly tooked fired.

Tonight, I soldered with Valeh our hall sensors on our locomotive. I hope we’ve made it strong and clean. Let’s see our mouse 🙂


RoseOnRails – Annnnnnnnnnnnd …. it rolls!!

See by  yourselves !!

LEDzep – mpu and shell


These days I worked especially on our motion tracking device. We use the nine-axis MPU-9150 that can measure gyro, accelerometer and compass datas. The range we have chosen has a characteristic, it embeds a digital motion processor. By accessing to its registers, we can retrieve measures that have already been filtered and analyzed. I decided to use the motion driver SDK provided by Invensence, the manufacturer.

The code now, recover a FIFO on which the measures filtered by the DMP processor are set to the string. A callback is also called each time the DMP detect a collision and the function send back the direction from which came the collision and the number of these impacts. It will be very usefull because we will be capable after a collision to round and drove off in the opposite direction. We should now work on the i2c communication functions that must be defined for the Invensence platform.

We will soon need a quick data return for altitude and direction servo-control. We purposely left an uart output on our PCB. So i used it in order to implement a small shell in order to have first the mpu data returns.

We also finished the other evening the assembly of PCBs. They have been tested today and connections are all good 🙂

LEDzep - PCBs













Finaly I also Worked on the architecture of the futur android App. I made a first mock-up in order to think about what it might look like and to help to encode faster once we will have tested all the android features.

here is the link.

If you want to see what happens directly on your smartphone, you can download the app “Fluid Player” and flash the following code:

LEDzep - flash code



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.

Plume – Working on the control part of the receiver software

Hi readers !

This last week, I worked on the core of the receiver software : the control part. I had to answer these questions :

How will the data be processed on the mini-DSP of the codec we choose?

We chose to multiply our signal by a cosine on one hand and by a sine on the other, each at the frequency of the signal (19kHz) and send the results, after a lowpass filtering, on the left and right output channels of our codec. That way, we bring our signal back in baseband and thanks to the 90° phase shift, we will be able to compute the amplitude of our signal and follow the evolution of its phase.

How will we synchronize with the emitter on start-up?

Let me remind you that our emitter has a four steps periodic operation : it emits on one coil, then on another, then on the last one, and then stops for a time. All of these steps have the same duration.

So to find the correct synchronization, what we have to do is simple in theory, we wait for the signal we measure to be small enough to consider we have no emission, then we wait to sense something to consider the first coil has started emitting.

How will we keep this synchronization through the time?

Though quartz oscillators are rather precise, but at a 192kHz audio sampling rate, the synchronization might shift of one audio sample every 0.4 s if we don’t fix it on a regular basis. But as we compute the phase of our signal at each measure, we can use it very easily to fix this synchronization.

For example, let’s suppose the clock of our emitter is a little faster than the one of our receiver, instead of sensing a 19000Hz signal, we will have a 19000.001Hz signal, therefore instead of having constant values on the left and right output channels of our codec, we will have a cosine and a sine at 0.001Hz. by measuring the phase of this output, we will be able to compute on each measure cycle the corresponding phase shift to fix it, by skipping an audio sample for example.

How should I organize and trigger the different steps I have to do on each emission cycle?

For each emitting coil, we have three steps:

  • at the beginning, we need to set the amplification at the lowest
  • after some time, we make one low-accuracy measure to compute the perfect amplification setting and send this setting
  • at the end, we process our samples to get our measures

We will receive the values from our codecs through I2S and use a DMA controller to record them on two buffers synced on an emission period, so that one address will always correspond to the same time of an emission, that way it will be really easy to access the samples we need.

To trigger our different steps, we will use a PWM and callbacks.

How will we transmit all of our values?

The problem with bluetooth low energy is that it can only transmit 20 bytes packets. Considering the rate at which we will transmit, we might not be able to transmit more than one packet for each measure, therefore we need to compress the 9 values on 32bits we had to a smaller size.To do this, I decided to send the 9 values with a 16 bits precision, and one single bit-shift indicator to use on everyone of them. As the 9 values should always be on the same order of magnitude, we shouldn’t be losing in precision doing that.


I already have written the code to execute all of that, but as Guénolé told in a previous message, we haven’t received our PCB yet, so I may not test all of this before Tuesday. I am really looking forward to testing the software on the real board, but I am afraid of the time it will take to debug everything ! We’ll see that soon !


See you !