Dealing with Decoder “Boot-up Jerk” Behavior when Using the ProMini Air Receiver


I have the benefit of some beta great testers for the ProMini Air receiver, and one of them has reported an issue that I’d like to show you how to address.

The problem is this: when you first power up the locomotive (and the onboard ProMini Air receiver and its DCC amplifier), sometimes the locomotive briefly “jerks” before “settling down” with standard control by wireless DCC commands. Uh oh.

The Cause of the “Boot-up Jerk”

The ProMini Air receiver uses a Pro Mini Microcontroller Unit (MCU) with “bootloader” firmware. Now, bootloaders are useful because they allow you to download the firmware with a simple and inexpensive “FTDI” break-out board that connects between your computer (via USB) and the ProMini MCU (via its 6-pin connector on one end of the board). You use the FTDI board as described in my previous post to very simply download firmware updates using the Arduino IDE.

As useful as boot loaders are, they have downsides: they consume memory (not a problem for us here), and they consume time on boot, which IS a problem for us. The latest versions of the software/firmware for the ProMini Air receiver have reduced the boot-up time significantly from previous versions. Still, you just cannot get around the time consumed by the bootloader during boot-up.

The boot-up process does not take long: less than two seconds, but during that time delay, the Pro Mini MCU is sending out a zero control voltage to the DCC amplifier. Well, what does the DCC amplifier do with this zero input voltage? Plenty. The DCC amplifier’s job is to convert 5V “logic-level” DCC to DCC Track Right/Track Left, each with an opposite “polarity” from the other. With a “low” input from the Pro Mini MCU, the DCC amplifier outputs a “high” voltage on one track output and a “low” voltage on the other.

Once the DCC amplifier sends this brief but steady high/low pair of voltages to the DCC decoder, this is where the fun begins. DCC waveforms are a sequence of pairs of high/low or low/high pulses with a total duration of about 116 microseconds to encode a DCC “1” and about 200 (or more) microseconds to encode a DCC “0”. I’ll resist the temptation to discuss DCC waveforms and how they make up a DCC “packet” that is a complete command to the decoder. Suffice it to say, the output from the DCC amplifier does NOT look like a DCC waveform for the brief period of time while the ProMini Air boots up!

For some configuration settings, the DCC decoder will interpret the “boot-up DC” from the ProMini Air receiver/DCC amplifier as a command to proceed while the DCC decoder is waiting for DCC packets to show up that will tell it how to behave – thus, the “boot-up jerk.” This temporary “DC command to proceed” doesn’t last long, but it’s undesirable behavior.

The Solution(s)

I will provide two solutions to the “boot-up jerk.” The first involves setting decoder Configuration Variables, and the second involves reloading the Pro Mini MCU firmware is a special way.

Solution #1

DCC decoders are familiar with what to do with inputs that “look” like DC inputs, and how they respond is controlled by how you configure the DCC decoder.

First, we’ll talk about what DCC decoders might do with brief DC inputs, and then we’ll talk about how to change the configuration. Some DCC jargon will be unavoidable.

The user controls the configuration of the DCC decoder by “programming” the values of configuration variables (CV) persistently stored in the decoder. You may “program” the decoder in several ways, but perhaps the simplest is called “Programming on the Main” (PoM) that virtually all DCC decoders will accept. In this mode, you can stop the locomotive (you’re not required to do so, but I do), and then place the DCC throttle into “PoM” mode. You then select a CV number (a value that is usually between 1 and 512 or so), and then you enter the value (always a number between 0 and 255) that goes into the CV’s “slot.”

One of the essential Configuration Variables for a DCC decoder is CV29. Inside CV29’s value (which is only one byte, or a sequence of eight ones and zeroes, in size) are several vital settings such as using a short or long address (bit 5 = 0 (short) or 1 (long)). Our interest is in bit 2 of CV29. If CV29, bit2=1, then the decoder will accept “analog” input as a power source, which causes the “boot-up jerk” problem because CV29, bit2=1 tells the decoder it’s OK to act on non-DCC inputs; e.g., DC input.

If, however, you set CV29, bit2 to 0, then the decoder ignores many forms of “non-DCC” input, including the “boot-up DC” we’ve been discussing. I say “many,” but not “all,” because users sometimes set CV27 bits for fancy “braking” schemes, where the locomotive will stop or continue if it senses the discontinuance of DCC waveforms and senses DC on either the left or right rail. These CV27 options, however, are supposed to come into play after DCC has been received for some time and then receives DC (“DCC before DC”), which is NOT the circumstances we are trying to handle of “DC before DCC.”

So, that’s Solution #1: set bit2 of CV29 to 0 (CV29=binary 00xxxx0xx where x might be 1 or 0 depending on the desired configuration controlled by CV29). You should exercise great care should when changing the value of CV29. You can cause the addressing scheme to switch from long address to short or vice versa by changing CV29, bit5, in which case the decoder will no longer respond to the previous address! Please be careful! Regardless of what else you are doing, if you are using a long address, MAKE SURE THE VALUE OF CV29 is EQUAL TO OR BIGGER THAN 32 (32=binary 00100000) AND LESS THAN OR EQUAL to 63 (63=binary 00111111)!!! If you are using a short address, MAKE SURE THE VALUE of CV29 is LESS THAN OR EQUAL to 31 (31 = binary 00011111)!!! We are dealing with multi-function decoders, so bits 6 and 7 are not relevant to us, and you should set both bits to 0.

Some of the user interfaces for programming decoders, such as ESU and Zimo, can set CV29, bit 2 for you but couch the change in various ways, with options such as turn on/off responding to “Analog DC” and “Digital DC” (whatever that difference means). For instance, when you turn off the responding to “Analog DC” and “Digital DC” using ESU’s LokProgrammer, the software sets CV29, bit2 to 0, and sets CV50 to 0. Taking a careful look at your decoder’s user manuals may help set other CV’s that might be involved. Usually, however, only setting CV29, bit2=0 takes care of the problem.

Just for fun, here is what the NMRA Standard S-9.2.2 says about CV29:

Configuration Variable 29 Configurations Supported

Bit 0 = Locomotive Direction: “0” = normal, “1” = reversed. This bit controls the locomotive’s forward and backward direction in digital mode only. Directional sensitive functions, such as headlights (FL and FR), will also be reversed so that they line up with the locomotive’s new forward direction. See S-9.1.1 for more information.

Bit 1 = FL location: “0” = bit 4 in Speed and Direction instructions control FL, “1” = bit 4 in function group one instruction controls FL. See S-9.2.1 for more information.

Bit 2 = Power Source Conversion: “0” = NMRA Digital Only, “1” = Power Source Conversion Enabled, See CV#12 for more information,

Bit 3 = Bi-Directional Communications: “0” = Bi-Directional Communications disabled, “1” = Bi-Directional Communications enabled. See S-9.3.2 for more information.

Bit 4 = Speed Table: “0” = speed table set by configuration variables #2,#5, and #6, “1” = Speed Table set by configuration variables #66-#95

Bit 5 = “0” = one byte addressing, “1” = two byte addressing (also known as extended addressing), See S 9.2.1 for more information.

Bit 6 = Reserved for future use.

Bit 7 = Accessory Decoder: “0” = Multifunction Decoder, “1” = Accessory Decoder (see CV #541 for a description of assignments for bits 0-6)

*Note If the decoder does not support a feature contained in this table, it shall not allow the corresponding bit to be set improperly (i.e. the bit should always contain its default value).

I hope you’re happy I interpreted the standard a bit for you.

With Solution #1, all DCC decoders I’ve tried (ESU, Zimo, MTH) start-up without the “boot-up jerk,” even though the brief “boot-up DC” is present.

Solution #2

So what’s solution #2? Reload the firmware into the Pro Mini MCU using an “AVR ISP,” such as the Sparkfun Pocket AVR Programmer or a less-expensive clone. This “ISP” downloading mode will bypass and erase the bootloader to directly load the firmware into the Pro Mini MCU. On boot-up with the bootloader now erased, the Pro Mini MCU will almost instantly supply “5V logic DCC” to the DCC amplifier, which in turn, provides the DCC decoder with standard DCC waveforms. There is no “boot-up DC” to speak of and no need to set CV29, bit2=0. (I set it anyway.) With Solution #2, all DCC decoders I’ve tried (ESU, Zimo, MTH) start-up without the “boot-up jerk.”

This “ISP” form of loading firmware is not as extensively used by folks using the Arduino IDE, but ISP loading is easily accessible within the Arduino IDE. The overly-brief method of ISP programming steps are the following:

1. Connect the USBtinyISP Programmer to the following six Pro Mini pins: GND, RST, VCC, SCK (pin 13), MISO (pin 12), and MOSI (pin 11). Be sure the “power the target” switch is set so that the USBtinyISP will supply power to the Pro Mini MCU. I have developed a very simple Pro Mini ISP Programming Board that I will make available at a nominal cost (<$3.00+shipping). This board has a pair of pins for optional GND/VCC power input because some ISP programming boards, unlike the USBtinyISP, do NOT provide +5V DC power.

Pro Mini MCU connections to a USBtinyISP for loading firmware without a bootloader.
Pinout for USBtinyISP programmer.
USBtinyISP connections to the Pro Mini MCU using a programming board available from the author.

2. From the Arduino IDE, Select Tools → Programmer → “USBtinyISP”

3. Select the AirMiniSketchTransmitter sketch.

4. Select Sketch → Upload using a Programmer.
The Arduino IDE will then compile the sketch and download the resulting firmware to the Pro Mini via the USBtinyISP, bypassing (and erasing) the bootloader. 


So there you have it: a “start-up jerk” problem caused by the bootloader time delays of the ProMini Air receiver’s MCU and two solutions that I know to work for at least several brands of DCC decoders: ESU, Zimo, and MTH. Other brands should work with either solution as well.

What’s my choice? Go with Solution #1 if you can. Setting the CV’s is pretty straightforward. Downloading firmware is more challenging but more “guaranteed” to work. We try to make everyone happy.

In the future, if you obtain the ProMini Air kits from either BlueRidge Engineering or by contacting me, you will be given the option of whether we provide a Pro Mini MCU with the bootloader or not.

Thanks for stopping by!

Dealing with Loss of RF Signal in Dead-Rail for Onboard DCC Decoders

Note: This post deals with details of various brands of DCC-compatible, wireless RF receivers operating in the 902-928 MHz “ISM” band that connect to onboard DCC decoders. Some aspects of the discussion may apply to other RF bands as well.

Typical application. In some cases, such as the Airwire transmitters, the throttle and transmitter are combined. Also, the receiver and amplifier may combined, such as for Airwire and Tam Valley Depot receivers.

The designers of various DCC-compatible RF receivers have a couple of strategies for what output to provide to the onboard DCC decoders when a valid RF signal is lost:

  1. Output the random pulses that the RF receiver naturally outputs when a valid RF signal is lost. This option will cause most DCC decoders to maintain direction and speed while the DCC decoder “sifts” the random pulses searching for valid DCC packets.
  2. Output a fixed, positive Direct Current (DC) voltage to one of the DCC decoder’s “Track” inputs and a zero voltage DC the other “Track” input when either a) RF signal is lost, or b) when the RF transmitter does not send sufficiently-frequent “keep-alive” DCC packets. The latter is true for the Airwire CONVRTR. How the DCC decoder responds to these DC “Track” inputs depends upon DCC decoder configuration and, unfortunately, DCC decoder manufacturer discretion.

There are several NMRA-specified Configuration Variables (CV’s) that affect how DCC decoders handle the loss of valid DCC packets and are important to understand when the DCC decoder is connected to the DCC output of DCC-compatible RF transmitters because the RF receivers may lose or receive corrupted RF signal from the dead-rail RF transmitter.

The NMRA standard S-9.2.4, section C “Occurrence of Error Conditions” states “Multi Function Digital Decoder shall have a Packet Update time-out value.” Further down on line 60 the standard states “A value of 0 disables the time-out (i.e., the user has chosen not to have a time-out)”. This part of the NMRA standard is not universally-implemented by manufacturers, and it affects how decoders will respond to the loss of RF transmission of DCC packets. To implement this requirement, the NMRA standard S-9.2.2 has defined the recommended (R), but not mandatory (M), CV11, Packet Time-Out Value. A value of CV11=0 is defined to turn off the time-out, but CV11 is frequently not implemented.

However, another CV that is often implemented addresses some aspects of loss of DCC. The optional (O) CV27, Decoder Automatic Stopping Configuration, is under re-evaluation by NMRA, but the NMRA has taken no definite action some time. Here is what the NMRA standard S-9.2.2 currently (as of 2019) states about CV27: 

Configuration Variable 27 Decoder Automatic Stopping Configuration
Used to configure which actions will cause the decoder to automatically stop.

Bit 0 = Enable/Disable Auto Stop in the presence of an asymmetrical DCC signal which is more positive on the right rail.
“0” = Disabled “1” = Enabled

Bit 1 = Enable/Disable Auto Stop in the presence of an asymmetrical DCC signal which is more positive on the left rail.
“0” = Disabled “1” = Enabled

Bit 2 = Enable/Disable Auto Stop in the presence of an Signal Controlled Influence cutout signal.
“0” = Disabled “1” = Enabled

Bit 3 = Reserved for Future Use.

Bit 4 = Enable/Disable Auto Stop in the presence of reverse polarity DC.
“0” = Disabled “1” = Enabled

Bit 5 = Enable/Disable Auto Stop in the presence forward polarity DC.
“0” = Disabled “1” = Enabled

Bits 6-7 = Reserved for future use.

Since DCC decoder manufacturers frequently do implement CV27, what electrical output the DCC-compatible RF receiver provides to the DCC decoder upon loss of a valid RF signal will influence how the DCC decoder responds. We will break this down for various brands of DCC-compatible RF receivers in the 902-928 MHz ISM band in the following subsections.

Note that some DCC decoders will not honor CV27=0; i.e., all auto-stopping features disabled. For example, with CV27 set to 0, the Zimo MX-696, and probably other Zimo DCC decoders as well, will continue speed and forward direction if positive DC level is input to the “Right Track” DCC input, and a zero DC level is input to the “Left Track” DCC input. Under these “track voltage” conditions, the locomotive will stop if originally moving backward. Some (but not all) DCC-compatible RF receivers, such as the Airwire CONVRTR, provide these DC inputs, if a valid RF signal is lost, but only if connected correctly.

The “correct” connection relates to how the user connects the DCC output from the RF receiver to the “Track Right” and “Track Left” inputs of the DCC decoder. Under normal circumstances, when there is a valid RF signal, which way the DCC decoder connects to the RF receiver does not matter. Under the exceptional case of DC-only output by the RF receiver, if it loses a valid RF signal, which way the DCC decoder connects to the RF transmitter does matter. The user will likely want the locomotive to continue forward with the loss of a valid RF signal, so some experimentation is required to determine which of the RF transmitter DCC outputs should connect to which of the DCC decoder’s “Track” inputs to achieve the desired behavior.

Example DCC waveform output from a DCC-compatible RF receiver when there is a valid RF signal
Example random pulse output from a DCC-compatible RF receiver when there is no valid RF signal. Note the waveform’s superficial similarity to valid DCC output.

As a further complication, the user should probably turn off the decoder’s “analog” mode of operation by setting Bit 2 of CV29 to 0 to force the decoder to use “NMRA Digital Only” control of ”Power Source Conversion” (see the NMRA standard here). If Bit 2 of CV29 is set to 1, and again we emphasize the user should probably not activate this feature, then “Power Source Conversion Enabled” and then CV12 determines the power source; the most common of which is CV12=1, “Analog Power Conversion.”

Airwire CONVRTR Series

CVP Airwire CONVRTR-60X tender installation. The CONVRTR operates on Airwire channels 0-16. Note that the U.FL antenna lead was later connected to the CONVRTR. The LokSound L V4.0 DCC decoder mounting harness can be seen mounted on the tender wall opposite the CONVRTR, and its Track Left/Right inputs are connected to the CONVRTR-60X’s DCC A/B outputs.

When the CVP Airwire CONVRTR loses a valid RF signal or receives insufficiently-frequent DCC Idle packets, it detects these conditions and outputs a fixed DC voltage to the decoder. Consequently, the user should set CV27 according to the description above.

While it may seem that the user would want the locomotive to stop if its RF receiver loses a valid RF signal, consider what might happen in tunnels or locations remote to the DCC RF transmitter. Getting stuck under these circumstances if a valid RF signal is lost is probably not what the user wants, so we strongly suggest that the user set CV27=0.

The user is cautioned, however, that some DCC decoders, such as the new ESU LokSound 5 L DCC, do not honor the CV27=0 setting unless the “polarity” of the “Track Right/Left” is connected “correctly” to the CONVRTR’s “A/B” output. Experimentation may be required to determine the correct connection, but my experience is: CONVRTR A <–> Decoder Track Right & CONVRTR B <–> Decoder Track Left

QSI Solutions Gwire and Tam Valley Depot DRS1 Series

The QSI Solutions GWire operates on Airwire Channels 0-7. If the U.FL plug (at the upper-left corner of the Linx Transceiver chip) connects to an externally-mounted antenna, the antenna wire at the upper-left corner of the GWire board should be cut off at board level, or better yet, unsoldered.
The Tam Valley Depot DRS1, MKIII, operates on Airwire Channel 16
The Tam Valley Depot DRS1, MkIV, operates on Airwire Channels 0-16 (as well as other frequencies). Note the internal antenna on the right-hand side of the board.

The QSI Solutions Gwire and Tam Valley Depot DRS1, MkIII and MkIV DCC-compatible RF receivers will output random pulses to the onboard DCC decoder when a valid RF signal is lost, so setting CV27 is probably of no use. On the “plus” side, most DCC decoders will maintain locomotive direction and speed in the presence of these random pulses since the DCC decoder is actively sorting through these pulses for valid DCC packets, which is usually the behavior the user wants.

A Blueridge Engineering webpage describes how to easily modify the GWire for use as an RF receiver for any onboard DCC decoder.

Blueridge Engineering ProMini Air Receiver

Blueridge Engineering ProMini Air receiver operates on Airwire channels 0-16. The ProMini Air can also be configured to operate as a DCC-compatible transmitter that wirelessly transmits DCC from any DCC source on Airwire channels 0-16.

The Blueridge Engineering ProMini Air receiver has a default long address of 9001. Like the ProMini Air transmitter, the ProMini Air receiver’s channel can be reset in “OPS Mode” by setting CV255 to a value in the range of 0–16. The ProMini Air receiver has the following options when a valid RF signal is lost:

  • Output random pulses to the onboard DCC decoder: The user can set the ProMini Air receiver to output the random pulses when it loses a valid RF signal by setting CV246 to 0 in “OPS mode” at the ProMini Air’s address. In this case, setting CV27 for the onboard DCC decoder is not relevant, because the random pulses from the ProMini Air receiver will cause the onboard DCC decoder to maintain speed and direction of the locomotive while it is “sifting” through the random pulses for valid DCC packets.
  • Output either fixed positive or negative voltage DC to the onboard DCC decoder: In this case, setting CV27 for the onboard DCC decoder at its address is relevant. The user can set the ProMini Air receiver to output fixed DC voltage when it loses a valid RF signal by setting CV246 to 1 in “OPS mode” at the ProMini Air’s address. A positive DC voltage is output by setting the ProMini Air receiver’s CV248 to 1 in “OPS mode” at the ProMini Air’s address, or a negative DC voltage is output by setting CV248 to 0. If the user does not want the locomotive to stop with the loss of a valid RF signal, then set CV27=0 for the onboard DCC decoder at its address. Of course, setting CV27 to other values (see above) in the DCC decoder will determine how the DCC decoder responds to the fixed DC voltage that the ProMini Air outputs to the onboard DCC decoder upon loss of a valid RF signal.


It’s an unfortunate fact of life that we can lose a valid RF signal from our DCC-compatible transmitter. However, with a little study of DCC decoder documentation, and possibly a bit of experimentation, gracefully coping is definitely possible.