Below is an explanation for why turning off DC mode in decoder prevents runaways.
The problem comes when a decoder on POWER UP must make a dramatic choice when it supports more than one operating mode based and do so on a limited time in which to get the information it needs to decide. Stated another way, if a decoder always operated one way and one way only (100% DCC) these runaway types of problems would disappear.
So what is the background of the problem?
To understand how the decision process even got started, we need to add some quick NMRA facts to this situation.
The DCC standard S-9.2, Section C translated says the decoder must make it's decision to switch to DCC within 30mS (0.03 seconds) after power is first applied. If it fails to detect DCC, it must then look at CV12 to tell if what the other (Alternate) "Power Source Conversion" mode it must choose.
The term "Power Source Conversion" means run under a different power source such as "Analog Mode" which is also know as "DC Mode". Go to the bottom of this web page if you want to read the actual wording of the DCC specifications.
That take away from this is the decoder has TWO operating power modes to choose from on power up. DCC and something else as defined by CV12.
What happens if the decoder does not support CV12?
If a decoder manufacture chooses to NOT support CV12, then the decoder manufacture must limit his Power Conversion options to one of two choices:
1) Do not support any power conversion (100% DCC only). Examples: Soundtraxx DSX and DSD decoders before Tsunami.
2) Go straight to the fixed and pre-determined Power Conversion Mode if no DCC detected.
What do MOST decoder choose for PowerConversion?
99.9% of the decoders make the alternative "Power Source Conversion" mode be DC Mode.
In other words, if there is no DCC detected, go to DC mode.
This is the ROOT CAUSE OF THE RUNAWAY PROBLEM.
What Triggers a Runaway if the decoder has DC mode Enabled?
If the decoder cannot detect a valid DCC signal and the 30mS timer has expired, the decoder MUST ASSUME it is DC power and jump straight to DC mode and NEVER looks back. So even is clean DCC power shows up after 30mS, it is to late. The decoder does not care anymore.
Now operating in DC mode and getting full DCC power, the decoder ASSUMES this to be full DC power and hence like a DC power engines would do, it tells the motor to go to full speed...You Have Your Runaway!
SOLUTION:
The only way to prevent this "runaway" situation from happening it to turn off BIT 2 in CV29 which is often simply called the "DC MODE" bit. This forces the decoder to stick with 100% DCC mode and never think twice about it.
Why does the decoder never look back?
To prevent the decoder from going "wacko" due to track noise creating corrupted DCC commands or signals that could mislead a decoder into yet another "Power Source Conversion" evaluation cycle. To prevent a potentially endless 2nd guessing what mode it needs to be in which in turn can prevent a smooth startup, the decoder "LOCKS" into the mode it detects on power up at the 30mS point as allowed by it settings.
However, the DCC Standard say decoders are allowed to do Power Conversion Modes on the fly.
That is correct they can IF they are designed to do that. The question is not so much can it be done, it is when should it be done and why.
For quick startup and maximum operational reliability on power up, locking the power mode in for a period of time or permanently is the best solution. But if the decoder has stabilized and operating just fine for a while, then the decoder has the potential to change is operating mode on the fly. It depends on what features the decoder wants to support.
Example: Some DCC decoders take full advantage of this changing power modes capability in the from of supporting features such as the "Brake On DC" function. This feature has the moving train exit DCC power track and enter a section of DC power track that is the lenght of the train. Once the decoder see pure DC, it checks it's CV 29 setting DC mode setting. The decoder knows it has not lost power since it making this decision while it is already running with DCC. If the Decoder has "DC mode" DISABLED, then the decoder knows that it must slow down per CV4 Deceleration rate and come to a complete stop. When DCC power is restored to the track, the decoder then starts to Accelerate per CV3 back up to normal track speed. No runaway and No loss of power in the process. However these operating conditions are NOT the same operating condition a decoder encounters on power up!
What does the different types of power on the track do to a decoder?
From a decoder electronics point of view, the type of power applied to the decoder on startup has no effect on its ability to get up and go in terms of the "decoder brain" (Microcontroller). The full wave bridge rectifier (4 diodes) converts anything and everything coming from the track into DC. That includes ANY noise that has some power behind it! So now that it is up and running looking at the track signal, the next decision to make is WHICH WAY to go.
So what are the source of noise and corruption?
Derailments resulting in random shorts, bad or defective boosters, poor layout wiring.
If your locomotive does not take off due to noise on power up, the next symptom of the SAME problem happens under derailment conditions.
Here we have a short circuit that is intermittent as the trains derails rolling down the track corrupting the DCC packets and killing power at the same time. All it needs is the right sequence of things to happen.
They are:
1) The short created by the small derailment kills power long enough for the decoder to reset
2) The momentum of the derailment partially restores power enough to power up the decoder moments later but NOT enough to prevent DCC packet corruption.
3) 30mS of garbage'd DCC packets the decoder does not understand means time is up and we jump to DC mode. (This can all happen without the booster shutting down because the booster shutdown takes a lot longer than 30mS. Typically it's about 10 times that period.)
4) If the engine manages to re-rail itself in this process...runaway!
If you run enough trains, I think everyone will eventually see this happening sometime.
Unfortunately this is not the worse thing that can happen. There are two other possible results from the same derailment event. They are:
a) Decoder looses it programming causing a decoder reset in which the
DC MODE bit assumes factory default (ON) and then runs away via steps 1 through 4 above.
b) A blown decoder that fails in such a way the motor takes off and/or just burns up.
Both of these involve aspects of track wiring.
What to the DCC standards Actually Say?
The DCC standard S-9.2, Section C says:
Manufacturers of decoders are encouraged to provide automatic conversion for a variety of power signals and command control formats in addition to the NMRA digital signal (per S-9.1), provided that automatic conversion to these alternate power signals can be disabled. If automatic conversion is enabled, Digital Decoders must remain in digital mode and not convert to using any alternate power signal so long as the time between Packet Start Bits is less than or equal to 30 milliseconds in duration. If automatic conversion is disabled, Digital Decoders must remain in digital mode regardless of the timing of Packet Start Bits. It shall be possible to configure Digital Command Stations to transmit at least one complete packet every 30 milliseconds as measured from the time between packet start bits.
The DCC standard RP-9.2.2, says:
Configuration Variable 12 Power Source Conversion
Contains the identity of the alternate power source to which the decoder will be converted should CV #1 contain all zeros. This is also the primary alternative power source selected should the decoder perform power source conversion. The currently assigned Power Source Conversion codes are listed in Appendix B of this Recommended Practice.
Appendix B:
The following Power Source Conversion codes (Binary) have been assigned by the NMRA Technical Department.
00000001 = Analog Power Conversion (DC mode)
00000010 = Radio
00000100 = Zero-1
00001000 = TRIX
00010000 = CTC 16 / Railcommand
00100000 = FMZ (Fleischmann)