Pi = DCC for model railways?

[SiriusHardware]

I have more nerdy interests than I care to recall, and among those I have a passing interest in model railways.

I note that for some time now there have been systems around in which power is permanently applied to the track and the trains individually controlled by digital signals transmitted along the track, presumably superimposed on the power, to local controllers inside them.

This system is collectively known as 'DCC'.

I'm wondering just how standardised (if at all) the physical data transmission method and the data protocol are - is each one unique to a manufacturer, or is there a more or less cross-industry standard now? It strikes me that the Pi would make a great DCC master controller with the addition of a suitable data-over-power interface to the track.

[rpdom]

I believe a few people have been working on this and may have been some success.

Searching the forums for "model railway dcc" seems to get a number of hits.

[aTao]

DCC is the name of one of a handfull of standard systems, Google will help with finding them. I believe that DCC is one of, if not the most prolific.
So DCC has a well defined protocol and electrical specification.

DCC uses an a.c. square wave at +/- 12v. The data is encoded in the mark/space ratio of that square wave.
The RPi can generate a signal suitable to directly input to a motor drive bridge that can power the track.
Or the RPi can communicate with one ot the many DCC controllers that have USB input
Or you can use the RPi to instruct a microcontroller (Arduino for example) to then drive the motor drive bridge. (An unnecessary indirection if you ask me)

DCC specification can be found here: http://www.nmra.org/standards/DCC/stand ... CStds.html

[SiriusHardware]

I believe a few people have been working on this and may have been some success.

Searching the forums for "model railway dcc" seems to get a number of hits.

Ah! Thank you for that. I did try searching but I made the mistake of searching only this (interfacing) forum.

At least some of those posters were talking about computer controlling an already complete working DCC system which has a computer control input option on the control head unit. That's the sensible approach if you already have hardware DCC working. I'd like to go at it the cheap way, buy a loco decoder - I don't even own any model locos at his point - and try to generate the necessary signals (via a hardware power output stage) to control a motor and other on-off devices connected to the decoder.

[SiriusHardware]

DCC is the name of one of a handfull of standard systems, Google will help with finding them. I believe that DCC is one of, if not the most prolific.
So DCC has a well defined protocol and electrical specification.

Thanks for clearing that up - I had been under the impression that 'DCC' was an overall umbrella name for all of the various digital model railway control standards, not just one of them. When I do eventually get around to acquiring a DCC-equipped model, it will most likely be an 'N' scale model made by Farish, who appear to be owned by Bachmann now- I'm assuming that they will use a common DCC system, and that it is DCC and not one of the other standards.

DCC uses an a.c. square wave at +/- 12v. The data is encoded in the mark/space ratio of that square wave.

One of my other nerdy interests is radio, especially short-wave. My immediate reaction to the information above is: That must generate a hell of a lot of radio interference.

The RPi can generate a signal suitable to directly input to a motor drive bridge that can power the track.
Or you can use the RPi to instruct a microcontroller (Arduino for example) to then drive the motor drive bridge. (An unnecessary indirection if you ask me)

My instinct is to want to use the Pi, plus the minimum necessary amount of additional hardware: Essentially, nothing more than a power amplifier which takes the 0V/3V data output range of the Pi and turns it into +12V/-12V. However, I note from the info you pointed me to that the timing is pretty tight: A 'one' bit has an acceptable on - off time period of 58uS plus or minus only about 5uS. If you were generating the code directly from the Pi while at the same time reading user input and generating onscreen graphics, time wobbles introduced by Linux system events could easily knock the timing out of the acceptable tolerance range - so for that reason, it might well be best to use an 8-bit parallel interface from the Pi to shunt 3-4 bytes at a time to a microcontroller dedicated to the job of generating the actual control pulse train.

[PaulCheffus]

DCC uses an a.c. square wave at +/- 12v. The data is encoded in the mark/space ratio of that square wave.

One of my other nerdy interests is radio, especially short-wave. My immediate reaction to the information above is: That must generate a hell of a lot of radio interference.

Hi

Not had an issue in the eight years I have been using DCC but then I don't tend to use short wave radio.

Cheers

Paul

[aTao]

I note from the info you pointed me to that the timing is pretty tight: A 'one' bit has an acceptable on - off time period of 58uS plus or minus only about 5uS. If you were generating the code directly from the Pi while at the same time reading user input and generating onscreen graphics, time wobbles introduced by Linux system events could easily knock the timing out of the acceptable tolerance range - so for that reason, it might well be best to use an 8-bit parallel interface from the Pi to shunt 3-4 bytes at a time to a microcontroller dedicated to the job of generating the actual control pulse train.

Ah ha! heres the good bit (theres always a good bit, especially in the RPi)
The PWM outputs can be configured to pump out a bit stream that is stored in memory and delivered to the PWM by DMA. So.... this is what you do (any old coders recognise the quote?).

lets say you need 60uS low, 60uS high, 100uS low, 100uS high....
write a bit stream into memory of 0,0,0,1,1,1,0,0,0,0,0,1,1,1,1 and set the PWM to clock it out at 1 bit per 20uS. Job done.
Now then the DCC standard recommends that instructions are repeated, DMA is controlled by DMA blocks which have as part of the block a "next control block" address. If you make a loop with these control blocks the PWM will repeat the instructions (to the locos). Your user interface will take speed instructions, compile the bit stream and then switch the DMA controller to use the new set of DMA control blocks. Its going to be fast enough to be responsive to the user and there is no problem with signal timing, the PWM gets its clock from the system oscillator (not software) and the DMA is set up to maintain the required data.
I have only had a look at the method, not written any code, but those parts of the RPI hardware have been designed to be able to do this stuff.

[SiriusHardware]

I note from the info you pointed me to that the timing is pretty tight: A 'one' bit has an acceptable on - off time period of 58uS plus or minus only about 5uS. If you were generating the code directly from the Pi while at the same time reading user input and generating onscreen graphics, time wobbles introduced by Linux system events could easily knock the timing out of the acceptable tolerance range - so for that reason, it might well be best to use an 8-bit parallel interface from the Pi to shunt 3-4 bytes at a time to a microcontroller dedicated to the job of generating the actual control pulse train.

Ah ha! heres the good bit (theres always a good bit, especially in the RPi)
The PWM outputs can be configured to pump out a bit stream that is stored in memory and delivered to the PWM by DMA. So.... this is what you do (any old coders recognise the quote?).

lets say you need 60uS low, 60uS high, 100uS low, 100uS high....
write a bit stream into memory of 0,0,0,1,1,1,0,0,0,0,0,1,1,1,1 and set the PWM to clock it out at 1 bit per 20uS. Job done.
Now then the DCC standard recommends that instructions are repeated, DMA is controlled by DMA blocks which have as part of the block a "next control block" address. If you make a loop with these control blocks the PWM will repeat the instructions (to the locos). Your user interface will take speed instructions, compile the bit stream and then switch the DMA controller to use the new set of DMA control blocks. Its going to be fast enough to be responsive to the user and there is no problem with signal timing, the PWM gets its clock from the system oscillator (not software) and the DMA is set up to maintain the required data.
I have only had a look at the method, not written any code, but those parts of the RPI hardware have been designed to be able to do this stuff.

I understand the principle you're explaining - you explained it very well, to the extent that I realised you accidentally missed out the final '1' in your data example - I would know how to do it with a microcontroller like a PIC, but that is much deeper than anything I've attempted on the Pi so far. Does Python have the sort of libraries which would give me access to low level hardware functions like that? Or would I need to drop to 'C' or even assembler for that sort of work?

In the meantime, I've been looking around at DCC decoders and Bachmann (among others) do a small one for less than 20 GBP, so it wouldn't be too much to lay out for one to play with. For initial experiments it might even be possible to use a MAX3232 as the output level changer, using two LEDs in parallel (in opposite directions) as the 'motor' load on the decoder. The incidental data inversion done by the MAX3232 doesn't matter, as the decoder has to cope with the fact that the loco may be placed on the track facing either way: Therefore the data can be transmitted right way up or upside down: The decoder doesn't care.

[aTao]

I believe that there is a c library for Python to access the GPIO via WiringPi. (Im not into Python [yet])
I think it would be worth having a look at the c code (apart from the initial set up it is very straight forward), combined with the Broadcom documentation of the GPIO system http://www.raspberrypi.org/wp-content/u ... herals.pdf
If you can follow how the GPIO pins are accessed then you should be able to do something similar for the PWM and DMA (the info is all there).

I am currently writing some JNI so Java can have a fair crack at the RPi peripherals.

[aTao]

For the main power output I think http://www.ti.com/product/drv8432 looks pretty good, 7A rms out, 12A peak, good for a 70W controller.

[SiriusHardware]

For the main power output I think http://www.ti.com/product/drv8432 looks pretty good, 7A rms out, 12A peak, good for a 70W controller.

It does look good functionally, the only snag with it really is the fact that it only seems to be available in fairly fine-pitched surface-mount packages - I'd probably opt for an older device still available in a conventionally leaded SIL 'power slab' package - something I can shove into a bit of stripboard and bolt a heatsink to, basically.

[BrianW]

My instinct is to want to use the Pi, plus the minimum necessary amount of additional hardware: Essentially, nothing more than a power amplifier which takes the 0V/3V data output range of the Pi and turns it into +12V/-12V. However, I note from the info you pointed me to that the timing is pretty tight: A 'one' bit has an acceptable on - off time period of 58uS plus or minus only about 5uS. If you were generating the code directly from the Pi while at the same time reading user input and generating onscreen graphics, time wobbles introduced by Linux system events could easily knock the timing out of the acceptable tolerance range - so for that reason, it might well be best to use an 8-bit parallel interface from the Pi to shunt 3-4 bytes at a time to a microcontroller dedicated to the job of generating the actual control pulse train.

I've been playing with doing exactly what you describe: using the minimum amount of extra hardware to get a working DCC signal.

With nothing more than under a fiver's worth of interface board (http://www.ebay.co.uk/itm/Dual-H-Bridge ... 0535254940), I've got my Pi running trains up and down a small test track on my desk.

I'm using a timer to interrupt a dedicated thread which outputs a suitable signal on the GPIO pins. By setting the thread to run in the highest possible priority, the timing is accurate enough. It uses about 10% of the CPU.

I do intend to look at DMA at some point, but what I have at the moment works quite nicely.

[BrianW]

https://github.com/brianwiddas/gpiodcc

It's incomplete, but it's enough to make a train move using either JMRI or Android's SRCP Client (or other SRCP clients, probably, but I've not tested them).

[SiriusHardware]

https://github.com/brianwiddas/gpiodcc

It's incomplete, but it's enough to make a train move using either JMRI or Android's SRCP Client (or other SRCP clients, probably, but I've not tested them).

Thanks for sharing that, Brian - You honestly surprise me, I wouldn't have expected that the timing could be tight enough. I'll take a closer look at it at the weekend, thank you.

[pjcoleman]

It's great that this development has been done.
I'll give it a try and see if it can work with my Hornby 4amp booster box as this takes in any signal for DCC and drives it. I'll use a simple level changer to convert the output from the Pi to drive it.

[SiriusHardware]

With nothing more than under a fiver's worth of interface board (http://www.ebay.co.uk/itm/Dual-H-Bridge ... 0535254940), I've got my Pi running trains up and down a small test track on my desk.

.

I have one of those one the way to me now, so looking forward to having a play.

[SiriusHardware]

I've been playing with doing exactly what you describe: using the minimum amount of extra hardware to get a working DCC signal.

With nothing more than under a fiver's worth of interface board (http://www.ebay.co.uk/itm/Dual-H-Bridge ... 0535254940), I've got my Pi running trains up and down a small test track on my desk.

Brian,

I've got one of those L298 motor driver boards now - did you use a level shifter between the 3V logic outputs of the Pi and the 5V logic inputs of the motor driver board? Or do you find that 3V is enough to get over the logic level threshold?

[BrianW]

I've got one of those L298 motor driver boards now - did you use a level shifter between the 3V logic outputs of the Pi and the 5V logic inputs of the motor driver board? Or do you find that 3V is enough to get over the logic level threshold?

The Pi's GPIO output is fine to drive the L298N. It regards anything over about 2.5V as a logic 1.

[rkeil]

Hello
first - Thanks to Brian for this great work !

One comment:
The code runs only on a Rev1 Board (256MB Ram). For a Rev2 RasPi (512MB) you have to do some changes: The Pins 3&5 of P1 are not longer GPIO0 & GPIO1 at Rev2.
On a Rev2 Board Pin3 is GPIO2 and PIN5 is GPIO3.

I modified the source to use GPIO22 / 23 / 24.
So you can use it on Rev1 and Rev2 - but it's not tested up to now.

Greetings from Nürnberg
Rainer

[SiriusHardware]

I've got one of those L298 motor driver boards now - did you use a level shifter between the 3V logic outputs of the Pi and the 5V logic inputs of the motor driver board? Or do you find that 3V is enough to get over the logic level threshold?

The Pi's GPIO output is fine to drive the L298N. It regards anything over about 2.5V as a logic 1.

Thanks Brian - I was about to build some sort of level converter to be on the safe side - seems I don't need to. Thanks for all your work on this.

[rkeil]

Today i run the modified code on my Rev2 Board - it works.

Well done Brian !!

[dimonic]

The current issue (14) of MagPi has an article dealing with adding an Input/Output processor to a Pi, in part to overcome the lack of microsecond precision timing in Linux. The author specifically mentions that this would be useful for DCC. He uses a cheap ($1.25) LPC1114 IO Controller - which can be purchased with a board and ribbon for $20. He promises a future article to be in MagPi where he will detail projects.

I intend to give this a shot to build my own DCC system.

[BrianW]

The current issue (14) of MagPi has an article dealing with adding an Input/Output processor to a Pi, in part to overcome the lack of microsecond precision timing in Linux. The author specifically mentions that this would be useful for DCC.

I saw the mention of DCC in that article, and chuckled a little. I wrote the DCC above code just because a friend claimed it couldn't be done in Linux on the Pi.

My code runs itself at the highest possible priority and it does consume a lot of CPU, but it works. I wouldn't be surprised to learn that some DCC packets get ignored because of timing faults, but most of them seem to be accepted.

I have a suspicion that performance could be improved by putting the timing-critical elements into a kernel module. Also, it might be possible to do something with the DMA controller, which would free up a lot of CPU.

My first aim, when I find the time, is to separate out the SRCP bit from the DCC-generating bit, and make the latter part more amenable to calling from other programs.

[joan]

The current issue (14) of MagPi has an article dealing with adding an Input/Output processor to a Pi, in part to overcome the lack of microsecond precision timing in Linux. The author specifically mentions that this would be useful for DCC. He uses a cheap ($1.25) LPC1114 IO Controller - which can be purchased with a board and ribbon for $20. He promises a future article to be in MagPi where he will detail projects.

I intend to give this a shot to build my own DCC system.

The article mentions in particular

Some interesting projects that would require
microsecond timing resolution include:
• IR (Infrared) remote control protocols, such as the
LEGO® Power Functions RC protocol;
• DCC (Digital Command Control) for model
railroads;
• Ultrasonic ranging with a device like the Parallax
ultrasonic distance sensor.

As far as I'm aware none of these require microsecond timing and all are doable under Linux on the Pi.

• IR pulses are generally in the hundreds of microseconds.
• DCC I've not used but it seems to be in the 50s of microseconds.
• Ultrasonic ranging is in the 10s of microseconds and because you just need relative timings even Python can produce decent results.

[SiriusHardware]

The current issue (14) of MagPi has an article dealing with adding an Input/Output processor to a Pi, in part to overcome the lack of microsecond precision timing in Linux. The author specifically mentions that this would be useful for DCC. He uses a cheap ($1.25) LPC1114 IO Controller - which can be purchased with a board and ribbon for $20. He promises a future article to be in MagPi where he will detail projects.

I intend to give this a shot to build my own DCC system.

The article mentions in particular

Some interesting projects that would require
microsecond timing resolution include:
• IR (Infrared) remote control protocols, such as the
LEGO® Power Functions RC protocol;
• DCC (Digital Command Control) for model
railroads;
• Ultrasonic ranging with a device like the Parallax
ultrasonic distance sensor.

As far as I'm aware none of these require microsecond timing and all are doable under Linux on the Pi.

• IR pulses are generally in the hundreds of microseconds.
• DCC I've not used but it seems to be in the 50s of microseconds.
• Ultrasonic ranging is in the 10s of microseconds and because you just need relative timings even Python can produce decent results.

For DCC, it is the pulse length error tolerance which is in the order of a few uS, not more than about 5uS I think. That's why BrianW's achievement is so impressive.