You're reading ...
Hardware, Software

DCC Sniffer – Packet Analyser with Arduino

This Arduino sketch ‘captures’ the DCC packets as they are transmitted by your Command Station and shows them in a readable format on your PC screen via the Arduino Serial Monitor.

Hardware: an Arduino Uno (or another type, as long as it runs the Uno code) and a small opto coupler circuit, the schematics of which can be found on the Software page. Total costs: around $4,-. Connect the opto output to pin 2 of the Arduino.

Software: the .ino sketch can be downloaded here. Unzip it and place the folder in the Sketches folder on your PC. No library is needed, just this one .ino file. Put the Arduino Serial Monitor on 38400 baudrate and enjoy the DCC commands passing by on your PC screen.

Most DCC packets are recognized, with the exception of the Decoder Control and Consist commands, which is work in progress.

Some examples of DCC packet readout:

Loc 1902 Forw 21 = loc 1902 speedstep 21 driving forward
Loc 4 Rev 14 = loc 4 speedstep 14 driving backwards
Loc 4 L F4-F1 0 = loc 4 lights off, F4 off, F3 off, F2 off, F1 off
Loc 4 L F4-F1 11 = loc 4 lights off, F4 off, F3 off, F2 on, F1 on (leading zero’s are not shown)
Loc 4 L F4-F1 10001 = loc 4 lights on, F4 off, F3 off, F2 off, F1 on
Loc 4 F8-F5 1010 = loc 4 F8 on, F7 off, F6 on, F5 off
Loc 4 CV 4 Write 3 = loc 4 write value 3 into CV4
Acc 4 1:3 1 On = Accessory 4 (= module 1 port 3) On, pulse = 1
Acc 5 2:0 0 On = Accessory 5 (= module 2 port 0) On, pulse = 0 (a module has 4 ports)

Edit October 25, 2015: A new version is available via the download link above. This version has the ability to send configuration commands via the keyboard, to change the buffer size, change the refresh time and to toggle on/off the display of locomotive or accessory packets. The keyboard commands that are available are:
1 = 1s refresh time
2 = 2s
3 = 4s (default)
4 = 8s
5 = 16s

6 = 4 DCC packet buffer size
7 = 8
8 = 16
9 = 32 (default)
0 = 64

a = accessory packets display on / off toggle
l = locomotive packets display on / off toggle


..

Advertisements

Discussion

49 thoughts on “DCC Sniffer – Packet Analyser with Arduino

  1. I’ve compiled the SW for an Arduino NANO.
    Connected the optocoupler to pin 2.

    But in the monitor I only see the message from the SetUp:

    DCC Packet Analyze started
    Updates every 4 seconds

    No message with a refreshing data.
    I’ve to say that the Opto is another type (6N136) then the one in the drawing (6N137). The designed type is on the mail, but not arrived yet. The 6N136 we have used with another DCC-signal detector and there a signal could be seen, so the opto should work.

    What is wrong in my setup?
    Why isn’t it working?

    regards,
    Willie

    Like

    Posted by Willie | June 27, 2018, 21:40
    • If there is no printout on the serial monitor, it means there were no recognizable DCC packets. This usually is caused by the dCC data not reaching pin 2 properly. The 6n137 is 15 times faster than the 6n136 … this may very well be the cause.

      Like

      Posted by RudyB | June 27, 2018, 22:14
      • Hi Ruby,
        I will test this evening if there is a DCC-signal available at the input and the output of the opto-coupler, at home I don’t have a scope. I’ve seen the 6N136 been used in DCC-applications like a selfmade decoder, so it is possible to use this type.
        How do you detect the DCC-signal? Is pin 2 at an Arduino-UNO and an Arduino-NANO (same number printed at the PCB) really the same pin in the program??

        Regards,
        Willie

        Like

        Posted by Willie | June 28, 2018, 10:54
      • As far as I know on the Nano pin 2 is also the interrupt(0) pin, same as on the Uno, so that should not make a difference. If it should be the number printed on the PCB I can’t tell … some board manufacturers use different numbers on the board than on the IC. You will need to check that yourself. I have the sniffer working here with an Uno and a 6n137 … the code is OK. Unless something happened with your code of course, I can’t tell.

        Like

        Posted by RudyB | June 28, 2018, 11:48
      • Found it.
        The 6N136 can be used very well for this application. Only a small midification in the schematics is necessary, the resistance from +5V to pin 7 of the optocoupler should be removed.
        Then the Sniffer is working perfectly, thanks.

        Like

        Posted by Willie | June 29, 2018, 06:16
  2. I have a question. everything works fine….however the screen keeps scrolling and I tried changing the refresh time and it does not work. Also I don’t think it matters I am using the Bachmann EZ-Command system….the sniffer posts everything..not just individual locos and decoders etc…thanks in advance!

    Like

    Posted by Scott | May 22, 2018, 21:18
    • The sniffers shows every valid DCC command that it recognizes. If it keeps scrolling then probably the EZ-command unit keeps sending out recognizable DCC commands. Different brands / types of command stations use different schemes of repeating DCC commands.

      Like

      Posted by RudyB | May 24, 2018, 17:38
  3. i’m trying to use nodemcu esp8266 V3 and nodemcu restarts (wathdog problem)

    Like

    Posted by pablo atalaya | May 20, 2018, 18:54
  4. Hi! tested on china duino with today nigthbuild portable IDE…ALLOK! I’ve changed some lines for a a stupid (is for me!) reading of F0-F4(ON)…or f0-f4(OFF)

    case 4: // Loc Function L-4-3-2-1
    mybyte=instrByte1&B00011111;// !!!!remeber to define variable byte mybyte;!!!!!
    if (mybyte&0x10) Serial.print(” F0 “); else Serial.print(” f0 “);
    if (mybyte&0x01) Serial.print(” F1 “); else Serial.print(” f1 “);
    if (mybyte&0x02) Serial.print(” F2 “); else Serial.print(” f2 “);
    if (mybyte&0x04) Serial.print(” F3 “); else Serial.print(” f3 “);
    if (mybyte&0x08) Serial.print(” F4 “); else Serial.print(” f4 “);
    //Serial.print(” L F4-F1 “); //your Printing!
    //Serial.print(instrByte1&B00011111,BIN);//your Printing!

    break;
    Thanks,
    Carlo

    Like

    Posted by Carlo Zamboni | April 30, 2018, 16:47
  5. Hi Rudy,

    Thanks for sharing your work.

    I made a DCC Decoder with 6N137 (Dave Falkenberg schematic) but he can’t detect any signal from the tracks.

    I’m using a DCC++ BaseStation and the JMRI Signal Monitor reports every packet.

    I don’t think I have a problem with a faulty component because I made 4 of this circuits with different components on 3 different breadboards…

    I also tried the following:
    – Change R1 from 1K to 2K,
    – Use 12v and 15V

    Do you know any issues with this and DCC++?

    Thanks in advance
    Miguel

    Like

    Posted by Miguel Rodrigues | January 14, 2018, 20:58
    • Hi Miguel. There should be no issues with the optocoupler circuitry … if there are no faulty components and if the soldering is done according to the schematic, it always works. What you could do is order one of those €7 logic analyzers shown on one of the last blog posts and test the sgnal to see if the 58us and 100us dcc pulses really reach the Arduino on pin 2.

      Like

      Posted by RudyB | January 14, 2018, 22:31
      • Thanks Rudy,

        I already bought one usb analyzer is on the slow boat.

        Since it’s going take a few weeks I also bought one board made from DCC Interface in the UK to see if the problem comes from my DCC++ base station or from the all batch of optocouplers.

        Thanks for your time

        Miguel

        Like

        Posted by Miguel | January 15, 2018, 12:38
  6. Sorry if I wake old daemons 😉 I cloned this and ported it to run on an esp8266.
    https://github.com/bjorniuppsala/RudysModelRailWaySnifferOnEsp8266

    Like

    Posted by Björn Bergman | December 29, 2017, 21:21
  7. Rudy, I would like to thank you for this program. It is a good trouble shooting tool. For those who try and construct the electronics make sure that the component leads are “fully” pushed in the breadboard. It does work!

    Like

    Posted by Glenn Laser | December 13, 2017, 14:19
  8. Hello Rudy,

    Here the correction to insert in the ino file to correct the problem of bad long address :

    if (bitRead(dccPacket[1],6)) { //bit7=1 AND bit6=1 -> Loc Decoder Long Address
    decoderAddress = 256 * (dccPacket[1] & B00111111) + dccPacket[2];
    instrByte1 = dccPacket[3];
    decoderType = 0;
    }

    Nice week and regards,

    Alain

    Like

    Posted by Alain Meunier | June 19, 2017, 17:17
  9. Hello Rudy

    I read addr 102 on the monitor (loc line). Strange the real loco addr is 6246. (spped and functions are OK)
    I test with Roco multimaus centrale
    As the sniffer decodes long addresses, I ahve no aidea about the problem.

    Have you sime explanation ?

    Thank you for thr work and best ragrds,

    Alain

    Like

    Posted by Alain Meunier | June 18, 2017, 16:12
  10. Hello Rudy

    I have a address problem (ROCO multimaus centrale) withe the sniffer
    The sniffer shows addr : 102 but the real addr is 6246 but I think the sniffer decodes long address
    Have you an idea ?

    Alain

    Like

    Posted by Alain Meunier | June 18, 2017, 16:07
  11. Hi Rudy, some brilliant sketches and free too, your a ‘Star’ for that.

    I have built the Sniffer V2 and it worked first time, my very first Arduino project as well, never used one before. Really pleased with what it can do.

    Could you kindly expand a bit on what the three columns of binary represent after the plain English packet description. I do understand binary to decimal conversion that is not the issue, but the three columns have no descriptive heading to what they represent.

    Hope you can fill in the detail for me.

    Thanks again for the great work you are doing.

    Chris in UK

    Like

    Posted by Chris Saf | February 12, 2017, 22:28
    • lol, Chris, it’s alreay too long ago for Me to remember what those bytes are! 🙂 I did not check the code yet … but I bet they are just the raw address and data bytes as read from the DCC signal. Since they are difficutl to interpret by eye, because bits are mingled in all kinds of dubious ways according to the NMRA standard, the translation into readable text is exactly what the sniffer does for us.

      Like

      Posted by RudyB | February 13, 2017, 11:08
      • @ Rudy and Chris

        I just looked up the NMRA spec for accessory decoders (S-9.2.1 Para D) and it is impossible to decipher by me anyhow. I can just about decode the rest of it but he accessory decoder part has me stumped.

        There is a basic part, then an extended part, which deals with, by way of a second data byte, handling of signal aspects which is what Chris is trying to help resolve on the Hornby forums.

        Could you point me / us in the direction of which file amongst the full download package contains the binary decode please.

        Rob also in UK

        Like

        Posted by Rob | February 13, 2017, 12:07
      • I’ve worked out some of them from other DCC documentation For example; the left most column on a Loco packet is the Loco ‘Short address’. I would assume that one of the other two loco columns should represent direction and speed. Example for ‘loco, forward, stop’ I should see (I believe 01100000) [01 = defining a speed and direction byte, 1 = forward, 00000 = speed stop] but my two undefined columns are 00111111 & 10000000 respectively which have no comparison to what I was expecting. Bit of a mystery.

        On an Accessory packet, the left hand column appears to be the ‘accessory module number’ but the right hand column meaning and where the port number is expressed in binary is still eluding me at present.

        My next step is to start reading NMRA S9.2 & 3 again I’m sure given enough effort all will become clear. But any further clues you can give me to the examples I have given above would be appreciated.

        As you say, understanding the binary is not imperative, but I really want to get into understanding the DCC packet protocol. And see this tool as an aid to that.

        Thanks again for the prompt reply….

        Like

        Posted by Chris Saf | February 13, 2017, 12:52
      • Just thought I would update you with the status of my deciphering the binary packet coding. I have got the Accessory Packet deciphered now. The port number is Bits 1 & 2 in the second Byte. It looks as if the two loco bytes that had been eluding me (middle and right hand columns) are extended packets with the 128 speed step structure, whereas the basic byte that I was expecting to see displayed is for 14 speed steps. So I should, with a bit more research of the NMRA S9x standard, get that understanding sorted soon. My initial look at the DCC Function packets look fairly straight forward. One thing that I think that I have observed from your sketch code is that the binary only displays the first address byte, thus the second byte for long addresses are not displayed in the Monitor. In other words, you appear to have chosen to only display some selected DCC bytes and not the whole frame / packet structure. I think that it is that binary display limitation that had thrown me before.

        Anyway, I am making progress and using the Sniffer output in conjunction with the S9x Standards documentation has really helped with my understanding of the DCC packet structure. The NMRA does seem to be rather haphazard with the way they have DCC functions split across multiple bytes. It makes reading the commands in binary quite difficult, in fact very difficult. I can now really appreciate the benefit of the binary to plain text translation.

        Like

        Posted by Chris Saf | February 14, 2017, 00:42
  12. Hi rudy. Your sniffer works fine. I came up with the idea to expand it with an LCD display as a standalone object just
    for fun. I thought it would be easy, just to add lcd.print(“”); after Serial.print(); in the loop section.
    The issue: when pressing the corresponding function on the ECOS, serial monitor stops an LCD is empty ( showed
    intro from setup). On internet i found code from the NmraDcc guys with an LCD display. Is there any idea from the
    experts out there? Code can be sent if desired. regards

    Like

    Posted by helmut schmied (Heidelberg) | January 30, 2017, 21:25
  13. Hello Rudy,
    Many thanks for your work and availability. I downloaded your files, wired the opto and checked that the DCC is read and brought to Arduino pin2…but the serial monitor says only DCC Packet Analyze V2.0 started and displays no other DCC data.
    How can I be sure that the DCC is read by the Arduino?
    Thanks for your help
    Yves

    Like

    Posted by Yves | January 25, 2017, 16:19
    • Yves, that is hard to tell. If the optocoupler circuit is soldered correctly AND the optocoupler itself is not broken it should work. What you can try is the DCC_decoder_servo sketch and configure it for one servo at say address 1 and give it output pin 13. Then, if you operate that servo via your DCC, the on bord LED must go on/off. If it doesn’t … there is no proper DCC input on pin 2. All you can do then is check the hardware.

      Like

      Posted by RudyB | January 27, 2017, 11:26
      • Hi Rudy, Thanks for your answer. I checked the HW again and looked to the signal at Arduino input pin2. It looks fine: 0-5 volts swing, good rise time, no jitter. But I found another problem on the DCC itself.
        I suspect now another trick: I use a LENZ LZV100 unit that has a long stop for RailCom operation. This means that the DCC signal is set to 0 volt during 1 msec every 20ms. This might confuse your DCC reading routine.
        While I investigate if I can disable the RailCom feature, can you tell me your feeling about your decoding routine in front of this bad behavior? Thanks again, Yves

        Like

        Posted by Yves | January 29, 2017, 09:38
      • Hi Yves. I can’t tell, the raw DCC is decoded using the NMRA Arduino library available on the internet. I never looked into that in detail, I just use the data packages that it generates in my code.

        Like

        Posted by RudyB | January 29, 2017, 10:00
  14. Rudi
    I have been following your progress on the DCC sniffer project with interest as I am working on a similar project using a USB oscilloscope and a commercial software package that has DCC functionality built in.

    The only way to make sense of what the scope ‘sees’ is by way of what I call a Link File which translates the binary values from the DCC packets (per NMRA definitions) into understandable text on screen.

    You already appear to have achieved this cross info listing as your screen shots show the text translation of loco speed and direction, address, points commands, etc.

    Would you be happy for me to use this ‘translation’ file (if and when I can find it) and for it to be used at end game by the people who market this software, which incidentally is a free download from their website.

    If you would like to discuss further then please contact me direct at honnor@cytanet.com.cy
    Thanks Rob

    Like

    Posted by Honnor@cytanet.com.cy | January 17, 2017, 13:13
    • Hi Rob. All the ‘translation’ done is visible inside the Arduino sketch code. There is no other info used than that. It was deducted by myself from the available DCC message descriptions on the NMRA website.

      Like

      Posted by RudyB | January 17, 2017, 14:12
      • Many thanks Rudy. I will ensure a suitable credit is posted to you.
        I cannot see a direct email contact for you anywhere, so I cannot put you in direct contact with these guys unless you want me to.
        Rob

        Like

        Posted by Rob | January 17, 2017, 14:20
      • I’ve sent you an email.

        Like

        Posted by RudyB | January 17, 2017, 15:58
  15. Hallo Rudy. Thanks very much for the great video. I’ve downloaded your DCC Sniffer ver 2, but it shows the wrong Loco address and the Serial input text that Juergen added does not even work. Any thought?
    Thanks in advance.
    Oji

    Like

    Posted by Oji no hansamu おじハンサム | December 9, 2016, 23:27
  16. Started today with the Arduino and DCC, and your sniffer works great, a good start point to go on with.

    Liked by 1 person

    Posted by Alco Post. | May 25, 2016, 23:06
    • Hello Alco?
      Welcome to Rudys site (hi Rudy I hope you do not mind me commenting! 😉
      I was hoping you were interested in the general topic and “might !” be looking for a similar wifi solution as myself?
      I have an Arduino DCC loco decoder which works great but I need it battery powered! So therefore DCC over wifi is the next evolution/step to make.
      If we are on the same journey, we could help each other?

      Regards

      MartinK

      Like

      Posted by martinkirkby | May 28, 2016, 20:15
  17. Hello Rudy
    So I am on to my next project after the success with the s88:),
    It’s wireless DCC!
    I have looked at this code and would like to send the “dccPacket” via a nrf24 to multiple other wireless DCC decoders ?
    Using your code is great as it makes it readable at both ends, great for debugging bad wifi!
    However my coding is basic at best and I can not get the packet format correct? Is there any chance you could post something which would get me to a working solution.
    Thanks

    MartinK

    Like

    Posted by martinkirkby | May 13, 2016, 12:39
    • Not excatly shure what you need, I can only point you at the NMRA DCC standard. Chapter S-9-2 contains all info on the DCC packets.
      http://www.nmra.org/index-nmra-standards-and-recommended-practices

      Liked by 1 person

      Posted by RudyB | May 13, 2016, 13:35
      • Hello Rudy
        I was trying to use your packet analyser to read the track DCC “packets” and get it to send them via wifi (nRF24) to another pro-mini fitted with the same wifi unit .
        Your code shows a print (dccPackets(n),BIN); for the binary packet ?but I am having trouble sending that to the rx/pro-mini?
        Due to my lack of coding skills! I think it must be formatted to use the radio.write command? Or I am I looking in the wrong buffer?

        Regards

        MartinK

        Like

        Posted by martinkirkby | May 13, 2016, 14:45
  18. Thanks a lot!
    But I can’t download software.. Download link doesn’t work(

    Like

    Posted by Михаил | March 31, 2016, 12:12
  19. I’m running DCCSniffer on an Nano V3 – works perfect

    Like

    Posted by Jueff | March 5, 2016, 11:24
  20. Hello Rudy, i have trouble with downloading your .zip files from app.box.com site. Can you help me, how to download it.
    Thanks.

    Like

    Posted by John | March 4, 2016, 12:04
    • Yes … there are trouble with Box … seems the monthly download limit is reached (I did not know such limit existed). Please go to the Software page and from there download the complete package that includes all the available files.

      Like

      Posted by RudyB | March 4, 2016, 12:09
      • Thanks – from Software page download works fine. And – thanks for your work with Arduino and DCC.

        Like

        Posted by John | March 4, 2016, 12:46
  21. I’ve improved the source code and would like to share the enhancements – how can I do that?

    Like

    Posted by Jueff | March 3, 2016, 11:07
    • Hi Jueff. Well … you could post a download link here in the comments. Or you could email it to Me and I can include it in the overall combined download package (you put your credentials in the code comments of course!)

      Like

      Posted by RudyB | March 3, 2016, 12:54
  22. Thanks a lot for the sniffer Rudy. I really wanted to make this as I love to see the details. I tried with some 817 opto-couplers that I had to hand but they are really not fast enough and I could not get the sniffer to work at all. So I ordered some 6n137s and it worked well. One thing to note though. The DCC voltages can be quite high and the 1KOhm at the input to the opto-isolator will draw a fair amount of current. I get +/-15V peak to peak which means that you need a minimum 1/2 watt resistor assuming 50% average duty cycle. I’m currently using two 3K 0.25W resistors in parallel and they get hot. I’ll now be ordering some beefier resistors than I have. Of course.. you can increase the resistance a bit as well as the turn on threshold for the 6n137 is 5mA so a larger resistor is also ok.

    Like

    Posted by hobbyspot | November 22, 2015, 20:36

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s

%d bloggers like this: