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 1 - MRBus Introduction

Section 1.0 - The Need for a Bus

DCC has been a great effort in the standardization of control in respect to track-connected devices (locomotives, items like turnouts controlled as accessories, etc.), but it left two other pieces of the communications puzzle unaddressed – the interconnects between the DCC system and operator cabs and the interconnects between all other devices. To a great degree, the cab bus is perhaps best left to the manufacturers at this point in the game. Cabs require guaranteed bandwidth in a time-definite manner so that commands are rapidly transmitted from operator to locomotive. Lenz and Digitrax have both done an excellent job with their respective bus architectures (XpressNet and Loconet), and both are part-way towards becoming de facto standards, as both types of buses are usedby third party products.

(Note: Loconet is more than just a cab bus – it's an actual shared network, capable of handling not only cab traffic, but also miscellaneous data for layout control. For those interested in extending Loconet, I recommend http://www.digitrax.com/loconetq.htm . Digitrax is to be highly commended for releasing the Loconet Personal Edition for hobbyists, but I still felt that any specification controlled by a specific commercial entity with some rights reserved was probably a bad starting point for a free, open system – especially one that I wanted to be able to grow and expand to fit problems as others and I encountered them. Not only that, but I wanted to avoid any legal issues that might pop up.)

This leaves the peripheral communications bus issue. Right now, all current known implementations of signaling, control, and telemetry systems require large runs of wire to connect remote pieces to control nodes and control nodes to each other. This quickly leads to inflexible, confusing masses of cabling that in turn lead to reliability and maintainability issues.

1.1 - Bus Architectures for Model Railroad Peripherals

Currently, most, if not all, existing layouts with such a system use one of two architectures:

The Programmable Master-Slave System - A signaling and control system consisting of a smart master controller, one or more less capable slave peripheral controllers in several centralized locations, and many individual wires running out to signals, switches, motors, block detectors, and other peripheral gear. While these systems have the benefit of being straightforward to design, construct, and operate, they almost always lack the ability to run without the primary controller (usually an old PC) being on. In addition, the mass of wiring from the peripheral controllers to the actual devices being controlled can quickly become a minor nightmare in terms of debugging and maintenance. The key example is Bruce Chubb’s C/MRI (computer-model railroad interface) system and its derivatives.

The Modular Discrete Logic System – Overcomes the need for a central control unit by using many individual nodes wired together in such a way that they form the correct signaling logic. These typically consist of block detection nodes, signal logic nodes, and sometimes switch motor nodes. These are then connected by discrete signals indicating block occupancy. These work well, but have a high cost with large layouts due the number of nodes required. In addition, they suffer additional maintenance and troubleshooting problems due to the logic relying on the correct user interconnections, which becomes quite complex with anything greater than simple ABS. The signaling isn’t at all flexible – once you choose a scheme, the signal logic is built in hardware. Also, especially in CTC installations, they require an enormous number of wires to be run back to the main control board due to all signals being on discrete lines.

The Peer-To-Peer / MRBus System – What I propose is a shared, packetized bus of microcontroller-equipped nodes, each powerful enough to collect data and broadcast that to the bus and/or receive data from the bus and process it accordingly. Each node is as flexible as the designer chooses, ranging from all functions needed for a CTC-controlled siding to a computer interface to a simple digital I/O card. The nodes are tied together with a modified RS485 network and a set of power cables. This allows a layout of smallto- medium size to be wired with a minimum only four wires (excluding short feeder runs, because the nodes are near what they serve), and the potential to operate without the need of a computer. This overcomes the problems of the previous two systems, but with the downside of additional complexity. Note that MRBus is by no means limited to model railroad application – I intend to use it for home automation in the future as well.

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

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