Cool. Are you looking to do an Airwire-compatible receiver, or a Airwire-compatible PC-based transmitter (or both?) With Tam Valley’s discontinuance of their DeadRail transmitters, there’s definitely a need for something that can take the DCC signal from JMRI running on a PC and send that directly to an Airwire-receiver-equipped decoder.
Later,
K
Eric Reuter said:
Success!
Bringing this along^^^^^ page 2 .
Eric you really need to find yourself a hobby!
(https://www.largescalecentral.com/externals/tinymce/plugins/emoticons/img/smiley-wink.gif)
One specific thing that I would like to do is build a low-cost accessory decoder for turnouts, etc. But the JMRI interface is definitely something I’ve been thinking about. Since I know now that the system just transmits raw DCC, alll of these things should be fairly straightforward.
A basic function decoder would be nice, too, for things like lights and remote couplers in cabooses or passenger cars. Lots of possibilities.
I have cobbled together a basic accessory decoder to demonstrate turnout/signal control.
I have dug into the CV programming, both Ops mode and Service mode, by logging tons of transmissions and comparing them to the DCC standards.
In ops mode, the messages are fully compliant, including the error detection byte. There’s no reason that JMRI or other software couldn’t program these decoders, provided one CV is updated at a time.
In service mode, it transmits CV values in direct mode, as would be expected for the normal method of programming. A transmission looks like this:
00000000 00000000 00000000
00000000 00000000 00000000
00000000 00000000 00000000
00000000 00000000 00000000
011111AA AAAAAAAA DDDDDDDD EEEEEEEE
00000000 00000000 00000000
00000000 00000000 00000000
00000000 00000000 00000000
00000000 00000000 00000000
That’s several reset packets, the programming packet, and several more reset packets.
The letters above mean:
AAAAAAAAAA: CV number - 1 (CV1 = 0000000000, CV2 = 0000000001, etc.) [10 bits]
DDDDDDDD: Value (0-255) [8 bits]
EEEEEEEE: Error Detection (bitwise XOR of previous bytes in message)
Next step is to create a decoder file in JMRI and give it a try.
Edit: Service mode is standard compliant. I was looking at paged mode earlier.
Eric, something I encountered while playing with wireless programming via JMRI… I’m using a Tam Valley Depot transmitter module attached to the output of a Sprog Nano. I can program decoders connected to Tam Valley Depot receivers all day long with no issues. The Airwire “Convertr” receivers do not recognize the output of the TVD transmitter as a valid signal, even though they’re on the same frequency. (The red “signal present” LED does not light up.) Both the TVD and Airwire receivers work with the Airwire throttles just fine. I haven’t had time to research why the Airwire receivers don’t like the TVD transmitter module output, since–in theory–it’s just passing through the DCC command packets. Note that the Convertr receiver didn’t like the output of the TVD transmitter module no matter which DCC system was feeding it. (MRC Prodigy, MRC Prodigy Advance2, Piko, or JMRI via Sprog Nano)
Just food for thought. You’re using your own receiver modules right now, but if you’re looking to broaden your scope, know that there are subtle differences in the receivers which may affect how they respond to different transmitters despite the frequency and command protocol being “the same.” (purposefully in quotes, because apparently there’s something different…)
(Oh, and the Tam Valley Depot Deadrail line of transmitters and receivers has been picked up by Dead Rail Systems, so it remains in production.)
Later,
K
My first guess would be that the Sprog Nano isn’t generating the error detection byte at the end of the packet. This is optional in the DCC standard, but AirWire receivers do require it to validate the packets. I don’t have a Convertr to test, but I suspect that it validates the packets before forwarding them to the attached decoder to improve reliability of decoders that don’t support validation. If the TVD receiver doesn’t care about the error detection byte, it would still be able to understand the Airwire throttle since the rest of the packet is identical.
The RF chip I’m using is the same as what all the CVP products use: TI CC1101. CVP uses the Anaren modules that prepackage it with an antenna/antenna connector, and I’m using a $3 version from China, but the guts are the same.
I get the same results from the MRC and Piko command stations as well as the Sprog, so if there’s something in the packet itself that the Convertr is looking for, it’s not seeing it from any of the command stations other than the Airwire transmitters.
Later,
K
If it’s anything, it’s the error byte. I don’t have enough experience with DCC in general to know whether it’s common to use it. It may be that nobody really uses it other than CVP. In a hardwired system, it would be far less important to validate the packets. I’ll have to put the scope on my NCE Pro Cab and see if they use it.
I have been looking at using DCC Plus Plus to bridge JMRI and the rf module, but it doesn’t generate error byte. I’ll have to modify it to do so. That shouldn’t be much trouble. It’s just an XOR of all of the previous bytes in the packet.
Homebrew AirWire servo control:
Cool, Is there a way to report back and display the current position?
No, the throttle is transmit-only.
Eric Reuter said:
No, the throttle is transmit-only.
Is there another throttle that would do it? I was thinking for a turnout or remote coupler I would like to know what the current position is. Real-time would be great but I suppose you could at least display the last command sent?
Good question. None of the AirWire products are bi-directional, and the throttle doesn’t display the last transmitted state for either functions accessory commands. I agree that that would be a nice feature. I have remote couplers on a couple of my engines, and the lack of feedback is annoying. I’ve thought about putting an LED on the engine or something to indicate when the coupler is open.
I thought AirWire did bidirectional in service mode?
Greg
It does; the other direction is acoustic (beep!). Seriously, though, I haven’t seen the T5000 throttle put the modem into receive while in service mode.
So, service mode cannot read back a CV value?
The beep is from where?
Tried to look up the manual, I know you can enter service mode, but not being able to read back a CV value is unbelievable.
But www.cvpusa.com is down and was down yesterday too… hmmm…
Greg
The receiver beeps (at least the current versions) to confirm that a CV has been written. There is no way to read a CV back from the decoder. That’s why they give you a little record sheet at the back of the manual to write down the values you program. I agree that it’s not ideal.
The hardware is all capable of two-way communication, but I haven’t seen any evidence that it’s used.
Interesting, so the beep really only means that the transmitter has sent a command, no guarantee it was received?
My fault for not knowing this, I was told service mode “worked”, and I assumed it met NMRA specs, i.e. you could read back…
ouch…
Greg
It’s the receiver that beeps, acknowledging receipt of the value. I haven’t done a lot of programming, but what I have done has worked fine. If you scroll up a bit, I posted what is actually transmitted in service mode.
