Introduction
I have the benefit of some great beta testers for the ProMiniAir 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 ProMiniAir 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 ProMiniAir 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 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 simply download firmware updates using the Arduino IDE.
As valuable 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 ProMiniAir receiver have reduced the boot-up time significantly from previous versions. Still, you cannot get around the time the bootloader consumes during boot-up.
The boot-up process takes less than two seconds, but during that time delay, the Pro Mini MCU sends 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, 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 a brief period while the ProMiniAir boots up!
For some configuration settings, the DCC decoder will interpret the “boot-up DC” from the ProMiniAir receiver/DCC amplifier as a command to proceed. At the same time, the DCC decoder waits 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 consists in reloading the Pro Mini MCU firmware specially.
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), which 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, the decoder ignores many forms of “non-DCC” input, including the “boot-up DC” we’ve discussed. 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). It would be best if you exercise great care when changing the value of CV29. You can cause the addressing scheme to switch from a long address to a short one 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 irrelevant 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 turning 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 CV50 to 0. Taking a careful look at your decoder’s user manuals may help set other CVs that might be involved. Usually, 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, providing 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 straightforward 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.
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.
Wrap-Up
So there you have it: a “start-up jerk” problem caused by the bootloader time delays of the ProMiniAir receiver’s MCU and two solutions 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, and Downloading firmware is more challenging but more “guaranteed” to work. We try to make everyone happy.
In the future, if you obtain the ProMiniAir 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!
