The model train world has moved far forward from the old-school days of analogue current motor control. It's now possible to have multiple trains on a track with sound effects, lights, and motors, and control these trains with ease. DCC (Digital Command Control) is the cool new way to do this. It's a command protocol on the rail lines that allows for addressing  and commanding of individual trains on a shared "network" of rail line. DCC  can be thought of as quite similar to an i2c or rs482 communications bus but also supplying power at the same time as data. We're planning to use, likely 3, N-scale locomotives for our train layout that all have DCC decoders built into them. To interface to the DCC decoders on the trains we're using the Sprog 3 Command Station.

Sprog 3

The Sprog 3 is a simple USB based DCC controller that allows for both programming and running of devices on a DCC rail network. It's a really small packaged device and it works on a simple serial command interface. Traditionally it's connected to a PC or Raspberry Pi running JMRI which is a super powerful program that handles reprogramming of devices, track layouts and automation and a tonne of other stuff; it's actually over powered for what we're looking to do and I'm excited for the opportunity to create my own interface for working with the Sprog. To be fair, another reason we're using this controller is it was repurposed from a previous project so essentially for this project it was free.

DCC Command Protocol 

So when it came to working with the Sprog I had a little bit of a harder time than expected. The documentation for the Sprog is reasonable. It has a command list for "rolling roads" and other testing features but these setups tend to be for reprogramming purposes. When it comes to actually running a full working track layout you need the sprog in it's command mode instead. 

I needed a way to get a better look at what the command structure should be for the Sprog. I struggled to find anything under "Dcc command list" on google due to an open source "Dcc controller" project that actually led me astray. In frustration I tried a different tactic; I setup JMRI and after a lot of jigger-pokery I managed to get it up and running with my lovely little DCC decoder tester.

The decoder tester is basically a deconstructed train on a pcb. It has lights, a motor and speaker and with a decoder plugged in it reacts exactly like a train. Using JMRI (which reaffirmed my opinion that it's overly complex) I was able to monitor the packets that JMRI was sending to the Sprog based on my inputs to the JMRI "throttle" control. This made it clear that the Sprog works on a packet format similar to;

< O -Train Address- -Data 1- -Data2- -CheckSum- >

Now I could have simply gone through the process of testing every button press and speed value, creating a look up table of commands and using that to jerry-rig the control I wanted, but obviously it was much better to understand the packet and decode it to allow me to create commands on the fly. I did a couple of easy checks to start out; Speed, Forward, Backward, Stop slow and hard emergency stop. Interestingly these commands were all encoded in one packet. I thought that possibly there would be a separate command for direction and then speed but this didn't turn out to be the case.  

Clearly I needed some documentation to move forward. I contacted the owner of the Sprog site and he replied pointing out that the sprog accepts "standard NMRA DCC commands". That led me down the rabbit hole of eventually finding the NMRA spec sheet for DCC commands. Reading through the document we can see that the DCC commands are based on a packet layout as discovered and use the individual bits in a byte to differentiate the different commands and control. Another point made to me in the email was that JMRI repeatedly sends the same commands over and over again. This makes sense when we consider that the trains my lose packets or even full connection as they move round the rail track. By refreshing the packets consistently we ensure that the train behaves as expected.

It's going to take a lot more work but as of today I have a good set of python code to control an addressed train's speed, direction and one set of lights using the NMRA specs. You can find this code in my git hub under python_scripts. My future work will include supporting the "F" function buttons for the trains and also setting up a method of continually sending packets out at a refresh rate instead of just the once at the moment.