As I mentioned previously in my entry about using the Zimo MXULFA as a simple DCC Command station, JMRI (at the time of writing) has a bug that causes the locomotive direction of travel to be reversed to what is requested when using this device.
As part of my testing this problem, I put together a DCC Sniffer to enable me to verify where the problem was occuring.
A DCC Sniffer is a device that connects to the DCC output of the DCC command station (i.e. the rails), and decodes the DCC commands it sees into a human readable form.
I had an Arduino Uno compatible board available, that had a small prototyping area built in to the board itself, so I was able to construct the DCC Optocoupler circuit in the prototyping area for a single board solution.
I also added the LEDs that Neil mentioned in his post, so if I want I don’t even have to connect the sniffer to a PC, I can just supply the sniffer with 5V on the USB cable (e.g. from a Power Bank or USB charger), and see indicator lights for a quick diagnosis of main DCC functions.
Some people might be wodnering where the LEDs are in the photo above. I left them behind the label deliberately, and when lit they show through.
The above image doesn’t really show the LEDs as well as they appear in operation, so this one is a better close-up, with a deliberate “fault” condition to show I have 3 colours of LED in use:
When I was using this device to diagnose the MXULFA, connection to the PC and monitoring the serial output from the sniffer was required. This showed that while JMRI was setting the locomotive direction to Forward, the MXULFA was setting the DCC code to Reverse, and vice versa. When the MXULFA was used as a stand-alone DCC controller, the directions worked correctly, and other people confirmed that the MXULFA worked correctly when it was connected to different PC software, so the bug was tracked down to being the JMRI interface with the MXULFA device.