Airwire CONVRTR Compatibility with the ProMini Air Transmitter/Throttle

As some of you may know from my previous postings or other sources, if you try “raw” transmission of DCC from standard DCC throttles, such as with the Tam Valley Depot DRS1 transmitter, to Airwire receivers, you probably won’t get consistent control – I didn’t. This failure set me on the road to devise the ProMini Air transmitter that would work with CVP Airwire receivers using DCC generated by standard DCC throttles, including the superb “open-source” WiFi-equipped EX-CommandStation created by the folks at Of course, the ProMini Air receiver is fully-compatible with Airwire throttles.

My web research and discussions with fellow dead-railers led me to believe you might solve the compatibility problem by providing frequent DCC “Idle” messages. Once the dust settled on the ProMini Air firmware we made available on our GitHub site, the ProMini Air transmitter worked pretty well with Airwire receivers! Besides CVP Airwire transmitters, the ProMini Air transmitter is the only currently-manufactured transmitter that works with Airwire receivers.

After this success, we have worked hard to ensure that the ProMini Air transmitter (and receiver) are compatible with multiple product lines, including CVP Airwire, Tam Valley Depot DRS1 transmitters and receivers, Gwire transmitters and receivers (available but no longer manufactured), Stanton Cab transmitters and receivers, and the no longer manufactured NCE D13DRJ.

OK, you may ask, what’s the point of this post? Well, I’d like to share some further research on the source of the CVP receiver’s incompatibility and its consequences on updates for the ProMini Air transmitter/receiver firmware.

Further Investigations

OK, I based our initial success in making the ProMini Air transmitter compatible with CVP Airwire receivers on observing how well the ProMini Air worked with Airwire receivers. Yep, numerous inserted DCC IDLE messages from the ProMini Air transmitter seemed to keep the Airwire receivers reasonably “happy,” responding to throttle speed/direction commands and function activation.

However, sometimes the Airwire receiver seemed a bit slow to respond to function activation… And some customers (who are hopefully still friends) sometimes noted this slow response. Could this be improved?

Still, I hadn’t analyzed what an Airwire throttle was sending in detail, so I purchased a simple logic analyzer from Amazon to look at the actual DCC transmitted by an Airwire throttle. I also needed the “pulseview” software from and a DCC decoder add-on. To properly analyze DCC, I modified the add-on and will make it available on our GitHub site.

The figure below is what I observed by firing up my original ProMini Air transmitter integrated with a WiFi-equipped EX-CommandStation, and using the iOS WiThrottle app to send throttle commands to a ProMini Air receiver. The figure below shows the “raw” digital output from the ProMini Air receiver’s transceiver.

The raw DCC data received by a ProMini Air receiver from a ProMini Air transmitter integrated with a WiFi-equipped EX-CommandStation

The waveform is what you would expect. A “one” end packet bit from the previous DCC packet and then a series of 15 “one” preamble bits followed by a “zero” packet start bit that signals to the decoder that a DCC command is coming. I observed no significant or consistent DCC “errors” in the collected data.

Here’s what the S 9.2 NMRA DCC Standard states about the preamble:

The preamble to a packet consists of a sequence of “1” bits. A digital decoder must not accept as a valid, any preamble that has less then 10 complete one bits, or require for proper reception of a packet with more than 12 complete one bits. A command station must send a minimum of 14 full preamble bits.

The data below is what I observed by firing up an Airwire T5000 transmitter and looking at the “raw” digital output pin from the transceiver (radio) on the ProMini Air receiver.

The raw DCC data received by a ProMini Air receiver from an Airwire T5000 throttle

Well, well. Now we see an NMRA-permissible (see line 121 of NMRA Standard S 9.2) but non-DCC transition pair, called a “cutout,” with a 1/2 “one” and 1/2 “zero” pair after a valid “one” end packet bit and before a very long (30 “one” bits) preamble. If you try to send shorter preambles, say 15 “one” bits, the Airwire receiver will NOT work consistently despite the NMRA standard stating that a decoder must not require more than 12 complete “one” bits in the preamble. So, the Airwire receiver is placing a non-standard requirement for a “long” preamble of “one” bits before it will operate consistently.

Timing of a 1/2 “one” and 1/2 “zero” cutout

While reviewing the DCC sent from an Airwire throttle, there were NOT an unusual number of DCC “Idle” messages sent by the Airwire transmitter. But, by sending tons of short (3 bytes) DCC “Idle” messages, the ProMini Air transmitter was sending just enough “one” bits to keep the Airwire receiver functional. I am not privy to the details of Airwire’s receiver firmware, so my success was based purely on empirical observation without underlying “insider” knowledge.

So what? With this knowledge, I felt it essential to make some ProMini Air firmware changes.

Firmware Changes to the ProMini Air Transmitter

Based on this new information, to improve compatibility with Airwire receivers, we have modified the ProMini Air transmitter’s firmware to ensure a 1/2 “one” followed by a 1/2 “zero” cutout comes after the end packet “one” bit, and before at least 30 “one” bits are in the preamble. This change is NOT harmful to other wireless receivers, including the ProMini Air receiver. The ProMini Air transmitter and receiver still insert DCC “Idle” messages when possible to keep decoders “happy” while waiting for valid DCC messages from the throttle.

Along with these firmware changes, which will be made available on our GitHub site, you can set the number of “one” bits in the preamble by going into OPS mode at address 9900 (transmitter) or 9901 (receiver) by setting the value of CV242. If you set the value of CV242 to 0, the firmware sets the number of preamble bits to a “reasonable” value of 16 (receiver) or the number of preamble bits the throttle sent (transmitter). If you set CV242 to less than 12, it will be reset to 12 to ensure decoders are “satisfied” with the number of preamble “one” bits.

You can also change the duration of the cutout’s second 1/2 transition with CV240. By default, a CV240 value of 27 makes the second 1/2 transition a “zero” with a duration of 116us. If you do NOT want a cutout inserted, you can set the CV240 value to 141, which will make the duration equal to that of the cutout’s leading 1/2 “one” (58us), resulting in an output 1/2 “one” and 1/2 “one” pair, simply increasing the number of preamble “one” bits by one.

Example CV240 values to control cutout duration

So, how well do these modifications work for Airwire receivers? It isn’t easy to quantify, but the Airwire receiver’s red data LED remains “on” more consistently with less “flicker,” and the receiver’s DCC output to the decoder contains “cutouts” (with a duration of about five preamble “one” bits) just before the preamble. These characteristics are now very similar to those from an actual Airwire throttle. See the comparison figures below. It’s difficult for me to test the more practical aspects of these improvements, but the decoders continue to operate as I would expect, perhaps with somewhat less time delay. Other users may be able to test under more stressful conditions.

CONVRTR DCC output to the decoder from an Airwire transmitter. The cutout duration does NOT matter to the decoder.
CONVRTR DCC output to the decoder from a PMA transmitter with updated firmware. The cutout duration does NOT matter to the decoder.


We now have a better idea why Airwire receivers do not work well with output from a typical, NMRA-conformant DCC throttle sent wirelessly and how to better cope with Airwire receivers’ unique DCC requirements by sending very long DCC preambles, preceded by a 1/2 “one” and 1/2 “zero” cutout.

Raw empiricism often leads you to workable, pragmatic solutions, but a little “looking under the hood” for the “how” and “why” almost always pays dividends. If you own a ProMini Air transmitter and are not satisfied with its performance with Airwire receivers, don’t hesitate to contact me about how I can provide you with an update to see if your performance will improve.

Author: Darrell Lamm

I earned my Doctorate in Physics from the Georgia Institute of Technology in 1982, and before retiring in 2019 I worked for 37 years at the Georgia Tech Research Institute. My last position was Chief Scientist of the Electro-Optical Systems Laboratory. Like many people, my love for model railroading began at an early age, and I rekindled that interest starting in 2017.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.