MRBus Basics

Q: What is MRBus?
A: MRBus is a low speed serial communication network, designed to allow small microcontrollers to exchange short messages in a peer-to-peer manner. There is no master controller - MRBus is a connection of equal peer nodes. If one fails, the rest should be able to continue on without it. It was originally designed for model railroading applications, but has since been expanded for general telemetry purposes.

Q: How exactly do I pronounce MRBus?
A: "EM-ARE-Bus" is the preferred pronunciation, but occasionally even its creators get lazy and refer to it as "murbus".

MRBus History

Q: Who developed MRBus?
A: MRBus is actually a descendant of RDB (Revised Differential Bus), developed by Mark Finn, Michael Petersen, and Nathan Holmes as the telemetry bus for the 1999 Iowa State University solar car, PrISUm Phoenix. RDB's physical layer was in turn inspired by SAE standard J1708.

MRBus was born in 2001 as part of an effort by Nathan Holmes to build a signaling and control system for a model railroad that didn't need a myriad of cabling to implement, or a computer to operate. Nathan and Mark felt that previous work was a good starting point, and MRBus was born on the Microchip PIC architecture.

Somewhere around 2004, Michael Prader started working on an Atmel AVR port for use in Europe on some FREMO americaN modules. His work (and a few compatibility fixes by Michael Petersen) provided the modern AVR MRBus core library.

Q: What's this about MRBus-US and MRBus-EU?
A: There were a number of incompatibilities in the two original implementations of MRBus. The port by Michael Prader that's used on the east side of the pond (aka, the European Union) is actually more closely adherent to the specification. Nathan's version that's in use on the west side of the pond (aka, the United States) varies a bit. I think we've worked out our differences at this point and we've standardized on a common core. For historical reference, here is a list of differences that occurred between the two original code bases.

Using MRBus

Q: I've got a question about MRBus. Where should I ask it?
Q: I found a bug. Where should I contribute a patch?
A: Your best bet is the official mailing list over at Yahoo Groups - http://groups.yahoo.com/group/mrbus/ If you'd rather ask us privately, just email mrbus@mrbus.org

Q: Can I create my own MRBus node?
A: Absolutely, we strongly encourage it. The intent of making all of this public was to get others enthused about the technology so that we all benefit from a thriving MRBus-based ecosystem. Please let us know if you make something related to MRBus, and we'll add you to the list of nodes on the implementations page.

Q: Can I just buy some stuff?
A: Sure. MRBus.org doesn't sell anything - we're just the hub for the specifications and information about various nodes people have created. However, the nodes listed on the implementations page may be for sale - check the links back to their owners for more information.

The "Why X rather than Y?" Questions

Q: Why not CAN / ISO11898?
A: A couple reasons, actually:

  • CAN requires specialized hardware. MRBus can be implemented on pretty much any microcontroller with UART. You might even be able to bit-bang the serial for very simple nodes.
  • CAN support in microcontrollers in 2001-2002 (when MRBus was being developed) was very limited.

Q: Why not ethernet?
A: Implementing even basic ethernet on a small microcontroller would require a pricey external ethernet controller part, and would require switches and point-to-point wiring from nodes to those switches. If you actually wanted to implement UDP IP packets on top of that, you'd quickly get into a nightmare of IP configuration and protocol overhead. Plus a standard ethernet frame (~1500 bytes of payload) is many times the amount of memory most of the microcontrollers we use even have on the die.

Q: Why Microchip PICs?
A: It's because that's what Nathan and Mark were familiar with at the time, and had the development hardware to work with. They're also cheap and commonplace. The downside is, of course, that there's no free C compiler for them. Early on, we chose the BoostC compiler (at the time, known as C2C) because of its low cost. It's evolved into an excellent tool over the years (it was a little temperamental in the early days), but it's still commercial and Windows-only.

Q: Why don't you make the code compatible with the now-free HiTech PIC C compiler included with MPLAB?
A: Because that involves work. Seriously, it's on the to-do list when I get some spare time, but it's going to be a pain in the ass because of the small differences between the two - capitalization, how bits and bit names are handled, etc. If that's the sound of you raising your hand to volunteer, by all means, send us an email.

Q: Why the recent move to Atmel AVR microcontrollers?
A: The biggest reason is the standardized, high quality, and free (as in speech and beer) toolchain based on GCC that will work on both Linux and Windows (and probably MacOS X, but really I don't know any Mac developers). With PICs, there was no "standard" compiler until Microchip recently started bundling the Hi-Tech compiler with MPLAB and made the Lite version usable at no cost.

Q: Why not Digitrax's LoconetTM?
A: Because it's a closed ecosystem. There's the Loconet Personal Edition, but it's rather restrictive in what you can do without explicit licensing from Digitrax. For example, it prohibits me giving you a board I designed that implements LPE. (From their terms of use: "The information is for private use only and my not be used for products that are intended for distribution to others, with or without profit.") I think an open specification and open hardware/software ecosystem where people can build what interests them and do as they wish with it is in all of our best interests.

Q: Why not just move to MERG's CBUS, OpenLCBTM or in the future NMRANetTM?
A: The short answer is because I'm not ready to concede. Don't get me wrong - I think they're a very strong contender and are doing many great things - some similar to MRBus, some not so similar. I don't think the technology that will run the next generation of model railroads is yet settled.

Licensing and Legal

Q: What's the licensing on MRBus?
A: The specification and documentation are licensed under a Creative Commons Attribution-ShareAlike 3.0 License.

The core source code is licensed under the GNU General Public License, version 3.

MRBus is a trademark of Nathan Holmes, and permission to use the term is granted to anyone who creates a node that's compliant with the official specification, or uses compliant nodes as-is. It's not that I like legalese, but I want to make sure that nobody creates incompatible nodes or specifications and then tries to associate them with us. There is no formal licensing process (nor do I ever anticipate one) or compliance testing procedure (yet).

Q: Can I sell things related to MRBus?
A: Yes, absolutely. Just remember to comply with the license terms of the GPL v3 if you use our MRBus core library. Also remember that MRBus is a trademark, and while I've granted permission for anybody creating a compatible component to use it to describe their part, it would be greatly appreciated if you'd just email us for formal permission. As long as you do that, we'd love to add a link on our implementations page so that others can find your creation.

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