There have been a couple of vendor-specific technologies that allow a train’s DCC decoder to report information back to the command station (or to a computer). The NMRA is now working on a standard for this, and refers to this technology generally as “Decoder Transmission”. This is distinct from what decoders do on a programming track to report the value stored in CVs, although technologically there are similarities.
What the NMRA is working on standardizing is a system for decoder transmission developed by Lenz, under the name RailComm, although the standard has been in a draft state for years (it does seem to be making some progress). The current draft standard is RP-9.3.2 (PDF), dated May 2012, replacing a 2003 draft that apparently was never implemented.
With Railcom, in addition to the detector (and decoders that support it) you also need something called a “cut out” device on the power station’s output. This is built into Lenz’s power stations, and likely other new ones. But it needs to be added via an external device to older systems. And that’s the “gotcha”, despite being a monitoring system, RailCom does need to alter the command station output, and products that do that aren’t easily come by (and aren’t cheap). After surveying the existing products in 2012, I don’t think RailComm is quite ready for prime time yet. But it’s something I plan to keep an eye on.
Digitrax has a proprietary form of decoder transmission called Transponding, which works with their occupancy detectors and those of a few other companies. Few if any decoders other than theirs support it, however.
Digitrax’s transponding is something I spent a fair amount of time on, and there’s a description of that on my Occupancy Detection page and my BDL168 Testing page. Frankly I could never get it to work consistently or reliably, and eventually stopped trying. It’s not a bad system (assuming you can get it to work, and many apparently do), and if you’re already invested in it not likely to be worth abandoning. But the train has left the station on Decoder Transmission, and Transponding was left on the platform. RailComm is clearly the NMRA’s future direction, and as an open standard it’s likely to be everyone else’s direction, just the way DCC displaced a bunch of proprietary competitors.
Like Transponding, RailComm depends on decoders and detectors that support it. Further, as noted above, command stations and/or power stations (boosters) need to provide for the “RailComm Cutout” in their DCC signal, to allow trains an opportunity to transmit their information. If you have a RailComm-compatible command station, such as those made be ESU (ECoS) or Lenz, adding it isn’t too hard (but may be expensive).
Lenz makes a distinction between RailComm and RailComm Plus, the latter apparently allowing unsolicited transmissions from a decoder. I’m pretty sure the latter is what the NMRA is calling Decoder Transmission in their latest RP, and what most people are calling simply RailComm, which just adds some terminology confusion (should you shop for RailComm or RailComm Plus?).
A number of DCC decoders, unfortunately not including Digitrax, support RailComm. Lenz also makes a simple decoder that can be added to a train with an existing decoder that does not support RailComm, the LRC100, which retails for US$16-20 each in packs of 5.
Note: apparently back around 2003 Digitrax decoders wouldn’t work at all on a Lenz system with RailComm enabled. It’s unclear if that’s still an issue today but it seems unlikely that it would be.
For each block/zone where you want to be able to detect RailComm-equipped decoders, you need a detector. This splices into one of the feeder wires, and has some kind of bus connection to allow it to report back to a computer. Each manufacturer does their own bus.
UK firm DCC4PC sells a Local RailComm Reader that supports 16 zones for about US$209 list (£160 in their native U.K. due to VAT). It uses their Omnibus network, and a US$79 Computer Interface Device (UK£60 with VAT) is required. See their site for a list of suppliers. Note: I have no experience with these, and this is not a recommendation.
It’s not strictly a detector, but the ESU ECoS 50200 command station incorporates a “global” RailComm detector, so it can read back variables like fuel level from decoders that support this, and tell you what addresses are in use on the locomotives on the layout. They don’t apparently sell a standalone detector, not even for expanding their own system, which makes this of rather limited benefit.
The granddaddy of RailComm detectors, the LRC120 retails for around US$70 and detects trains in one block. It includes a simple four-digit display to show the address of the currently-detected decoder. As far as I can tell, all this can do is display the loco address on its display. There’s apparently no computer interface. This is one of their older “non-Plus” units.
Both a simple power-use occupancy detector and a RailComm detector, the LRC130 will support up to four blocks. And it communicates with a computer via their new RailCommbus (a USB interface is still required to the bus). Assuming it ever ships. It was apparently announced in 2010. I’m currently seeing it priced as “TBA” on a number of sites in January of 2013, and not offered for sale by anyone. At least at launch, this may be limited to Windows XP systems, although I’d expect JMRI support to happen fairly quickly. For Lenz, the LRC135 is a USB interface to their Railcommbus. It’s also not yet available or priced.
TAMS is a German company (German website). Their RCD-1 (US$40 built, also in kit form) is a one-block detector and their RCD-2 (US$62 built, also available in kit form) is a two-block detector. The RCD-2 can also control up to 8 switched outputs (for things like crossing-gate control, presumably). Both use their RC-Link USB computer interface (US$92) and their own bus (which may be limited to 24 detector modules, if I’m reading the translated German correctly).
Uhlenbrock is a German company, which can make finding and using their equipment a bit harder. But they do publish manuals in English and there are some sources accessible to English-speakers (see the Suppliers page). Their US$54 (list price in Euros converted to U.S.) MARco (product 68500), which I learned about from a review on this site, seems to be fairly new (it’s not listed as new by the manufacturer, but I can’t find it in any English-language store). But for U.S. modelers it’s very significant, as it is a RailComm detector that works with LocoNet as its communications method. Note that this does not remove the need for the command station to provide a cutout (see below); this device is only a detector.
If you don’t have a RailComm-compatible command station or booster, you’ll need to add something called a “cutout device”. This connects to the track output of the command station (you’ll need one for each booster if you have those) and briefly interrupts the signal at the allowed times to give decoders a time to send their information. Non-RailComm decoders should work fine with this as RailComm was designed to be backwards-compatible with older equipment (there’s some chance some older ones might not, and I saw one very old report about problems with Digitrax decoders and an earlier version of RailComm, but it seems to be fairly unlikely that this is a problem with the current RailComm and recent decoders). The problem lies in finding a cutout device: at present there’s only one supplier (in the U.K.) who wasn’t shipping when I first looked for these, and I was unwilling to buy a whole new command station just to experiment with RailComm. That derailed my initial plans to see how it works. It’s now available, so I may revisit this in a bit.
In addition to their detectors this UK company also makes a Cutout Device (which started shipping in January 2013, see links above) that can condition the output of a non-RailComm DCC command station. List price is US$79 (£ 60 in their native U.K. due to VAT).
TAMS makes a cutout-module, but it’s only for use with their own booster.
And that’s it. It’s clearly still early days for RailComm. I could probably run a RailComm-compatible Lenz booster off my Digitrax command station (Digitrax has instructions for doing just that on their website and these should apply to the current LV102 RailComm-compatible booster). But that requires buying a US$180 booster to replace the perfectly good power station built into my DCS100. And it assumes that the LV102 will condition a DCC signal from the DCS100 to add the cutout, which isn’t guaranteed (it depends on who creates the preamble bits, and how smart the LV102 is about processing them if it doesn’t create them). An $80 cut-out device is much more interesting.