MRBus Spec Table of Contents
  1. Section 1 - Introduction
  2. Section 2 - Hardware Layer
  3. Section 3 - Software Layer
  4. Section 4 - Component-Level Integration
Section 2 - MRBus Hardware

Section 2.0 - Design Fundamentals

The design for MRBus was a bit backwards from the normal procedure – the hardware was chosen first, and then the requirements of the software/data elements was fleshed out. The reason for this was that for most model railroaders, price was of paramount concern. A slow but functional and cheap system was to be preferred over an expensive fast system, since the lower the cost, the greater the chance people will actually implement it. It also makes potentially large systems (with lots of nodes) affordable.

In trying to describe the network in terms of the standard OSI network model (which I’ve never particularly cared for, but I offer up as a commonly understood reference point), I’ll describe MRBus in terms of the four layers it really fits into: Physical, Data Link, and Transport. Everything above that is left to the discretion of the implementer (since it will vary from platform to platform), but examples have been provided.

Section 2.1 - MRBus Physical Layer - Electrical

Since RS-485 only specifies the hardware layer of the multi-drop bus, a protocol for arbitration and collision detection/avoidance must be developed. MRBus is based off an earlier telemetry network concept called RDB – Revised Differential Bus. The concept was originally developed in late 1997 by Mark Finn, Michael Petersen, and Nathan Holmes, and works on the basis of an effectively “open collector” network. Zeros are transmitted by actively driving the bus, whereas ones are transmitted by disabling the transmitter for one bit-time and allowing the pull resistors to float the bus back to one. This provides a crude form of collision detection - any device transmitting a one and reading back a zero will be in collision and should cease transmission immediately. As long as this is done fast enough and propagation time is small enough compared with bitwidth, there should be no adverse effect to the system sending the zero. Thus collisions are not only detected, but also dealt with in a non-destructive manner. Also, the sending address is always used as the first byte sent (and thus the arbitration byte). As long as each device has a unique address, device supremacy will be sorted out before actual data transmission occurs. Combined with a certain randomness in transmissions and a backoff timing system, this implements a multi-access network capable of low speed operation. Originally running at 2400 baud and requiring a dedicated bus interface PIC, it proved a good concept, but far from optimal.

MRBus takes this concept and optimizes it in order to increase data rates to something acceptable for a near-real time control network. The basic concept of a semi-passive bus was kept for the arbitration of the bus, but as soon as a device has positive control of the bus (in other words, completes arbitration successfully), the bus is actively driven both ways at a much higher baud rate. In order to accommodate the full compliment of 256 devices (8-bit address) per MRBus segment, 1/8-unit load RS-485 transceivers must be used – such as Maxim’s MAX3082E. While not required, it is strongly recommended that slew-rate limited transmitters be used to minimize high frequencies on the bus, and thus help avoid possible termination/reflection issues. ( For reference, smaller buses that are not anticipated to grow larger than 128 nodes or so can use 1/4-unit load transceivers, such as the MAX487E. These have been used successfully to construct the first prototypes. )

Each bus segment should consist of no more than 1800 feet of UTP cable with a characteristic impedance near 125 ohms, a resistance of no greater than 200 ohms per thousand foot, and a capacitance no greater than 17pF/foot. Standard 26AWG Category 5 cable meets these specifications nicely. The bus can be architected in any convenient formation, except for loops, as the low bit rate and differential signaling should prevent most problems due to reflection or interference. Loops/rings are not allowed due to multi-path propagation delay issues, but any branching/trunking arrangement is acceptable.

Each bus segment must also have two sets of 2k-ohm pull resistors, set up to pull the bus to a “one” (or space) state if no transmitter is actively driving it to a “zero” (or mark) state. These should be spaced as close to 1/4 and 3/4 of the cable length as possible, though on runs shorter than 500 feet this really shouldn’t matter.

Section 2.1 - MRBus Physical Layer - Connectors

MRBus will use one of the two connection styles listed below.

Connection Type A: 4-Position Screw-Type Terminal Block, with the following pinout:

1 - +12VDC
2 - GND
3 - MRBus:RS485-A
4 - MRBus:RS485-B

This pinout is the cheapest possible alternative in implementing an MRBus connection. Note that despite the use of screw-type connections, the interconnections between nodes should still be made with Category-5 or better wire.

Connection Type B: RJ45-style connections, with the following pinout:

1 - +12VDC (White/Orange)
2 - GND (Orange)
3 - +12VDC (White/Green)
4 - MRBus:RS485-A (Blue)
5 – MRBus:RS485-B (White/Blue)
6 – GND (Green)
7 – DCC:RS485-A (White/Brown)
8 – DCC:RS485-B (Brown)

Devices implementing connection type B (RJ45) should always have at least two jacks to allow network pass-through. More than 2 jacks is also certainly acceptable, since MRBus is designed to have an essentially free-form architecture. This (rather bizarre) pinout was chosen to provide 2 power-ground pairs (with some minimal noise filtering due to mutual capacitance) and a differential data pair in such a manner that it would not be destroyed by (and in fact, will not be affected by) the accidental insertion of a crossover-style Ethernet cable into the network. However, MRBus is designed to work with normal (straight-through) style Ethernet cables. The choice of pairs and wire positions was chosen to follow the AT&T-258A and EIA/TIA 568B standards. Pins 7-8 (the brown pair) is available for optionally distributing the DCC signal to booster stations around the layout (via RS485 signaling). This is not mandatory, but rather provided as a convenience to save extra layout wiring (and should be quite useful once MRBus-compatible smart boosters are developed).

Copyright 2012 by the MRBus Group.
Licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Questions? Comments? Please email us at

Last modified on February 19, 2012, at 01:36 PM