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 ProMiniAir 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 DCC-ex.com. Of course, the ProMiniAir 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 ProMiniAir firmware we made available on our GitHub site, the ProMiniAir transmitter worked pretty well with Airwire receivers! Besides CVP Airwire transmitters, the ProMiniAir transmitter is the only currently-manufactured transmitter that works with Airwire receivers.
After this success, we have worked hard to ensure that the ProMiniAir 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 ProMiniAir transmitter/receiver firmware.
Further Investigations
OK, I based our initial success in making the ProMiniAir transmitter compatible with CVP Airwire receivers on observing how well the ProMiniAir worked with Airwire receivers. Yep, numerous inserted DCC IDLE messages from the ProMiniAir 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 sigrok.org 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 ProMiniAir transmitter integrated with a WiFi-equipped EX-CommandStation, and using the iOS WiThrottle app to send throttle commands to a ProMiniAir receiver. The figure below shows the “raw” digital output from the ProMiniAir receiver’s transceiver.
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 ProMiniAir receiver.
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.
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 ProMiniAir 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 ProMiniAir firmware changes.
Firmware Changes to the ProMiniAir Transmitter
Based on this new information, to improve compatibility with Airwire receivers, we have modified the ProMiniAir 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 ProMiniAir receiver. The ProMiniAir 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.
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.
Conclusion
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 ProMiniAir 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.