Ever wonder what your DCC system is actually putting on the rails? Need an interface to read the DCC signal and send it in a standardized form to another system? Here's a solution - a DCC decoder that outputs the data stream as serial.
I initially built this so that I could see how Lenz was mapping their accessory decoder numbers to actual packets on the wire. Eventually the intention is to use one of these as a front end for a DCC to MRBus bridge, but for now it's a handy way to see how DCC works at the packet level.
The module requires a very stable 5 volt power supply. You'll need to provide this, either via a simple 7805 linear regulator circuit, or whatever method you chose.
There are two configuration jumpers - neither does a darn thing at the moment. Eventually, they'll function as follows:
- The "-NO_DECODE" jumper, when closed, will shut off the human-readable decode. Packets will come out as
P:XX XX XX XX <0xA><0xC>, where each XX is one byte of the packet. * When the "-SPI/RS323" jumper is open, the output is in RS232 mode (what you'll want for a computer). When it's closed, the PIC will switch over to SPI mode, which is more appropriate for interfacing with other microcontollers. (This is very much TBD, and I have no idea what the output will look like.)
For now, just leave both jumpers open.
Otherwise, connect the DCC inputs to the track and plug the RS232 cable into the computer. Set your favorite terminal program to 115200 8-N-1, no flow control, and watch the output. If the system is picking up a valid DCC signal, the "DCC VALID" LED will come on and you should start seeing decoded output on the screen.
The PIC will do its best to break down the packet into something human readable.
- Any packet that cannot be decoded will come out as a raw packet, in the form:
P:XX XX XX XX <0xA><0xC>.
- Any packet that starts with E: will be an exception. Sample exceptions:
- E:DCC ON - DCC signal started
- E:DCC OFF - DCC signal lost
- E:CRC - DCC packet checksum fail
- Any packet beginning with L: is addressed to a multi-function decoder (usually locomotive). The L: will be immediately followed by a three digit number for short addresses, or a four digit address for long address modes.
- Any packet beginning with A: is addressed to an accessory decoder, and is immediately followed by the four digit address. (Note that due to a lack of agreement between DCC manufacturers and no clear guidance from the NMRA, how an accessory address actually translates to an over-the-rails command will vary significantly.)
Source Code Notes
The source was built with the BoostC 6.89 compiler, but it should be adaptable to most PIC C compilers. It's targeted at a PIC16F628A micro.
For those who don't want or need to compile the source themselves, the binary image for the PIC (suitable for feeding to MPLAB or your favorite programmer control environment) is also included in the zip file.
Source code and binary, v0.9