The problematics of the locomotive

Hi everyone

As promised in the previous post, some pieces of information about the H-Bridge: we are considering to change our initial choice of the IC A4973 to one simpler and smaller (A4953, A4950). I have not had the time to read the datasheets, but they look quite similar to an A4973, except it does not have a internal PWM. Basically, it is perfect for us.

A couple of things about the locomotive: unfortunately, there are only two white LEDs, one in the front of the locomotive and the other in the rear. That means we cannot simulate the real-life behavior (white/white, red/red, white/red, red/white). At least, it is easier to control, we could even use one GPIO high-drive mode. The following photo illustrates:

LED locomotive


Alexis is getting the library ready with the devices we are going to need. I expect to finish the design and begin the routing process soon.


Work during the past weeks

Long time no see,  huh?

Since I was generally helping Valeh with the subjects related to electronics and preparing myself for the TP/Challenge, it has been a long time anything was posted by me.  So this post will function as a recap of the previous weeks:

Firstly, we have worked with the H-Bridge, it has been extremely painful. If you don’t have a component that integrates all the drivers and sinks for the motor as well as implements a protection circuit, the job is pretty hard. We have started by positioning the drivers and the sinks, we have validated our design by running a simple simulation of our motor with the transistors. Obviously, it is not that simple.

Motors are quite nasty when you change their current quite quickly and that is basically what happens when you control it with a PWM. So you place some Schottky diodes in parallel to the transistor and it works, right? Yeah, for sure it protects your H-Bridge, but what about the noise that goes through your power supply to other devices? Worse, if you need to measure the BEMF, this voltage peak may damage your ADC.

So we have placed a RC filter in addition to a Zener diode. In this manner, the signal that goes to the ADC is smoothed and limited.  Problem: what is the cutoff frequency of the RC network, what is the amplitude of our signal in the input resistance of the ADC?

Our tests showed the resistance peak power was about 2W during the switching process. We have looked the Zener diode datasheet and a 100W non-repetitive peak power during 0.1ms is listed in its maximum ratings. That is largely sufficient, no? NOOOO!!! You can still damage your diode by creating an arc between its terminals. And our harmless 8V added to the BEMF may exceed its maximum ratings. Solution: resistance in series to limit the voltage.

Finally, Alexis has wisely pointed out that our idea for controlling the drivers and sinks poses a great danger to our circuit. If a driver and a sink from the same side are turned on simultaneously, we have just lost our transistors. We could place a NOT gate for making sure they do not go on at the same time, but all the work to downsize the H-Bridge would be lost. Well, we have decided to use a H-Bridge IC.

BEMF sensing, it seems easy, right? We just place a voltmeter between the two terminals of our motor and it is done. Try doing that with a uC …  The voltage can be either positive or negative, and the nRF ADC does not work well with that.  The measurement is differential, the nRF ADC does not support differential inputs. The maximum input voltage of the nRF ADC is 1.2V, and our motor runs with 15V. Many ideas of how to reduce the amplitude, convert it to single ended, shift the voltage to make it positive … Thanks to the documents Alexis has provided, we found an interesting solution: a resistance connected to the ground that estimates the current through the motor . If our PWM is fast enough, we take total voltage applied,  subtract from it the motor internal voltage, and we have just obtained the BEMF.

As I am currently designing the PCBs for our project, we are still working on the H-Bridge IC we have chosen. As it is quite difficult to find simple 15V rated H-Bridges, we are working with one fairly complicated (A4973). It has an internal PWM which we probably won’t use. News in the following posts.


RoseOnRails – a lot of things!

Hi all.

These last days have been difficult! I think this week we have worked on our project more than we have ever done since the beginning of ROSE! Yesterday night was one of the most exciting ones in my life (I’m not exaggertaing :p!) We managed to test our LED stripes, drill a piece of our railraod and put the stripe underneath… the result is a three times more beautiful railroad!! I’m so happy the stripes fit perfectly in the space below the railroad, although we’re still wondering how to manage the curves on the circuit….

On my part, I have started to think about our Software Architecture. I have therefore read about BlueZ, hcitool, gatttool and so on, to find out how to program the application that will be run on the Central Station. Then after discussing with Alexis on Tuesday, I temporarily switched to a more important question, namely how to manage the nrf51822 chips on the train and on the railroad switches (from a software viewpoint), above all the question whether or not we need an OS on our chip? Given that the SoftDevice BLE stack generates interrruptions on its own, it most probabaly wouldn’t be compatible with an OS running on the chip. If we absolutely need an OS then we should consider adding another microcontroller at the output of the nrf…. So I started to see what software mecanisms we need to implement on the train, and in fact apart from the PWM (for the motor and the lights on the train) there is nothing more (of course apart from the BLE app that will be managed by the SoftDevce). Good news : there aren’t PWM channels on the nrf!! Soooooo, last night Sam put me on the right track talking about the PPI, and the Task&Event mecanism. Therefore, I read a whole lot about all this, as well as GPIOTE modules and how to use them to “simulate” a PWM, by using a Timer peripheral in Compare mode and a GPIOTE controlling the GPIO that we want to PWM-control. I also found (once again after being put on the right track by Sam 😉 !) an example implemantation of a three channel PWM on the nrf on this very helpful website and dived into the code to understand what it does. Today, I will try to use it on our Evaluation Kit just to better understand how it works and then determine precisely whether or not we can be sure to be able to manage the train and the railraod switches in bare metal.

I wanted to talk about the motor as well because there has been a rather big change in our conception of the system -> we will no longer be using a “hand-made” H-bridge but rather a standalone H-bridge. After disussung with Alexis, we found out that with the previous model we had suggested, chances were high that there might be a shirtcircuit! So last night, Gleison and I found a model of an H-bridge (previsously suggested by Alexis to another group)… but it’s a bit more complicated than what we thought, to use it.. I didn’t have the time to have a closer look at it last night since I was busy datasheet-reading for the nrf, but hopefully today I will try and study that part a bit more.. we also need to determine what RC filter and what Zener diod we will be putting before the ADC input.

Today, it’s the Iranian new year I will go further in discovering how to use the nrf in bare metal mode for our application.. and if time there is (I have a porject to do for my ATHENS week in parallel :\ !!) to determine how to control the H-bridge and the components for our RC filter and Zener diod.

We’ll keep you posted 🙂 !


RoseOnRails – final steps before the PCB of the locomotive

Hi all.

Today, we finally had the opportunity to talk to our teachers Alexis and Sam about our solution for the implementation of the H-bridge and the BEMF measurement circuit for the motor (of the locomotive). Below are the three solutions we have tackled with so far. Today, after discussion with Alexis and Sam, we finally decided that “the current measurement” method is the most efficient one. The amplifier-based method is definitely too much complicated (further, and OA is often big and expensive…). The method with the 3 transistors works, but is still more complicated than the method using simple current measurement, namely the method have retained. The most interesting about this technique is that it doesn’t require to stop the motor! We can thus measure the BEMF while the motor is running!

circuit_moteur_loco_sol1 circuit_moteur_loco_sol2circuit_moteur_loco_sol3_3

Implementation 1 (OA)            Implementation 2 (3 transistors)      Implementation 3 (current measurement)

At this stage, we know how to control the motor. We have also found the references for the components we need to implement this circuit. The next step is to make the layout of the PCB… surely tomorrow!

Regarding the STM32 lab session, well I worked on the serial over usb connection today, but very little… mostly because I wanted to take the time to discover the BLE kits we received on Friday. So, I installed the necessary programs and flashed some demo codes. For now, I’m stuck with minicom configuration… I’ll have a closer look at it tomorrow.


BEMF, amplifier, H bridge, ADC and so on..

Hi all.

Tiring day, very tiring indeed! This morning: ADC, ADC, ADC. I re-read the datasheet of our STM32 board and saw some examples of code. Then I implemented my own code which… doesn’t fully work yet… but it sure will very soon 🙂

The rest of the day up until now, Gleison and I spent time thinking about the 12V DC motor in our locomotive. The more we thought and the more we raised questions and potential problems. Fortunately, we managed to find solutions to almost all of the questions we encountered. I’m not positng them here since we’re not fully sure yet. I’ll work on it again tomorrow and put some order in all we did today. We’d also like to discuss this with Alexis and Sam before going too far!

That’s about it for today!