RoseOnRails – Going on the led power supply and locomotive PCB

Hi everyone !

Yesterday morning I’ve finished with the rest of the group to put the turnouts PCBs the table of our rails. During, the afternoon I’ve worked on making the UART connection worked between our STM32 and our nRF51822. With Valeh, we’ve made it worked on with Sam eval boards nRF51822 (C0) and the previous year eval board STM32F103(cb). But, it is still not working yet. In spite of the fact, we get the right signal on the track between the TX of our nRF51822 and the RX of our STM32.. See :

I’ve also worked on our Threads with Valeh in order to correct the mistakes. Lot of tests are still to be done on the intelligence. During the night, I continue to solder the power supply of the led with Gleison and Valeh. We’ve finished it in the beginning of the afternoon. As expected some part of our ledstrip were broken and we’ve almost finished to repare it. I’ve solder the power supply on our four locomotive pcb and the connection with the motor. Now, that we’ve finished with the leds : WP_000539

We’re going to solder our hall sensors and test it with the deboucing.

Update :
The train says hello with his leds and is equipped with hall sensors :

RoseOnRails – Going on the turnouts

Hi everyone !

On Wenesday, I started working again on the intelligence Threads (one thread per locomotive and one thread of turnout). I finished it yesterday and I completed the corresponding. I’ve also agreed with Noémie and Valeh in order they complete the database in the way we use it in our threads. I’ve also implemented a first version of the Dijkstra algorithm with each section being a vertex and a valuation taking into account the size of the section, the number of switches used with a ponderation on the fact they are reserved. Then, with Valeh we’ve started to integrate the code. However, Gleison was working alone on our track and putting the pcb turnout under our rails took him a lot of time (drilling, soldering, passing the wires under the table). So, I’ve decided to work on it with him. Unfortunately, the first turnout PCB I put wasn’t advertising well. After a diagnostic we’ve asked Alexis to change the balun and now it works well. Thanks 🙂

Now, I’m going to finish to put the two last turnout pcb under our rails with Valeh.

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 :



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


RoseOnRails – Tests PCB are ready

Hi everyone !

On Wenesday, I didn’t have a lot of time to work. But I worked after my FH courses and after the session of improvisation. I’ve worked on the configuration of our STM32F103 because we realized during the afternoon that it wasn’t possible to use DMA on USART1 and SPI2 at the same time. See DMA tables for our STM32F103DMA_table

Luckily, this problem happens on the board Rose’s students were using last year, so we manage to correct this problem before our LED PCB arrive. Unfortunately, we’ve connected our STM32F103 with our nRF51822 through USART1. So we have the same problem (it doesn’t matter now because we aren’t using DMA for the UART communication). But, I would recommend to everyone who wants to do a communication between a STM32 and another device through UART to have a look at the DMA table first.

Because of this problem, the code I’ve made using ChibiOS wasn’t working because the STM32 couldn’t allocate two times the channel 5 of his DMA1. So, we configure our UART properly. This raise another issue how to handle interruption properly with ChibiOS. We did it on Thursay using a mailboxe and a CH_IRQ_HANDLER. Unfortunately, we made a mistake while configuring the BR register of our UART.

Because in the UART config of ChibiOS, the br field is directly the speed


* @brief Bit rate.
uint32_t speed;

But it was very easily corrected with a “grep -r speed” in ChibiOS files.

/* Baud rate setting.*/
#if defined(STM32F0XX)
if (uartp->usart == USART1)
u->BRR = STM32_USART1CLK / uartp->config->speed;
u->BRR = STM32_PCLK / uartp->config->speed;
#else /* !defined(STM32F0XX) */
if (uartp->usart == USART1)
u->BRR = STM32_PCLK2 / uartp->config->speed;
u->BRR = STM32_PCLK1 / uartp->config->speed;
#endif /* !defined(STM32F0XX) */

Thus because we’re using USART1 on STM32, we just changed our configuration the following way USART1->BRR = STM32_PCLK2 / 38400;

I would recommend you not to read the complicate explanation in the reference manual about how to configure DIV_Mantissa and DIV_Fraction to get the speed you want. Because if you use the ChibiOS macro the formula is easy : STM32_PCLK(clock number for your uart 1 or 2) / speed.

So as explained in Valeh’s post. Our test is now working properly.

On Friday we had our presentation. Then, we looked with Gleison to find an optic detector to enable our train to detect our LEDs. I think they were a confusion in our mind because I remember we said we could abandon using this optic detector if we detect our train position precisely enough. Thus, we didn’t provide any analog entry on the nrf51822 for the optic detector and finding a numerical one wasn’t easy. After some calculations and discussion, we decided to focuse ourself on detecting the train position with hall sensors. As we had decided a few times ago we’re going to use a bar code system (detecting north and south pole of our magnet). It depends on the budget but to get enough precision we should use enough benchmarks. We already have 78 magnets.

If we use barcodes with 6 magnets
Number of magnets necessary : 64*6 =384
Cost = 306*0.18 = 55.08 €
Accuracy : 28/0.64 = 43.75cm
If we use barcodes with 5 magnets
Numbers of magnets necessary : 32*5 = 160
Cost : 82*0.20 = 16.400 €
Accuracy : 28/32.0 = 87,5 cm

After, making this calculation Gleison explained us how the test of the turnout PCB works. Then, we finished the tests for the locomotive PCB including the adc test and the hall sensors test which enables us to receive data from the hall sensors through BLE.
Today, I’m going to look at how to implement our BEMF, improve the way we communicate through BLE with our central station because BlueLib seems to have latency compared to gatttool commands, and look at the implementation of the intelligence of our games.


RoseOnRails – Work leads to some encouraging results

Hi everyone!

Short sum up of my work since Friday night when we divide the work for Monday’s presentation which was finally postponed.

On Saturday, I tried to send gatttool command on my nrf51822 and look through BlueLib example in order to adapt it for my test for the Nordic UART Service. I’ve also spent a lot of time in order to estimate the cost of our products. I compared the price of our components for differents amount of quantity on Farnell and other websites (arrow, future-electronic, avnet-mermec). Then, I looked for similar product than ours on the internet. In order to price our product and to see if our products were some breakthrough on the model railroading market. It was kind of difficult because there are many products with many specifications which make each of them unical.

On Sunday, we meet from 12am till 10pm in order to discusse or Monday presentation and finalize our work. In order to find some arguments to justify our pricing I’ve found in a book this useful summary of the pricing :

“New product pricing difficult and can be made according to policies : shimming pricing and penetration pricing. Five factors are important to look at in setting a price :

– potential and probable demand
– costs of production and selling costs
– markets targets
– promotional strategy
– suitable channels of distribution
But the final decision cannot be arrived at by any given formula : good estimates make pricing more successful combining factors requires judgment.”
Personnally, after some thorough research taking into account these factors, I had applied the rules of 3 Sam talked us about on Monday.
On Monday, I get back to my BLE-UART work I tried to explain my work and my tests to Noémie but I was probably unclear.
On Thursday, I’ve split in several files the main file of the uart service on our nrf51822. Then, I worked with Valeh and Noémie (see Valeh’s post).
(Not finished yet)