RailCom (NMRA S-9.3.2) lets decoders send their address back to the command station. With a local detector you know which block every loco occupies — without extra wiring.
DCC is inherently one-way: the command station sends drive commands and the decoder executes them, but no information returns to the command station. RailCom changes that. Under the official NMRA standard S-9.3.2 — formally titled "Bi-Directional Communication in DCC", developed by Lenz and submitted to the NMRA as an open standard — decoders can send data back over the same rails they run on.
The practical benefit: the command station, or a per-block detector, can see which loco address is in which block. This is a fundamental difference from ordinary current-sensing occupancy detection, which only reports presence ("something is in block 3") but not identity. RailCom adds the identity question: "which loco?" For an overview of occupancy detection without RailCom, see the feedback and occupancy detection guide.
The same rails that carry traction current and DCC packets must also serve as the return path. RailCom solves this with a brief interruption. After every DCC packet the command station pauses the DCC signal for a very short time — at most approximately 500 µs. This pause is called the cutout or gap. During the cutout the track voltage drops to zero; the decoder recognises the silence and uses those brief windows to transmit its data back via the rail conductors.
Normal operation is not noticeably affected: 500 µs is too short for the motor to respond and the pause falls comfortably within the normal DCC packet cycle. The prerequisite is clear though: only the command station can generate the cutout. If the command station does not produce a cutout — even if the decoder has RailCom built in — nothing can be transmitted back. The cutout is the key to the entire system.
RailCom defines two communication channels, each with its own purpose:
Channel 1 — unsolicited broadcast
The decoder automatically transmits its active address on every cutout, without the command station requesting it. This can be the short address (1–127), the long address or the consist address. Channel 1 is read by the local detector installed in the relevant block. As soon as a loco enters a block, the local detector records which address is present — this is the foundation of block-based loco identification and automatic train operation.
Channel 2 — on request from the command station
Via channel 2 the command station can address a specific decoder and request more detailed data: current speed, the value of a CV (Configuration Variable) or other status information. Reading a CV via RailCom is considerably faster than the traditional service mode, which requires the entire layout to be de-energised before a single value can be read back. Channel 2 is read by the global detector.
There are two types of RailCom detectors, each positioned differently in the system and reading different data:
Modern block detectors that combine occupancy detection with RailCom typically incorporate a local detector. See the feedback and occupancy detection guide for an overview of feedback buses and block detection.
The following command stations generate the RailCom cutout (broadly documented from manufacturer specifications):
| Command station | Cutout | Detector |
|---|---|---|
| Z21 black (Roco, art. 10820) | Yes | Global (built-in) |
| ESU ECoS | Yes | Global (built-in) |
| Lenz LZV (e.g. LZV200) | Yes — co-developer | Global |
| DR5000 (Digikeijs) | Yes | Global |
| DCC-EX on ESP32 + EX8874 | Yes (v5.6.0) | Depends on external detector hardware |
RailCom-capable decoders — including ESU LokPilot 5 and LokSound 5, Zimo MS and MX series, and most modern DCC decoders — typically enable RailCom via CV29 bit 3. Check the manual of your specific decoder for the exact CV setting. The DCC tools page includes a free CV29 calculator.
RailComPlus is an extension to the base protocol, developed by ESU and Lenz. Where standard RailCom reports the address, RailComPlus goes a step further: the decoder registers itself automatically with the command station, providing the loco name, function list and a command-station-assigned address. The user does not need to enter anything manually — the loco appears in the system as soon as it is placed on the track.
Command stations with RailComPlus support are the ESU ECoS and the Lenz LZV200 (and compatible Lenz systems). When a loco is placed on the layout for the first time, the command station identifies the decoder via the cutout, reads the loco data through channel 2 and automatically creates the loco entry. Not every decoder that supports standard RailCom also supports RailComPlus — check the product specification before purchasing.
RailComPlus and mfx do something functionally similar — a loco registers automatically with its name and functions — but the underlying protocols and ecosystems are entirely different:
They are not interchangeable: a loco with a RailComPlus decoder will not auto-register on a Märklin CS3; an mfx decoder will not register via RailComPlus on an ECoS. Choose the ecosystem that matches your command station. For more on protocol selection, see the DCC vs Motorola vs mfx guide.
ModelRailPro receives loco address data reported by the Z21 black via the Z21 LAN protocol. Display of detected RailCom addresses in the block view within ModelRailPro: To be confirmed on a layout
When the ESU ECoS is used (ECoS status "test" in ModelRailPro), processing of RailComPlus registrations is planned — locos that register automatically may then be created as loco profiles: To be confirmed on a layout
With DCC-EX on ESP32 + EX8874 (v5.6.0), cutout generation is confirmed. The full per-block address detection pipeline in ModelRailPro has not yet been verified on real hardware: To be confirmed on a layout
Need to set CV values or calculate the RailCom activation in CV29? Use the free DCC tools. Command station specifications are on the Z21 hardware page and the Lenz hardware page.
ModelRailPro