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 3 - MRBus Data Link and Transport Layers

This section describes the part of MRBus traditionally implemented as software. This actually crosses the OSI Physical, Data Link, and Transport layers.

Section 3.0 - Addressing Scheme

Addressing and Multiple Networks

A maximum of 256 nodes are allowed on any segment, due to limitations in the bus transceiver parts. If parts other than 1/8-unit load RS485 transceivers are used, the maximum number of nodes changes accordingly (1/4-unit load gives you 128 nodes, 1/2- unit load for 64, etc.) Address 0 is reserved for packets with a destination of nobody (all nodes will ignore), and 255 is reserved for packets being broadcast to everyone. Each node capable of transmitting must have a unique address from 1-254. Nodes capable of listening only should be either assigned address zero, or if there is some specific reason, they can also be assigned a real 1-254 address.

For networks requiring more than 256 nodes, a “store and forward” style switch will need to be developed. This device will need the ability to filter packets and selectively bridge certain source addresses between segments, effectively allowing nodes needed by both networks to be visible on both networks. So far, this is only conceptual, and no such device has been implemented.

Section 3.1 - Arbitration, Packet Transmission, and Retry

Transmissions (transmit cycles) must be prefaced by a certain amount of delay while the bus is monitored for activity. This delay consists of two components – a fixed delay and a variable delay.

The fixed delay is slightly greater than two 4800bps bit times – 440uS. The bus will be monitored every 10uS for activity during this period. If any activity is detected, the transmit cycle is aborted and must be restarted.

The variable delay is slightly more complex, and consists of three components: priority, loneliness, and the bottom four bits of the device address. Priority represents the urgency of the message, and exists on a range of 0-12. 6 is an average priority message, and should be used for most all messages. The lower the number, the higher the priority. For important (or time-sensitive) messages, such as faults detected or CTC commands, should come in with a higher priority. Only real-time messages (clock synchronization, etc.) should carry a priority of zero. Lower priority messages, such as MRBus-connected DCC booster statistics or general telemetry data, should travel at lower priorities (higher numbers).

Loneliness is a very nebulous concept – it represents how much a node “wants” to talk to other nodes. The more times a transmission is aborted (due to activity, collisions, etc.), the greater the loneliness. Like priority, the lower the number the higher the loneliness. The higher the loneliness, the greater possibility that a device will win the arbitration battle. Every time a transmission fails due to some other device seizing the bus, loneliness is decremented towards 0. It should always be reset to 6 (midrange) upon successful transmission. The only exception is that devices that transmit frequently (more than once a second) should reset their loneliness to something higher than 6. More details on this will be filled in as soon as some experimentation has been completed.

The variable time is then calculated by: P = Priority number (0-12, nominal 6) L = Loneliness number (0-12, nominal 6) D = Device Address (0x00-0xFF) Tv = Variable delay time Tv = (P + L + (0x0F & D)) * 10uS

Like the fixed delay, the receive line must be checked every 10uS for activity. If any is detected, the transmit cycle must be aborted.

All transmissions start with an arbitration byte, transmitted in semi-passive mode. The arbitration byte is simply the device address, transmitted at 4800 bps LSB first, with a zero start bit and a one stop bit. For example, if a device had an address of 0xFF, it would send (including start-stop bits, read left to right) 0111111111 as the arbitration byte. Zeros are transmitted by actively driving the bus to the defined “zero” state, whereas ones are transmitted by disabling the transmitter for one bit cycle (208uS). The receive line should be monitored to assure that no collision occurs within the arbitration period. As expected, any device sensing a collision should immediately abort transmission, release the bus, and start the transmit cycle over again.

The actual data transmission occurs at 57600 bps following successful arbitration, and is up to 20 bytes of 8-N-1 using fully-driven RS-485. This works out nicely, because one low bit at 4800 will cause a framing error at 57.6k and will not be detected as a valid byte by any UART listening at 57.6k. 4800 has a bit time of 208uS, which affords a 20% safety margin over 57.6k’s byte time of 173uS (using 8-N-1 transmissions).

Diagram of a successful MRBus transmit cycle

Above the physical layer, the actual data packet is structured as: 1. Arbitration Byte (device address), at 4800/9-N-1 2. Device address again (this and all further bytes at 57600/8-N-1) 3. Packet desination address (0xFF is broadcast) 4. Packet length (bytes sent at 57600 only, including bytes 2-4) 5. CRC-16, low byte 6. CRC-16, high byte 7. Packet type 8. 0-13 bytes of data, depending on value in byte 4 For ease of understanding, byte 1 is usually assumed and not explicitly written, since it's a line protocol-layer item. All further packet descriptions will be noted as follows:

[DEST][SRC][LEN][CRC16_H][CRC16_L][TYPE][DATA (bytes as needed)]

For example:
...or, an identical packet represented differently...

If and only if the transmit cycle is aborted (either by activity during the delay periods or by a collision during the arbitration phase), the device must wait until a packet is successfully received or 10mS, whichever is shorter.

Communication is assumed to be stateless and only moderately robust. Devices should be able to store one packet for processing while another is being received. This will provide reasonably positive assurance that packets will be handled if received and that overruns and missed packets will not occur. No provision for packet sequencing or packets larger than the maximum length described above is provided. Any such needs should be handled at the specific application layer. By convention (and convention only), byte 7 (the packet type) is an upper-case ASCII character for commands or informative broadcasts, and a lower-case ASCII character for replies. The following characters have typical uses that should be commonly followed:

APingAny device addressed should respond with a lowercase (a) packet with no data
BAlternate CmdMost frequently used to control the west end of a CTC-controlled siding
CCommandCommand to inform a node to perform some control function (such as throwing turnouts or relays)
R?EEPROM ReadReads a specified address in configuration EEPROM
SStatusPeriodic data updates from a device (such as block occupancy, temperature, etc.)
VVersionSoftware/Hardware revision and identification for a node
W?EEPROM WriteWrites a value to a specified address in configuration EEPROM
XResetPerforms a reset of the device
ZReserved DebugThis packet type is reserved for device-specific debugging use

The packet 16-bit CRC is calculated using a starting value of 0 and a polynomial of x^16 + x^15 + x^2 + x^0, with no reflection of data bytes or xoring of the data or output CRC. For more details, see the CRC16-MRB page.

The CRC is accumulated by starting at the device address byte and working through the packet (whatever length that may be), skipping over the two CRC positions.

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