Because all Boys (and some girls) love Trains

DCC Control and Feedback Bus Systems

DCC Control & Feedback Bus Systems

While the DCC Protocol is generic and standardized by the NMRA, there are quite a number of different  Control and Feedback bus systems on the market.

Edited & Reviewed: Stéfan Stoltz

Some of these are proprietary and specific to equipment made by one vendor, while others are either fully open standards or proprietary standards that allow third-parties to manufacture devices for them (possibly with the payment of a license fee).

Note: Control bus systems that allow for third-party products may still have limits on how devices work together. For example: even if two different manufacturers use the same bus, the command station from one may not work with a hand-held throttle made by the other!

Read more about the Compatibility issues and why it is important to make an informed decision..


Lenz XpressNet, X-Bus and the RS Feedback Bus

Lenz created DCC, and their XpressNet is the granddaddy of modern control bus systems, dating from 1993, but it is mainly intended to be used as a high-speed cab and control bus, not a general communications bus. Lenz also has a separate Feedback Bus for devices, like occupancy detectors, that need to send infrequent information and which do not require instant attention.

XpressNet is actually version 3.0 of their X-Bus, and is a significant change in the software protocols from earlier versions, while remaining compatible with them. Like LocoNet there are other manufacturers making XpressNet-compatible devices. Unlike LocoNet, XpressNet requires a Lenz command station to work because it is a centrally-managed network of devices. At heart it uses the standard RS-485 serial protocol, and the specifications are published online, making third-party construction of compatible devices relatively easy.

XpressNet uses four-wire twisted-pair wire arranged in a tree structure, with RJ connectors (some systems and manufacturers have also used 5-pin circular DIN plugs). There is a limit of 32 devices, including the command station, on a bus. The length of any single segment between devices is limited to about 1,000’ (305 m).

XpressNet requires the use of devices that precisely implement RS-485, and does not allow ordinary serial interfaces (RS-232 or USB) to connect directly to it, instead a computer interface device connects to the computer’s serial interface and to the XpressNet. Lenz sells several different models of these. Addresses on an XpressNet are simply numbers from 1 to 32.

XpressNet operates at 62.5 Kbps, but each device must wait to be polled by the command station before it can send anything. This provides for an even distribution of bus capacity to devices, but isn’t very efficient if most of the communications is happening between a couple of devices. However the bus speed is sufficiently fast, and the size of messages transmitted relatively small, that this is not likely to pose a problem.

Lenz’s Feedback Bus uses two wires attached to screw terminals on the command station, with devices (such as the LR101 feedback encoder) connected to these wires in parallel. There can be up to 64 of these (newer documentation says 128). The terminals are labeled “R” and “S”, so this is sometimes referred to as the “RS bus”. There are third-party devices for the Feedback Bus, such as the LDT RS-8, containing eight occupancy detectors in one case.

There does not appear to be anyone doing shields or software to interface an Arduino to the Lenz Feedback Bus. I found a number of hobbyists who had started work on Arduino shields or libraries for XpressNet, but none appear to have been completed.


Digitrax LocoNet

Digitrax’s LocoNet is used not only by them, but by a number of other companies under license. This means that there is a fairly rich variety of LocoNet-compatible devices on the market. While LocoNet is often associated with Digitrax’s DCC systems, it can be used independently of them (i.e., you don’t need to own a Digitrax command station to use some kinds of LocoNet devices).

LocoNet is based on the RS-485 serial standard, using six-conductor unshielded flat-cable wiring with RJ12 connectors. While most devices have only two LocoNet connectors, it can be wired in a tree structure with some limitations. A LocoNet bus can have up to 32 devices on it (one document says 40), although they recommend limiting each to about twenty. A limited form of the standard (LocoNet Personal Edition) is available online to non-commercial hobbyists, but the full standard is not.

Digitrax makes a repeater (originally the LNRP, today the LNRP Xtra) for building larger or longer LocoNet systems. The also make gateways supporting their wireless (InfraRed and radio) hand-held throttles.

The extra two wires in the LocoNet cable (after the two power and two serial wires) carry a copy of the DCC signal when LocoNet is used with a Digitrax or compatible command station, so that boosters can be connected to the command station via LocoNet with no additional wiring. The signal format of these wires appears to conform to the NMRA’s standard for connecting command stations to boosters (S-9.1.2, PDF), and is compatible with Lenz boosters as well, although the connectors are not. The signal on the extra two wires is not always passed along by LocoNet devices, so boosters should normally be the first devices on the bus after the command station.

There is Arduino support for LocoNet in the form of the Embedded LocoNet library, which is part of Model Railroading with Arduino.




BiDiB® is short for BiDirectional Bus and is another standard bus for computer based model railway control.

The name BiDiB stands for the protocol itself and this can be implemented in many different physical connections like Ethernet, USB or BiDiBus which is designed especially for the needs of huge layouts.

Why a new bus system?

  • Feedback system such as used by Railcom (Lenz) and LocoNet (Digitrax) may not have enough bandwidth to implement bidirectional data transfer on a large scale and in the case of LocoNet, the protocol is “closed source” which makes it impossible to send BiDi data.
  • Bidirectional data transfer opens up new opportunities, such as sending the actual train speed during operation. Bidirectional data transfer has a high demand for bandwidth.
  • Existing bus systems for model railways have some deficits like non-protected transmission, may be fault prone, and are often difficult to configure (due to address allocation schemes)
  • Existing bus systems are stand alone solutions and remain incompleted as there are feedback bus, booster bus, handheld controller bus and so on.
  • Existing bus systems are limited in their wiring topology. This causes problems in huge layouts and specially layouts in U or L shape are affected

Bidirectional data transfer was announced to the industry in 2004, with successful implementation in decoders.

The first bidirectional feedback system became available in 2009, but, it was soon realised that this system had not been designed for a system-wide installation.

With the release of 16 channel feedback sensors around 2010 (Blucher, OpenDCC) the need for a common system bus again came under discussion.

The BiDIB  This draft contains concepts and structures that solves all other known system bus problems from other model railway vendors.

Basically, the bus was designed as a feedback bus only but it has the potential to become the All-in-One system bus for model railways. Therefore, the design is constantly expanding to cover command stations, booster, accessories and control panels.

bidib_logo_lightWhile very promising, as of date, only a limited number of suppliers and manufacturers have announced plans to develop BiDiB products, and as far as I could determine is currently very limited:

Blücher Elektronik

Tams Elektronik

Without support from the leading DCC manufacturers, the BiDiB protocol will most likely fail to become a defacto standard, and will likely be viewed in the history books as nothing more than just another promising technology that failed due to a lack of commercial viability. I hope this not to be true, as the technology has the potential to make model railway Automation even better.



The Computer/Model Railroad Interface (C/MRI) was invented by Bruce Chubb in 1985, a short while after computer interfaces for model railroads were commercially introduced, and is still in use today.

As the name implies, C/MRI requires the use of a computer, and in fact all devices on the bus communicate only with the computer. If two devices need to work together (e.g., an occupancy detector and a crossing gate motor) the computer must mediate between them. Everything other than the computer is treated as a simple on/off wire (although multiple wires can be used together to manage more complicated things). This makes C/MRI an excellent system for remote control panels and devices like turnout (track switch) motors and lineside signals.

C/MRI is based on the RS-485 serial standard. It uses a “RS-485 Converter” to connect to a computer, and runs between “SMINI” devices (as well as the larger SUSIC and older USIC equivalents) on the bus. Other devices, such as simple occupation detectors or the SMC for turnout control, connect to the SMINI. The converter is technically optional, and only required when daisy-chaining multiple devices, so you could start without one for your first SMINI (assuming you have a serial interface on the computer) to limit costs. It is recommended, however.

Each SMINI (or equivalent) must have a unique address set manually at installation by setting small DIP (dual-inline package) switches on the board.

One major drawback is that the company’s “product”, aside from electronics, is the design of C/MRI, which means that documentation is sold in book form rather than being freely available online (although you can find a lot of information by Googling around, you really need at least some of the paper documentation). As of September 2013 the third edition is up to three volumes at US$35 each, with a fourth planned. It’s a small part of what you’d ultimately pay for the whole system (regardless of whose control bus you use this stuff ultimately isn’t low-cost for a layout of any moderate size), but this makes it hard to evaluate the details before committing to the technology.

C/MRI is supported by the open-source JMRI program, which treats C/MRI inputs as “sensors” and outputs as “turnouts” or “lights”.

Since devices communicate with the SMINI in a very simple manner (essentially an on/off state), it’s very easy to create something using a device like an Arduino (or even just a simple circuit) that communicates using one or more “bits”, with each bit being a C/MRI input or output. Here’s an example of someone using an Arduino to control a crossing gate, with a simple up/down signal from C/MRI connected to one digital pin on the Arduino.

Image converted using ifftoany

CTI Train Brain

CTI Electronics makes a proprietary line of remote control and sensing modules known as “Train Brains” that are used to create a control bus. These include the relay and transistor-based “switch” modules for controlling things, and a variety of detection sensors (including magnetic, RFID, Infra-Red and optical, as well as the more common current-based ones). They also make a throttle that can be used with this system.

CTI provides their own software running on the computer. This is apparently free if you buy their circuit boards (downloadable as a trial version with an unlock key), but available only for Windows. If you use their software, all that is required to connect a computer is a small circuit board called a “diplexer” (US$7 and included in the starter kit) for computers with a serial port, or a “USB Bridge” (US$30) for computers with USB.

In addition both RR&Co and JMRI support CTI via a more sophisticated interface, called the Acela (US$40), which is sold in both serial and USB versions. This board does not appear in their catalog, but is hidden away on an application note; JMRI says only the serial version is available as of September 2013.

CTI uses four-conductor flat cables with RJ11 (telephone) connectors. The Train Brain units must be cabled as a ring, i.e., each module is cabled to the next, and both ends connect to the board providing the computer interface.

There do not appear to be any third-party manufacturers of compatible modules, nor could I find any Arduino-based hardware or libraries.



MERG is a UK organization that’s been around for more than 45 years. RPC, the Remote Panel Control System, was an early control bus. And it’s still in use today. Like others, it is based on RS-485, but it can also use RS-232 for simple single-device applications.


A more modern offering from MERG, and one of the contenders for NMRAnet, is their version of a CBUS-based protocol.

The specifications are available for download from their site.

NCE Cab Bus

NCE has been making DCC products for over twenty years (since 1993). Their current “NCE Cab Bus” uses six-wire unshielded twisted-pair wire with RJ-12 connectors in a daisy-chain arrangement, which supports up to 63 devices (simple wiring panels aren’t addressed, but the throttles that plug into them are). Device addresses are set manually at installation time by setting small DIP (dual-inline package) switches on the board to select an address from 1 to 63.

This isn’t quite as functional as C/MRI as a control bus, since it seems to lack a good way to control simple (non-DCC) output devices.

NCE’s bus requires their DCC command station, which also serves as the interface between a computer and the bus. The bus is a daisy-chain between front-of-layout panels with modular jacks for connecting hand-held throttles (which NCE still calls “Cabs”) as well as other devices, such as the AIU, which provides a set of one-wire on/off input-only sensing lines.

Devices for use on the cab bus seem to be fairly limited, and only made by NCE.

The NCE Cab Bus is supported by the open-source JMRI program, which treats AIU inputs as “sensors”. It can also send commands to turnouts (track switches) treated as DCC accessory decoders, but this is apparently done via DCC; the turnouts do not connect to the Cab Bus.

NMRAnet and OpenLCB

In 2008, the NMRA began work to standardize a control bus to “manage and control devices that are independent of train control on a model railroad layout”, which came to be known as NMRAnet. This led to the development of a set of standards known as OpenLCB outside of the NMRA by one group of modelers, to be proposed to the NMRA (there were competing proposals, including one by Lenz based on XpressNet as well as MERG’s CBUS). As open standards, both NMRAnet and OpenLCB publish their standards online.

There was a bit of drama in the early days, but in August of 2012, the NMRA adopted standard S-9.7.1 NMRAnet Physical Layer, as well as an accompanying technical note TN-9.7.1, the first (of likely many) of the NMRAnet standards. Now a physical layer standard just defines what kind of wires and connectors to use, but it’s an important start. As of September 2013, five more documents are in draft and available for review. However, while adopted, S-9.7.1 doesn’t appear on the NMRA Standards page yet (as of June 2014).

OpenLCB has gone quite a bit further than just writing things, and there are devices based on OpenLCB standards available today that can do a number of useful functions. But it’s important to understand that OpenLCB is not NMRAnet, and what eventually emerges from the NMRA may or may not be compatible with OpenLCB devices purchased today. Compatibility is likely, but not assured.

NMRAnet uses the CAN (Controller Area Network) 2.0 standard, with unshielded twisted-pair wire (a minimum of four wires, or up to eight) with RJ45 connectors. This is the same wire and connectors used for Ethernet, so they are readily available at low cost. Unlike most other control bus systems, the underlying technology is not a simple serial line, but a control bus designed for industrial control applications and found in, among other things, most modern automobile control systems. Although it requires moderately sophisticated electronics, these are based on chips mass-produced in very large volumes, so costs are relatively low, and the system is designed to provide reliable operation in a fairly hostile environment (inside an automobile) and thus should be reliable in a model railroad.


Despite its use of Ethernet cables, NMRAnet is not Ethernet. It operates at a rate of 125 Kbps, while Ethernet uses 10 Mbps or higher. There is a limit of approximately 48 stations on a single CAN segment, but each station reduces the effective maximum length of the bus, so this would only be possible with a bus 47 feet in length with one foot between each station. At a minimum, cable must have two twisted pairs and be compatible with “Category 3” (Cat3) Ethernet standards (meaning any commercial Ethernet cable can be used). Preferably, cable with all four twisted pairs, compatible with “Category 5e” (Cat5e) standard, should be used to ensure support of future capabilities (two of the extra wires are used for power, the other two are reserved).

Note: with Ethernet cables, higher numbers are always compatible. Thus a Cat5e (or Cat6) cable can be used anywhere a Cat3 is required. The reverse is not true: if Cat5e is required, substituting Cat3 may work some of the time, but may prove unreliable or not work at all. NMRAnet requires Cat3, so any Ethernet cable can be used, as there are none below Cat3.

NMRAnet supports (in theory) the use of repeaters, bridges and gateways, with some limitations, to get around the limits on a single segment. A repeater can extend overall length (but timing limits will still impose a maximum). A bridge can extend overall length and avoid the timing limit, but may be incompatible with capabilities based on “RTR frames” (which may be use by receivers to prompt senders to provide information). Bridges can be used to connect media other than a CAN segment (such as wireless links), but do not change the data format, and for that reason are not compatible with other networking systems (e.g., Wi-Fi). Gateways are similar to bridges except that they allow for use with other network technologies, such as Ethernet, Wi-Fi or IP networks.

There is a considerable amount of Arduino support for OpenLCB:
– There are libraries available at Model Railroading with Arduino.
– Railstars makes the Io:duino, an Arduino with built-in NMRAnet interfacing and support, as well as providing the OpenLCB library.

There are also other projects (google for them) if you are up to ordering custom circuit boards and building what are in effect electronics kits.


Technically, S88 is a feedback bus with multivendor support (ESU, Märklin, and Viessmann, as well as OpenDCC). It can apparently also be used as a Cab Bus (at least, ESU appears to use it that way although I may be misreading that).


S88 is a very simple serial communication system, and vulnerable to disruption by electrical noise as a result. Use of twisted-pair cables designed for computer networks (i.e., Ethernet cables) can avoid some of these problems. Unfortunately, not all modules use Ethernet-compatible RJ45 connectors. In 2008 a new standard, S88-N, was adopted (well, by at least the two authors; I couldn’t find anything indicating a standards organization was involved, although it does appear to have multivendor support). This specifies the use of Cat5 RJ45 cables and connectors (which are standard low-cost Ethernet cables, although more expensive than Cat3). Even this can take incompatible forms, as the accessory power supplied on the bus can be either 5V or 12V.

S88 is apparently a daisy-chain, but there are “data switch” modules (LDT DSW-88-N-G) that can split it, forming a tree structure.

It appears that S88 is implemented slightly differently by each vendor (even the signals on the wires differ between vendors), making third-party support something of a challenge. Despite that, there is some.

LDT makes a number of products, some of which appear to support vendor-specific versions as well as S88-N. However, these all seem to be input modules (appropriate for a feedback bus), with no control modules.