Jim Betz explains the causes and remedies for these annoying decoder behaviors.

Our decoders are small computers. Every time they power up they go thru a "boot sequence". There are two things that happen during the boot up that depending upon the circumstances produce results we model railroaders scratch our heads about.

Why Do My Locos Run Away?

One of the earliest things the decoder does when it is powered up is to "check to see if the power is DC or DCC". Actually - it just checks to see if it is DCC and if it does not see the DCC packets it assumes what it is seeing is DC. When the decoder thinks the power is not DCC it behaves 'normally' for DC. Which means it checks CV 29 to see if DC operations are OK and behaves appropriately. All decoders do this test. And they all, essentially, do the same thing when the power is DC ... which is to "get out of the way and send whatever power is on the track to the motor - if DC compatibility is turned on (and with the polarity/direction of travel being determined by the power").

If the power is DC this is fine because the power has polarity and is "coming up to the current voltage setting of the power pack".

However - if the power is actually DCC what happens is that the loco will be fed full power in one direction - and it will take off like the proverbial Bat Out Of Hades. Only IF the decoder is set for DC compatibility (CV 29).

So the obvious question is "how/when does the decoder misdiagnose DCC as DC"? If the layout/track is currently powered by DCC ... but there is an intermittent short ... the decoder can get 'confused'/gets the wrong answer to the question "are there any packets in the power?". During a short the power does not come up smoothly every time. Some times it stops part way and restarts. If the decoder is checking for the DCC packets at the time the power is low/gone and then the power recovers quickly enough that it doesn't go thru the check again ... it can get the wrong answer. And no decoder that I know of ever "checks twice".

So what can you do to fix this? Do what all of the large layouts and clubs are doing!

  1. Turn OFF DC compatibility in all of your decoders!
  2. The use of the PSX series of circuit breakers has shown to provide a noticeable improvement.

Yes, that means that you have to "plan ahead" to run one of your locos on DC - because you have to use the DCC to reset the DC compatibility ... and then you have to set it back to "no DC" when you run it on DCC. But it is the only way to prevent these full power run always.

However - if you turn off DC compatibility you will NOT have any more runaways.

If you've ever seen a run away you know just how scary it is. Consider how devastating it would be if one of your most expensive or favorite locos or trains went to the floor ... do I need to say anything else to convince you that turning off DC is a good thing?

Why Do My Decoders Sometimes RESET?

The other thing that is done during the boot/power up of the decoder is to perform what is called a "CheckSum" against the part of the memory of the decoder that the CVs are stored in. If the CheckSum fails - it resets itself. It doesn't wait, it doesn't ask, it doesn't tell you it did it (it -can't- do any of these). The way you find out it happened is that the loco will not respond to the address you have programmed into it - it will respond to the "factory default" - which is address "3". This is known as a "spontaneous reset" because no one sent the reset command to the decoder.

The technical background for this is that whenever a change is made to any CV the decoder re-computes and stores a CheckSum value. And during power up (boot) the decoder recomputes the CheckSum value and compares it to the stored value. If it is different it resets.

Please understand - the way that the CheckSum works does not allow the decoder to know which value is 'wrong'. All it knows is that the two values(sums) don't match and its only recourse is to reset. The CheckSum is a "simple check" done by adding up the values of all of the CVs and storing that sum somewhere as "the stored Checksum". At least one of the reasons why the CheckSum can fail is - again - if the layout power is fluctuating due to a short i.e. the same source as the run always above. But any fluctuation of the 'quality' of the power can also cause any computer (the decoder is a computer) to not be able to compute correctly - and can cause errors.

What can you do about it? There is only one decoder family that I know of that has a solution for this problem. The QSI Revolution decoders provide a way to set the values in the "factory reset information" to your own choice of values. So what you can do is to get the loco running the way you want it, then use the current CVs to update the reset info. Then when it resets - it will set itself back to what you want it to (i.e. the same thing it was before the reset). This is a neat trick! In order to write those values to the reset info you have to use the QSI Programmer (which costs about $75 or so). (I'm hoping that the soon to be released QSI Titan decoders will also have this feature but don't know.)

There is one other thing you can do to help you deal with spontaneous resets. If you use DecoderPro you can save a 'roster entry' when you are done programming the decoder. Then, if a reset occurs, you can take the loco to the programming track and bring up the roster entry and do a "Write All Sheets" - which will rewrite all of the CVs back to what they were when you saved them in the roster entry. Also a neat trick!

Can I Eliminate the Shorts?

Both of the above situations point the finger at "a short occurring that affects the decoder". So the obvious question is "what can we do to prevent shorts?"

The answer to this is - regrettably - "not a lot". At least not as much as we would like to be able to do. But it is still worth trying!

The most common source of a short is someone running a turnout/switch. The next most common is when there is a derailment. Sooooo - yes, you can reduce the occurrence of shorts - by training your operators sufficiently that they will not run a turnout/switch ... as often. But you are never going to eliminate all the shorts caused by operator error. I like to use a simple rule of thumb - on the average about the best you can expect to achieve is that your operators, on the average, are going to cause about 1 short per hour per operator.

Some more than others, some less. BTW - this number is/was the same for DC. The only real difference is that under DC a short caused by one guy rarely affects another guy. But the number of operator caused shorts is high enough that it is a worthy goal to try to reduce them. And ... although it is difficult to do ... if you can get your "worst offenders" to improve you can reduce the number of operator caused shorts by a significant percentage. If you have a lot of "boomers" operating your railroad (operators who are not familiar with the layout - no matter how experienced they are at running trains) you will find that they tend to cause more shorts per operator per hour ... familiarity breeds competency.

The other source of shorts is derailments. Rigid track and equipment standards can help this one. A lot.
Even a lot higher percentage than you can eliminate the number of shorts caused by operator error. But again - even the best of layouts will have some derailments every operating session.

Both of these are worth while - and should not be avoided because they are difficult/take a lot of effort. Whatever you do to reduce shorts will result in a better railroad and better ops. And not just because you will eliminate run always and resets.

But if your crews are bugging you to "lay off" you may have already achieved all/most of the reduction that is possible.

ReCap/Best Practices

  1. Turn off DC compatibility in all your decoders.
  2. Use DecoderPro and/or QSI Programmer to "save the values of all of the CVs" - and recover them when a reset occurs.
  3. Train your crews to avoid running turnouts.
  4. Use standards to get your track and locos and rolling stock to operate as flawlessly as possible.

- Jim Betz