Support - DCC Programming Track

Command Station Cannot Read CV's

Question: My command station says it cannot read, or has failed to write, the CV's in my TCS decoder. Why?

There are a few reasons why your command station may not be able to read CV values. Here are the top problems:

    Problem 1: Trying to program a sound decoder on a low-power program track without a booster.

Some systems on the market do not supply enough power for enough time on the programming track to allow for a programming operation to successfully take place. This is an issue especially for sound decoders or decoders with Keep Alive® which require more "juice" to program. This will result in erratic and periodic results of success or failure when reading or writing CV's on the programming track. The system may report errors such as "No Decoder," "No Ack," "No D," "No CV," etc. This issue can be solved in most cases with a programming Booster. In our experience, the PTB-100 from Soundtraxx is a reliable option when used with our decoders and Keep Alive® devices.

Command stations which continually supply power to the decoder when in programming track mode, such as the CS-105 and LT-50, are not susceptible to this issue. Other systems which do cut the power between each programming operation are far more likely to have reliability issues when programming. Adding a programming booster can help to overcome the issue of low voltages and inrush current requirements, but do not solve the core issue of the command station cutting power to the programming track between each operation.

    Problem 2: The motor is not connected to the decoder.

In order to communicate with the command station, a DCC decoder needs to generate a spike of current. This is done by pulsing the motor. If no motor is connected to the decoder, the decoder has no means by which it can "acknowledge" that a programming command has completed. Similarly, the decoder cannot communicate a CV value when requested that it be read. Therefore, it is important to make sure your motor connections are made and that they are free of short or open circuits. Shorts across the motor at this point can damage your decoder's motor outputs making them permanently unresponsive or run away! Open circuits will result in a similar lack of acknowledgement, and will also display an error on your system, but will not damage a decoder. For instructions on how to check your motor connections, visit the Multimeter Troubleshooting Guide on our website.

Excerpt from S-9.2.3, Section D of the NMRA Standards and Recommended Practices:

"Service Mode operations provide for an acknowledgment mechanism from the decoder to the command station/programmer. Acknowledgment refers to the ability of the Digital Decoder to respond to a Service Mode instruction issued by a Programmer. Service Mode instructions can be executed regardless of whether or not the acknowledgment mechanism is detected by the command station/programmer."

What does this mean? What this means, is that a command station or dedicated decoder programmer will always send programming commands, regardless of whether or not a decoder provides an acknowledgement. On the flip side, this also means that a decoder will also always accept and ac upon any programming instruction(s) received, regardless of its ability to provide an effective acknowledgment. Suffice to say, if you know your decoder is powered, receives a valid programming command, it will always accept that command (unless Decoder Lock is active).

If a decoder is not physically capable of providing an acknowledgement to the programmer/command station that it has completed a programming instruction successfully, your programmer/command station will most likely display an error message to you that the instruction failed. This error message can be false if the decoder successfully processed the command but was unable to provide an acknowledgement. If the decoder is not physically capable of providing an acknowledgement, and is being asked to read out the value of a CV, the programmer/command station will always produce an error message, as there is no possible way for the decoder to communicate with the command station.

    Problem 3: Locomotive is not on the programming track. (No, this is not a joke)

Without using a two-way communications method such as RailCom it is not possible to read CV values on your DCC mainline track. Writing CV's is possible, but not reading. This is because the command station and decoder do not have a method by which to communicate CV information on the main. Only command stations and decoders which support RailCom can communicate data on the main. If you are attempting to read CV values, place your model on the programming track first.

    Problem 4: The programming track is not physically connected to the programming track outputs from the command station.

On some DCC systems, your main track and programming track might be combined; however, most systems use a second set of connections for dedicated programming tracks. If you have not connected your programming track to these outputs, or if there is a loose/broken connection, your programming track will not function. If you use an isolation switch to swap between mainline and programming for the same section of track, ensure the switch is in the correct position. If Problem 1 also applies to you, ensure that your booster is connected properly, powered, and functioning properly.

    Problem 5: Decoder lock is active.

Decoder Lock is a NMRA standard which allows for a decoder programming to be "locked" and therefore disallowed. When a decoder is locked, all CV values other than CV 15 and CV 16 will report "Cannot Read CV" or similar. More information on Decoder Lock can be found in the NMRA CV Standards or on their respective pages on this wiki:

• CV 15 - Decoder Lock (Key)
• CV 16 - Decoder Lock (Lock)

Using JMRI Decoder Pro

Question: I use JMRI for my decoder programming. Does all of the above information still apply for programming tracks?

Yes! JMRI Decoder Pro relies on your command station to do all the heavy lifting of reading and writing CV's. All of the issues and advice above still applies even if you use JMRI to program your decoders.

However, it is also important to keep in mind that JMRI is constantly evolving, and is a program developed by volunteers. As decoder manufacturers such as TCS continue to release new Decoder Types, Versions, and features, those options will be added to the JMRI as "decoder definitions" over time. As such, it is imperative that you keep your Decoder Pro and JMRI software up to date with the current release. The latest bug fixes and decoder definitions can make the difference between quick success and endless frustration when programming a decoder.

JMRI Cannot Identify Decoder Type/Model

Question: Why can't Decoder Pro identify my decoder?

Reason 1 - Technical/Electrical Issue

See the above points about CV read-back and troubleshooting steps. Often the solution is a simple electrical or mechanical one, and no fault of the decoder. If you are having connectivity issues with your command station, visit the JMRI Helpdesk for support, or post a question on the JMRI User Forum

Reason 2 - Decoder Definition Missing

If your version of Decoder Pro does not have the specific decoder or decoder version available in its list of definitions, the program will not be able to successfully identify your installed decoder. Make sure that your JMRI version is up to date with the latest available. You can download the latest version from JMRI's Website

Decoder definitions are created through volunteerism, and as such not all products and decoder variants have definitions created. If you are technically savvy, you can even create your own decoder definition! For more information on decoder definitions for JMRI, Click Here!

Mainline Programming

Programming "on the main" is complicated for a few reasons. The first complication is that CV number 1 may never be programmed on a mainline in OPS mode - This is a DCC standard set by the NMRA. Therefore, if you plan to program a short address, you MUST use a programming track. If you want to program a long address into a decoder using your mainline, your command station may have provisions for this, or you need to do it manually using CV 17, CV 18, and CV 29.

An important consideration about Mainline Programming is that it is 100% reliant on the address of the locomotive/decoder to perform programming. Here are the potential problems with that:

• Having multiple decoder on the same address
• Having multiple decoders in the same engine (See Decoder Lock)
• Not knowing what the address is/Accidentally scrambled the address
• Selecting the wrong address and instead programming a different decoder by mistake
• Having no confirmation that the programming you attempted was successful (Not true if RailCom® is in use for mainline feedback)

When setting addresses, TCS recommends only using a programming track and never re-configuring the address on the main.

One benefit of mainline programming is the speed at which programming operations can be performed, since it is not necessary for the command station to wait for confirmation or read-back on each operation. Another benefit of mainline programming is that power is constantly applied, and the likelihood of the decoder failing to program because of the track power disappearing is near-zero. Unfortunately, the trade-off is that without the technology such as RailCom it is not possible to perform mainline program read operations. Mainline programming is only recommended for on-the-fly changes that need to be performed in real time or if you are experienced with CV programming.