Two commands with DCC

Robert Owen Feb 2, 2021

Tags:
  1. Robert Owen

    Robert Owen TrainBoard Member

    51
    5
    6
    I wrote an Arduino script to implement DCC signalling on the track. My code can send a single DCC packet to an engine. If I send "01101111" in the command byte, the engine will move forward. While the engine is moving, I send a second packet with "10010000" in the command byte to turn on lights. I would have thought the engine would keep moving while the lights turned on. Instead, the engine stops, and the lights come on. Can anyone explain why this happens? Also, how do I instruct the decoder both to keep the train moving and turn on the lights?
    Thanks in advance.
     
  2. Robert Owen

    Robert Owen TrainBoard Member

    51
    5
    6
    I tried implementing an extended packet format with two command bytes 01101111 0 10010000, but the decoder only recognised the first command, and ignored the second command.
     
  3. Ash

    Ash TrainBoard Member

    106
    66
    8
    This is what I see in JMRI's DCC++ Traffic Monitor (with Show raw data):
    (Speed 62 is about 50% throttle.)
    [TX: t 4528 62 1] Throttle Cmd: Register: 1, Address:4528, Speed 62, Direction: Forward
    [TX: f 4528 144] Function Cmd: Address 4528, Byte 1: 144, Byte 2: null

    Speed 62 is about 50% throttle. I don't know the translation to DCC. I see a 't' and 'f' to distinguish between a Throttle Cmd and a Function Cmd. Perhaps the answer is in Byte 2.

    Reverse:
    [TX: t 4528 62 0]
    Stop:
    [TX: t 4528 -1 1]
    Headlight Off:
    [TX: f 4528 128]
     
    Robert Owen likes this.
  4. Robert Owen

    Robert Owen TrainBoard Member

    51
    5
    6
    Thanks Ash. Those are DCC++ commands, I am not using DCC++ and have written my own code for Arduino. The question was about understanding NMRA's S-9.2 and S-9.2.1 standards, and the way DCC specs enable two commands to the same decoder. When I implement two commands in two bytes, according to S-9.2.1, the command in the first byte is performed, while the second byte is ignored.
     
  5. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
    Well, the spec is fairly involved. Are you sending continual idle packets in between commands? Do you have the proper preamble, start and stop bits, and checksum byte? Are you repeating the commands for X number of repeats (say 3 for lights and constant for throttle)? Are you making sure there are at least 5ms between commands? Probably the easiest way to "see" what is happening is to use our https://github.com/DCC-EX/DCCInspector-EX using a microcontroller of your choice connected directly to the direction pin of the command station (to avoid the circuitry you need to connect it to the tracks), or get a $8 logic analyzer and use the free sigrok pulseview and the decoder we worked with littleyoda on to visually see the waveform and packet structure in a train with the decoded commands below it on your screen. The first option shows the decoded commands as they come in in real time in a table, the second captures a set period of the packets and displays them for you to scroll through later:

    dccpp_ex_acc_packet.jpg
     
    Robert Owen likes this.
  6. Robert Owen

    Robert Owen TrainBoard Member

    51
    5
    6
    The format you listed are all correct. Using a single command, I have tested the script on three trains with different makes of decoder, altering the speed of the engine. Three trains at different times, not on the same track. Not sure what you mean by "Are you repeating the commands for X number of repeats (say 3 for lights and constant for throttle)". My reading of the spec is that a single command should change the speed, which my script does. The problem is that a second command, to do something else like turn lights on, cancels the 1st command.
     
  7. haba

    haba TrainBoard Member

    78
    32
    10
    I always ask: What Decoder?

    Decoders can expect that speed information is sent continiously and if they discover that for some time no speed info has been sent they may stop. In some decoders one has a CV to configure the time commands are remembered. Probably that's just what happens when no special time is configured.

    Any special reason to start implementing this from scratch (but for the tinker value and the satisfaction to have it done)?
    You seem to implement 14/28 speed step mode. In DCC-EX we did not find that an important feature any more as most
    decoder encoutered can 127 (as it mostly is called) speed step mode.

    S9.2:
    C: Frequency Of Packet Transmission
    Packets sent to Digital Decoders should be repeated as frequently as possible, as a packet may have been lost due to
    noise or poor electrical conductivity between wheels and rails. Power may also be removed from the rails between
    the Packet End Bit and the Preamble of the next packet to allow for alternative command control formats. ...

    This applies to all packets to mobile decoders but to the higher function groups.

    Regards,
    Harald.
     
    Robert Owen likes this.
  8. Robert Owen

    Robert Owen TrainBoard Member

    51
    5
    6
    I realised my mistake while in bed last night. I construct a command packet, compile the script, and send it to Arduino for processing. My mistake was to assume I could construct a second, lights on, packet on my laptop, compile the script, and send it to Arduino and that the 1st speed packet would continue to be processed. I now realise that sending the second packet halted the decoder, took power off the tracks, and reset the decoder, which is why the 1st command stopped working. I need to implement a serial data channel from the laptop to change the value in the command.

    I wrote my own code for DCC to see how it works.
    Thanks for the assistance.
     
  9. Robert Owen

    Robert Owen TrainBoard Member

    51
    5
    6
    "Power may also be removed from the rails between the Packet End Bit and the Preamble of the next packet to allow for alternative command control formats. ..." My understanding is that if power is removed from the rails the decoder will reset since the decoder uses DCC digital signals to generate DC power for itself. This is the point of the idle packet, to keep the decoder powered at all times between command packets.
     
  10. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
    Well, most of the spec came from Lenz, and the additon of "power removed from the rails" is very specific to their Railcom. So this requires specialized hardware to short the track to create a current loop for the Railcom data to be transmitted in a 488us (note MICRO second) burst. Short enough to not interrupt most decoders. This is much like the way analog TV signals can insert color reference information and secondary audio program data in the vertical blanking interval if you are familiar with that. So this does not apply to what you are trying to do.
     
  11. Robert Owen

    Robert Owen TrainBoard Member

    51
    5
    6
    Is there a hardware description for DCCInspector-EX? I could only find software and the name of the ESP8266 WiFi board.
     
  12. FlightRisk

    FlightRisk TrainBoard Member

    548
    237
    14
    I have to finish the write up the web page still. See here:

    https://dcc-ex.com/reference/tools/diagnostic-tools.html

    Neil posted a lot on his blog with more detail that I have to fit into what we started. See here:

    https://wakwak2popo.wordpress.com/2020/12/11/dcc-sniffer/

    and here:

    https://wakwak2popo.wordpress.com/2021/01/28/stand-alone-dcc-diagnostics/

    There are several circuits and boards available to handle the DCC signal conversion if you want to pick the signal off the track. The key part is the high speed optoisolator. There is a very simple circuit that seems to work, though, and that is posted in Neil's blog also with a slow opto and not much else.

    The very simplest version is to just take an Uno, Nano, or Mega (we are adding more boards) and take the signal right off the signal pin used on the command station directly to the input pin on the sniffer. The signal from the Arduino that feeds the the motor shield is 5V. So for the STANDARD_MOTOR_SHIELD setting, that would be pin 12 on the Arduino Uno/Mega for the MAIN track signal (pin 13 is prog). You can clip onto it from the pin that is exposed between the Arduino and the Motor Shield, or use a jumper from that pin on the motor shield header to the input on the sniffer.

    The input you connect to on the sniffer:
    For Arduino Uno and Nano, pin 8; for Mega, pin 49. For the ESP8266/ESP32 it's GPIO2 (labelled D4 on the 8266 NodeMCU) Convert the 5V to 3.3V if you have a 3.3V board with a simple 2 resistor voltage divider! (I use a 5V nano).

    Neil is worse (better? ;) ) when it comes to experimenting. I was trying every combination I could think of and realized Neil had tried a few more and put it on the scope! Science!! I'll probably simplify a main option or two, then point to Neil's blog for all the experimental details. :)
     
  13. Robert Owen

    Robert Owen TrainBoard Member

    51
    5
    6
    Thanks FlightRisk. Very informative and helpful.
     
  14. Glenn Butcher

    Glenn Butcher TrainBoard Member

    167
    306
    9
    In the speed/dir packet, both the headlight and speed you want have to be encoded. When you sent the second packet to turn on the headlight, you also set the speed to zero.
     
  15. BigJake

    BigJake TrainBoard Member

    3,259
    6,172
    70
    LOL! I'm a retired electronics design engineer (mostly digital & FPGA, but enough analog to handle power supplies and various interfaces).

    I solved some of my thorniest problems, and developed some of my best solutions while laying in bed waiting to go to sleep!

    I remember once going to bed at ~11PM or so, then having a particularly fantastic Aha! moment, and being so excited I could not sleep, implementing the solution in my head, so I got dressed about 2AM and went in to work to get started implementing it! Two such moments led to breakthroughs to stuff "10 lbs" of functionality into an existing "5 lb" FPGA. The better solutions would have been to re-spin the boards with a bigger FPGA, but the schedule and budget (SWaP: Size, Weight and Power) would not allow that.
     

Share This Page