So the receiver beeps when it gets the command, but (correct me if I am wrong) it does not read back the value to ensure the CV was indeed updated?
And the beep comes from a Convrtr? or only the all in one G2 types? (receiver and decoder).
Sorry to ask so many questions, but it’s good to understand what really goes on.
I see what you’re asking now. I’m not sure if the decoder reads back from its own EEPROM and compares the value to what it wrote before acknowledging. I only have drop-ins here, so I haven’t observed the behavior of a Convrtr. I have a G3 on the way, but I assume that to be the same as the drop-in. I can see where this would be a bigger concern with the Convertr, since there is an additional DCC transmission between the Convrtr and a third-party DCC decoder. In that case, it would make sense for the Convrtr to read the CV to be sure that it was written. For the G3 and Drop-Ins, it’s a self-contained system, but there are two microcontrollers - one that handles the RF stuff (on a smaller PCB) and another that does the decoding, etc. I haven’t figured out the real division of labor - e.g. whether the first microcontroller actually does any manipulation of the data. The beeper is physically on the main board, and is driven by that microcontroller.
Holy #%^@!
You mean to tell me one of the largest selling wireless control solutions cannot provide feedback? I assumed given all the cheap bi-directional wireless communication solutions available, any system would include 2-way communication.
I currently have RailPro and get real-time reporting of virtually every setting. Volume, brightness, battery level etc. as well as status of turnouts. I thought everyone did.
On another post, Craig Townsend said “Maybe a givens and duthers list of wireless control needs to be started?”
I think this would be a good idea. It seems the current DCC wireless technology was designed for track power/Indoor operation. I understand HO is the bread and butter but maybe the venders need to know that battery powered outdoor large scale railroaders would have a different set of wants. I would think that ALL Garden railroaders using battery power would want to know the current battery status as well as the status of turnouts that are hidden from view. It’s 2018 folks! The technology is here!
Alexa, Uncouple loco 98!
There’s apparently several “trains of thought” here.
In service mode, you need to be able to read a CV value, without trying to set it. Even when setting, you want to read back to ensure it was set.
This is what I have been asking, basic STANDARD DCC functions. This is specified as part of the standard.
Modifying the system to work wireless has different flavors too, wireless from the cab to the command station, or trying to bypass the concept of a command station and transmit directly to a locomotive.
Now you have introduced another idea, status readback of other information wirelessly. The NMRA is working on a standard, and there is RailCom, and there is Digitrax Transponding. All of these could be made wireless.
Yep, it is 2018, but standards move slowly, especially since Europe basically split away from the NMRA and has their own standards group.
Greg
I can tell you definitively that there is no way to read a CV value. When you transmit a new one, the receiver/decoder does a blind write.
I don’t want this thread to turn into a comparison of systems, since there’s another thread going on that topic. But RailPro is an entirely different class of product. Pretty but proprietary. I like AirWire, and chose it, because it’s DCC and I can make my own stuff. That’s of little value to most people, but I appreciate it. On my GP9, for example, I have 7 different light circuits, a smoke circuit, and 2 remote couplers (a total of 10 devices). I was able to achieve this by tapping into the DCC lines to the sound board and using my own $2 Arduino to drive everything. The RailPro only has 6 outputs. There are pros and cons to each.
I have a speeder with a convtr and a TCS decoder for motor and lights. This goes back to previous posts about beeps from a convtr when changing a CV I just did a test in service mode and re-input CV1. No beeps but there were three definite pulses to the motor. Also with Airwire when I needed more outputs for lights or effects like gyra lights on Airwire decoders previous to G3’s I use TCS FL4’s connected to the Airwire DCC output along with Phoenix. This gives me four more programable on/off’s or light outputs.
The motor pulses must replace the beeper on those units. Good to know. And yes, that’s essentially the same approach I used to add lights. I just built my own function-only decoder.
Most decoders pulse the motor when accepting a CV change in service mode.
CVP site is back up, and I read the manual, wow really no information at all, it does not even educate the fundamental differences between ops mode and service mode.
OK, I’m educated… I think beeps only on G2 type decoders, not Convrtr
Greg
Folks, remember that up until the T-5000 throttle came out, Airwire didn’t have a transmitter that would be able to potentially display a CV read-back even if it could read them. If the transmitters couldn’t display the results, there’s not a lot of point in developing the technology to read them in the first place.
Having said that, I’m inclined to think there is some level of verification within the Airwire board of a successful write. Every now and then when programming one of my Airwire boards (1st generation), it will give me a longer constant tone for a second or two as opposed to a quick chirp when the CV value I’m programming did not take. I couldn’t begin to tell you what it’s looking for, but I programmed the CV again and it chirped quickly and the change was taken. I’ve not had this happen on my G2 or G3 boards, but that likely means I’ve just been able to successfully write every CV every time. The error “tones” on my 1st-gen board came when programming CVs on a decoder attached to the DCC output of the Airwire board, not the Airwire board itself.
With regard to the Convertr, it does not beep, pulse, or provide any other feedback to CV changes. Of course, its only CVs are related to the decoder address and Airwire frequency. It’s nowhere near as complex as the decoder attached to it. Feedback to CV changes written to the specific decoder attached to the Convertr will depend on that specific decoder. I’ve not seen any difference in that feedback whether a decoder is being programmed directly by a command station or wirelessly via a Convertr receiver.
Later,
K
What?
Sigh… the only way to know you have a successful write is to read back, and compare the value with what is written. Sorry, I am inclined to think you are wrong. (https://www.largescalecentral.com/externals/tinymce/plugins/emoticons/img/smiley-tongue-out.gif)(I just could not resist when you speculated this)
It may beep after executing the command, but that is not verification that the command successfully put the data into the CV, which was my point.
Also, the pulse comes from the motor outputs on the decoder, most decoders do this and I believe I stated this. Yes, of course the feedback depends on the decoder, but again, it just means that the decoder accepted a service mode command, again no verification that what you wrote got into the decoder.
If you are really interested in learning, you might try putting an illegal value into a CV in service mode on a real DCC system on various decoders, you will see the results vary, but some decoders will ack the command with the motor pulses.
Again, the feedback I was referring to, that you have apparently not seen, can be viewed by a normal DCC system, which does a read after write in service mode… (some cheaper systems do not do this, but with an NCE powercab system at under $200, I never recommend anything less)
Greg
p.s. the quest here is knowledge on how things work, not trying to protect AirWire from negative comments. DeadRail still needs more capability to be equal to “real” DCC.
My understanding is that the reason the decoder pulses the motor is that is how it sends the read back to the DCC programming track. There is no actual way for the decoder to “talk” to the programming track, but by pulsing the motor in a certain way, the programming track sees the current spikes, and reads the spikes. Kinda like a high tech Morse code.
This is why my one decoder could not be read. I had an open in the motor circuit. Once I fixed the broken wire (oops), then the programmer could “read” the decoder type, and CV values.
Yeah, the decoder has to create pulses on the rails, but the motor is not connected to the rails, so an interesting theory, but normally the motor pulses are to tell the consumer that things happened.
Remember, any connection between between the motor and the rails normally instantly destroys the H bridge.
Actually the reading of CV’s in service mode is pretty interesting:
Greg
Greg wrote: “It may beep after executing the command, but that is not verification that the command successfully put the data into the CV, which was my point.”
You missed what I was writing, then. I get two durations of “beeps” when programming my Airwire boards–a short “chirp” or a long “BEEEEEEEEEEEP.” The only time I get the long “BEEEEEEEEEEP” is when the data was not successfully written to the CV. I almost always check by running the loco to make sure the change took. “Chirp” = success, “BEEEEEEEEP” = failure. Without variation. You wrote “the quest here is knowledge on how things work.” That’s how my boards work. 
I haven’t a clue if the receiver itself is doing any kind of write-then-verify thing or if the long beep is just an alarm that goes off if it senses a corrupt command packet which would prevent the CV from being written in the first place. None of this is in any of the manuals. I just know “long beep = try again.” From an operator’s standpoint, that’s all I need to know.
Truthfully, this entire discussion is–for me–largely moot. I only have a few locomotives that still use Airwire boards which require service mode programming (and I’m done programming them!). Most of my DCC-based fleet now runs Convertr or Tam Valley Depot receivers tied to QSI, Zimo, TCS, or Soundtraxx decoders. I program those in ops mode via JMRI while the loco is running on the railroad. Outside of changing the decoder address, I have no need to even bother with service mode programming.
Later,
K
Hello - new member here, but long time modeler and maker. I came here after a search for airwire as I have successfully built the “Junior Throttle” airwire based DCC transmitter/receiver from Garden Railways 2014 issues. It was not an easy project, and yeah, the documentation was dodgy, but I’ve got four receivers and two throttles that work nicely. There was also a later post by a user who uploaded the source code for the project and modified circuits ( https://github.com/bdharrison/wireless-dcc ). I’m trying to figure out how to get serial communication out of the receiver to communicate with a raspberry pi zero w sound board .
Sean-
I have been vaguely aware of this article/project, but was never able to find a copy of it. Admittedly didn’t look that hard. I definitely didn’t realize that there was code online! That might have saved me some time.
You could certainly use my library with an Arduino to get serial data - either via USB, or just a logic level signal. Are you looking for raw packets, or do you want to do some decoding on the microcontroller before you send the serial data? There may even be a Linux DCC library available that you could use to decode the data directly from the radio module.
Let me know how I can help.
Eric
Sean- Thanks for posting the github link. Very Interesting. What are your plans on the Raspberry Pi side? I just ordered a zero with the bluetooth and wifi option. Cool little boards.
Thanks for the replies. As far as I can tell, the “Junior Throttle” uses the same RF protocol as Airwire, and claims to be compatible . The throttle project uses the TI MSP430 development board ( specifically the MSP-EXP430G2 ) to program and the AIR “shield” ( CC110L RF BoosterPack ) . TI has their own IDE and compiler, but there is an Arduino like IDE called “Energia” ( Arduino like is a misnomer, except for the red background it’s identical ) .
I’m using the Raspberry Pi as a sound device. I’ve played around with the Adafruit sound chips, but I’ve never been able to get a satisfactory loop, or been able to layer sound effects. The Raspberry Pi can use Python ( pygame specifically ) to mix 8 channels of audio. I’m hoping to be able to send a serial signal from the throttle micro controller to the Raspberry Pi to trigger the sounds. It would be nice to just use the Pi to decode the DCC signal as well, but from what I’ve read it’s not a great device when it comes to precise timing for signals. I’m trying to see if I can access the UART pins to talk to the Pi, without introducing timing errors in receiving and interpreting the DCC code.
You said the magic word - Python. And Pygame. I’m a big fan of both. I’m actually using pygame for Android to do phone apps. Wonderful package.
I can’t speak to decoding DCC with a Pi, I’ve avoided it for tight real-time stuff, I use Atmel chips for the nitty gritty. I would think that if the TI chip has a hardware UART you could easily load a character in just a micro second or two, via interrupt, between DCC bit times? Not sure. Looking at his code he does it a bit differently than I do. But it does look quite minimalistic, one would think there is a lot of spare time to be had in there.
Anyhow, thanks for the link, it’s nice to look at other code approaches. I don’t do much DCC decoding, I mostly go in the other direction for now. I also don’t use Airwire but I’m finding the descriptions and code samples that Eric has been posting very interesting.
I’ve been using the pigpio for timing-critical I/O stuff on the RPi: http://abyz.me.uk/rpi/pigpio/
I’ve not tried it for DCC, though. I was using it for Wiegand data from RFID readers, and it works well for that.
I think the simplest route to what you’re trying to accomplish is to use the Arduino library that I wrote (https://github.com/ereuter/AirDCC), an Arduino Pro Mini, and a CC1101 module. The Anaren modules are nice, but expensive. You can get cheap ones on eBay. My library handles the interaction with the CC1101, and then you can use a DCC library of your choice (either NmraDcc or DccDecoder) to handle the decoding, and route messages to the serial port.
Are you looking for function packets or accessory packets? The sample sketch included with the library is an accessory decoder. I have another sketch that scans all the AirWire channels and sends data to the serial port. That might be helpful as well. I need to clean it up a bit and comment it.
Eric
