For automatic operation or block control your software needs to know where locos are. Feedback bridges that information gap: from simple current sensing to per-block loco identification via RailCom.
You control a model railway from an app — but the app does not inherently know where a loco is. Drive commands go from the command station to the loco; in the reverse direction — from the layout back to the software — standard DCC is unidirectional. Feedback fills that gap. Without feedback you can drive and operate turnouts, but the software cannot react automatically to train positions: no block control, no automatic operation, no collision prevention.
There are two fundamentally different methods: current sensing (is there anything in this block?) and RailCom (which loco address is in this block?). Both can coexist on the same layout — current sensing handles occupancy, RailCom adds identity.
Current sensing relies on a galvanically isolated track section (block). One rail in the block is cut; the detector module sits in that break. As soon as a loco or vehicle closes the circuit via its wheels across both rails, a small current flows through the detection circuit. The detector recognises this current and reports: this block is occupied.
Advantages of current sensing:
Limitation: presence only, no identity. The software knows block 4 is occupied, but not by which loco.
Resistor wheel sets in wagons ensure that stationary, unlighted wagons are also detectable: each axle bridges the isolated rail through a small resistance (typically ~10 kΩ per axle). Whether the detector responds reliably depends on the minimum section length and the threshold of the specific module. To be confirmed on a layout
RailCom (NMRA S-9.3.2) goes a step further: the loco sends its own address back via the rails. The command station briefly interrupts the DCC signal (the "cutout", maximum ~500 µs) after each packet. During that interruption, RailCom-capable decoders transmit their address back. Local detectors per block read this message (channel 1) and therefore know which loco has entered the block.
This enables per-block loco tracking without separate inductive sensors. RailCom does require:
More on cutout timing, channel 1 vs channel 2, RailComPlus and which command stations support it: RailCom explained.
| Bus | Type | Max. inputs (typical) | Connector | Command station support |
|---|---|---|---|---|
| s88 / s88-N | Serial, daisy-chain | unlimited (chain) | Flat/IDC (s88) or RJ45 (s88-N) | Märklin CS2/CS3, Lenz, Z21 (via CAN), DCC-EX (via shield) |
| R-BUS | Proprietary Roco/Z21 | 160 (10 × 16 inputs) | RJ45 | Z21 black and white |
| LocoNet | Multimaster bus | very large | RJ12 (6P6C) | Uhlenbrock, DR5000, Z21 black |
| CAN (Märklin) | CAN bus over LAN | via Link s88 (60883) | RJ45 (LAN) | Märklin CS2, CS3 |
| XpressNet | Command bus (limited) | limited | RJ12 | Lenz, Roco multiMaus |
s88 is the most widely used feedback bus in the model railway hobby. The bus is serial: a clock pulse (CLK) shifts the occupancy status of all modules through to the command station. Each module has 8 or 16 inputs; modules are daisy-chainable to support a large total number of inputs. The signal format is straightforward and the technology has been stable for decades.
s88-N is electrically and functionally identical to s88, but uses an RJ45 connector instead of the older flat IDC connector. RJ45 cables are inexpensive and widely available. Important: the pin-out of s88-N differs from that of a network cable — do not use a standard Ethernet cable as an extension lead.
Märklin CS2 and CS3 use s88 via the Link s88 (item number 60883), which converts the s88 bus to the command station's internal CAN protocol. From the software's perspective, the CS2/CS3 receives s88 data via CAN and forwards it via CAN-over-LAN to the app.
The R-BUS is Roco's proprietary feedback bus, available exclusively on the Z21 family. R-BUS modules (such as item 10787) connect to the Z21 via RJ45; a maximum of ten modules per Z21 provides 160 detection inputs. Internally the Z21 converts R-BUS messages to Z21 LAN protocol, so ModelRailPro receives them via the standard Z21 connection without additional configuration. See the Z21 hardware page for the current ModelRailPro status.
LocoNet is a multimaster bus: each device on the bus can send messages without central arbitration. This makes LocoNet suitable for both drive commands and feedback on a single shared bus. Detector modules from Uhlenbrock (e.g. 63320) and Digitrax (BDL168) connect directly to the LocoNet cable using an RJ12 connector.
The DR5000 has two LocoNet ports: LocoNet B for boosters and LocoNet T for devices and detectors. The Z21 black (item 10820) also has a LocoNet port. Whether LocoNet feedback from the DR5000 (via Z21 emulation) appears as block occupancy in ModelRailPro is still to be confirmed. To be confirmed on a layout More about the DR5000: DR5000 hardware page.
Märklin CS2 and CS3 communicate internally via CAN bus. s88 modules connect to the CAN bus via the Link s88 (60883); the command station processes the occupancy status and forwards it via the CAN-over-LAN protocol to connected apps. ModelRailPro connects to the Märklin CS via this LAN protocol and receives feedback without additional per-module configuration.
XpressNet is primarily a command bus: it connects throttles and control panels to the Lenz command station and is also used by Roco multiMaus systems. Feedback via XpressNet is limited and is not the primary purpose of the bus. For reliable block detection in combination with a Lenz command station, s88 is the recommended choice.
In block control the layout is divided into sections. Each section has an isolated rail and a detector module. The software tracks which sections are occupied and sends drive commands based on that information: a train in section 3 may not proceed if section 4 is also occupied.
Current sensing is sufficient for this when you know which loco starts in which block. RailCom adds loco tracking, letting the software maintain which address is where — even after a session reset or with multiple locos running simultaneously. A practical guideline for layout design: define at least two block lengths per train length to enable effective stopping and waiting.
For fully automatic operation you need at minimum one occupancy detector per block. The more blocks you define, the more precise the position determination and the smoother the automatic driving behaviour. A command station comparison including feedback support is available on the Z21 vs ECoS comparison page.
ModelRailPro reads feedback via the protocol of the connected command station. The Z21 LAN protocol delivers R-BUS and CAN/s88 messages as numbered sensor events; you map these to blocks in the layout configuration. The Märklin CS connection receives s88 messages via CAN-over-LAN in the same way. See the hardware overview page for the current compatibility status per command station.
ModelRailPro