DCC++ and Arduino DCC accessory decoder trouble

Pepijn Jul 3, 2016

  1. Pepijn

    Pepijn TrainBoard Member

    18
    23
    4
    Has anyone successfully managed to operate any accessories such as turnouts using DCC++ in combination with one of the available DCC decoders for Arduino?

    I'm trying to operate two turnouts with servos connected to an arduino. The arduino runs a DCC decoder library and taps in to the DCC signal on the rails. This worked fine using my Roco Multimaus command station but I ran in to trouble using the DCC++ base station. After some fiddling around with DCC packet monitors I found that both the Mynabay library and the NmraDCC library fail to pick up the DCC packets from DCC++. Both work fine with Roco unit. I can however operate trains with DCC++ without any trouble.

    I'm using the circuit posted on the Mynabay page which is similar to circuits used in OpenDCC and other places.

    Anyone has any thoughts on what might cause this? Anyone used "hardware decoders" successfully?
     
  2. Scott Eric Catalano

    Scott Eric Catalano TrainBoard Member

    205
    57
    6
    I thought DCC++ had turnout options as well as sensor code built in?
     
  3. Jirka

    Jirka TrainBoard Member

    32
    39
    3
    Hi Pepijn,
    I moved from Roco to DCC++ successfully. Using Geoff Bunza's servo decoders for turnouts. Have you considered the Roco accessories address offset?
     
    Scott Eric Catalano likes this.
  4. Pepijn

    Pepijn TrainBoard Member

    18
    23
    4
    Thanks Jirka. Good to know this should definitely work.
    At first I thought the address offset was the problem, but the dcc packet monitor for both libs just fails to see any packet, even though I can move my trains, so they're there for certain.
    Maybe there's some distortion in the signal and the arduino dcc libs need a tighter signal than the hardware decoders on my trains?

    Working on some other stuff right now, but I'll try to troubleshoot it further at some point.
     
    Scott Eric Catalano likes this.
  5. Jirka

    Jirka TrainBoard Member

    32
    39
    3
    Well, the address offset was my mistake in the first step... then I tried to look with the Arduino based DCC sniffer at the command packets for the turnouts and found the problem. This means: when the Ardunio based sniffer can read DCC correctly (i.e. HW and SW is OK) , why shouldn't work the turnout decoders? (Unless they use differrent libaries than the the sniffer.)
     
    Scott Eric Catalano likes this.
  6. miguelcarmor

    miguelcarmor TrainBoard Member

    32
    17
    8
    Hi Pepijn,

    I'm sorry to resurrect this post but did you solve the problem? I'm having the exact same issue. I can run my trains with DCC++, but the dcc monitor from the arduino accessory decoder, comes out empty, no packets on the track. On my case I don't have another base station or throttle to try things out.

    Any help will be very much appreciated.

    Thanks

    Miguel

     
    Scott Eric Catalano likes this.
  7. PZ

    PZ New Member

    1
    2
    7
    Hi Miguel,
    I am also having the exact same problem. I have a regular motor shield - Deek Robot. I can use DCC++ to run a loco but monitoring packets with the Mynabay decoder library doesn't work. I know the Mynabay decoder does normally work because I have another booster circuit based on LMD1800 and the Mynabay decoder definitely works there. I used a Saleae Logic analyser to look at the signal going into the decoder Arduino from the motor shield and there are definite glitches, about 1 microsecond long just after almost every falling edge. Here is a picture: http://nscalemodeller.com/assets/Glitch.jpg. I presume the motor shield is producing the glitch rather than the circuitry in the decoder that extracts the signal and makes it compatible with the Arduino because, as I said, the decoder does work with another booster.

    I also discovered that I can temporarily remove the glitch by probing the boosted DCC signal with a multimeter set to a resistance range ( almost any will do ). How to fix this permanently I don't know.

    My guess is that the Mynabay decoder is a bit sensitive to glitches. Does any one know of an Arduino DCC decoder library that uses a different technique for detecting the signal?
     
  8. Naji

    Naji New Member

    1
    2
    1
    I am in the same boat. I have a DCC++ based on the Mega. I am also using IBT_2 as a booster. I can run the trains fine using both JMRI and Rocrail. I have built one of Geoff's 17 function decoders to use for servo control and when loaded as a multifunction, I can control it using the f0-fx buttons. But when loaded as an Accessory decoder, I can not get it to work. Most probably user error on my side since I am a newbie with DCC and addressing. For the folks that had success, can you advise how you setup the addressing in Rocrail and or JMRI with the default address configuration of 24 and 40.
    TIA
     
  9. William E Van Buskirk

    William E Van Buskirk TrainBoard Member

    40
    22
    3
    Hi Naji, sorry to resurrect yet again but recently I've been looking into Geoff's code for use with DCC++. Goeff's newest release zip, the extra content from Dec 2016 MHR article, has decoder sketches for both Mobile and Accessory decoders; some are functionally the same except for the addressing method.
    For the AccDec_xxx sketches it appears to me he is using Output Addressing mode, an 11 bit address per Function Pin (as opposed to Adr+SubAdr mode), and with the Dec_xxx sketches he is using Mobile decoder mode, same as a loco. What I think may be a problem is the DCC++ Base appears to only accept Adr+SubAdr Accessory addressing. Now I don't know how either of the Accessory address modes are sent via DCC, both seem to be the same total of 11bits, 9+2 or 11 bits. But if they are transmitted differently then a decoder expecting an 11Bit address would ignore a 9+2 address (?).
    In regards to these addresses, the first address, '24' is a Mobile decoder address and used for only programming the board's CVs. The '40' is the Accessory Decoder base address, and 40 corresponds to F1, 40+1 for F2, 40+2 for F3...up to F17, based on the code comments.
    Bill
     
    Scott Eric Catalano likes this.
  10. strchr99

    strchr99 New Member

    4
    0
    4
    Hi,
    I am a newbie on TrainBoard, but I have the same problem. Recently I made a DCC++ base station with Raspberry PI, and I can run trains fine.
    I have a few OpenDCC decoders, but they can not run on this system.
    Does anyone have a solution, please?
    Thanx,
    Tamas
     
  11. H0Guy

    H0Guy TrainBoard Member

    25
    6
    3
    What Arduino board are you using for your bade station and for your motor Shield?

    What error are you getting?

    Greg’s latest version of DCC++ v1.2.1 appears to only work genuine Arduino Motor Shields.
     
  12. strchr99

    strchr99 New Member

    4
    0
    4
    Hi,
    I am using a clone arduino uno board and a clone motor shild (deek robot). At first time CV redaing does not work. I modified PacketRegister.cpp and PacketRegister.h. The CV reading is working now, but the OpenDCC acessory decoder does not.
    So I am searching the solution.

    Best regards,
    Tamas
     
  13. H0Guy

    H0Guy TrainBoard Member

    25
    6
    3
    strchr99: What exact changes did you make to PacketRegister.cpp and PacketRegister.h? Can you send a link to the code?

    I have been looking at those modules myself. I have a Genuine Arduino and Genuine Arduino Motor Shield and everything I have tried appears to work with DCC++. I also have a Clone Uno and Arduino Mega and as long as I use the Genuine Arduino Motor Shield they work properly as well.

    However, I have a Pololu Motor Shield that has problems. It does not handle Auto Reversing at all and has a lot of 308 Engine not Acknowledging errors when I try to Program a Decoder.

    I have not tried to use any OpenDCC accessory decoders though.

    Have your tried using a regular Arduino Uno and Arduino Motor Shield?

    Those Modules you referenced in addition to the Current Sensing module and header are where I think Glenn's original code may be tailored specifically to the Genuine Arduino Motor Shield and may result in problems with clone Motor Shields including the Pololu Motor Shield.

    Not all clone Uno and Motor Shield boards handle I/O Pins, Clocks, Short Circuit Protection and Current Sensing exactly like the Genuine Arduino board. Glenn's code appears to be specifically written for the Arduio Uno (and Mega) and Arduion Motor Shield. Most of the fixes to these issues only fix the I/O Pin differences and not the other differences.

    Most of the issues I have seen on TrainBoard related to DCC++ have to do with Clones that are not 100% compatible with the actual Arduio boards.

    Regards, HOGuy
     
  14. strchr99

    strchr99 New Member

    4
    0
    4

    Attached Files:

  15. H0Guy

    H0Guy TrainBoard Member

    25
    6
    3
    Tamas:

    Thank you for the link. I took a quick look at the code and I don't think it addressed the issue that I found. I will take a more detailed look and compare the updated code with the original code and see if the changes fixed the issue that I found.

    Does is support Current Sensing on pins A0 and A1? If you look at Toms Trains and Things Website (https://tomstrainsandthings.com) he had a session on different Arduino Motor Shields and had difficulty getting the deek robot to work properly with DCC++. The deek robot motor shield may be your problem. Than again, the deek robot motor shield may not be your problem.

    Can you try a Genuine Arduino Motor Shield?

    Some clone Motor Shields do not support Current Sensing at all and should not be used as Motor Shields for DCC++.

    Other clone Motor Shields support Current Sensing, but are calibrated differently than the Genuine Arduino Motor Shield. If that is the case, they may not work with all DCC++ Commands or on when you are trying to read from the Decoder on the Program Track. They may let you run trains, but may not be able to read Acknowledgements from the Decoder in the engine.

    Regards, Larry (HOGuy)
     
  16. Atani

    Atani TrainBoard Member

    1,466
    1,736
    37
    There are a few different "deek robot" motor shields out there. If it has the L298 chip on it then it *WILL* work with DCC++ (or any variant thereof). If it has the L293 chip it *WILL NOT* work with *ANY* variant of DCC++.

    The L298 chip has current-sense capability whereas the L293 does not.
     
  17. wvgca

    wvgca TrainBoard Member

    499
    305
    21
    huh ... i never realized the deek robot shield was available with the L293 ......
    i always thought it came with the L298, amazing what you find out , lol
     
  18. strchr99

    strchr99 New Member

    4
    0
    4
    I have downloaded a motor shield schematic from net, and tried to check the clone board, and as I can see it looks like the same.
    So IMHO not the clone shield is the problem.
    I have found a few different DCC++ code on net, I have not tried them all, but I will.
    I want use my opendcc decoders. I have a Roco base station and it is works well.
     
  19. H0Guy

    H0Guy TrainBoard Member

    25
    6
    3
    Atani: Thank you for the information on the Deek Motor Shield.

    It seems as though there are a large variety of Motor Shields with many different characteristics. This makes it hard to support an application like DCC++.

    I understand that you developed your own implementation of a DCC Base Station. How do you handle the different varieties of motor shields?

    HOGuy
     
  20. Atani

    Atani TrainBoard Member

    1,466
    1,736
    37
    There are only a handful of ICs out there used by motor shields really. Many of them are usable but functionality is very limited on some by themselves as they do not offer current sense. This isn't always a deal breaker as you can add a current sense IC and feed to the the ADC pin bypassing the motor shield.

    For my ESP32 CS project, I've tried to capture known working shields/boards and caution against ones that do not have current sense by themselves. It is a bit more complicated now that I'm supporting RailCom since the L298 IC uses low side current sense and can miss short circuits in some configurations, this is why I switched to using the LMD18200 as the OPS output which uses an inline current sense circuit. Ideally the current sense would be high side.

    As for the configuration support for multiple board types, I have conditional logic which reconfigures the limits in the CS dynamically based on the board type and set limits (like the IBT_2 boards which can provide 43A!). I have found so far that documenting the supported configuration options (with pictures!) really helps people avoid mistakes on purchasing the wrong type of motor board.

    Sent from my ONEPLUS A5010 using Tapatalk
     

Share This Page