In August, the NMRA adopted standard S-9.7.1, NMRAnet Physical Layer, and a short article about it appears in the November issue of the member's magazine. What is this, and why should you care about it?

Well, if you care about Digital Command Control (DCC) for controlling a model railroad, it's an important addition to model railroading that will enhance that. And if you don't care about DCC, it's compatible with other control systems, and you may still want to use it.

Note: In the interest of full disclosure, I should mention that Don Goodman-Wilson, of Railstars and the author of the article mentioned above is a friend, and I’d previously been a beta tester for his original DCC booster kit. But I have no involvement nor financial interest in any of his current products, nor am I involved in NMRAnet in any way, other than as an interested observer.

What is NMRAnet?

Let's start with what NMRAnet isn't. It isn't a replacement for DCC, the digital method for controlling trains. Nor is it a replacement for RailCom, the standard method for trains to report information back to the control station. Nor is it a mandatory replacement for the way manufacturers do what it does today. It's likely that some of them will adopt it and integrate it into their products, but nobody's requiring them to do so.

NMRAnet is, or rather someday will be, a standardized communications system to "manage and control devices that are independent of train control on a model railroad layout" (per the NMRA's original mandate from 2010). It's based on OpenLCB, a set of specifications, software and hardware reference designs for a "Layout Control Bus". If you're familiar with DCC you've probably heard the term "control bus". That's the means by which a computer, handheld, or base station can interact with accessories separately from sending signals through the rails to them.

A control bus is a generalized version of the older "cab bus" idea, where you could have handheld throttles that moved around the layout with you, while the "power pack" stayed in one place. A modern control bus expands on that to allow any device to interact with any other device. DCC didn't define a "cab bus" or "control bus" as one of its standards, so every manufacturer was left to invent their own. Some examples are Digitrax's LocoNet, Lenz's XpressNet and NCE's Cab Bus.

In a complex layout, a control bus is very important. Without one, separate wires need to be run to each turnout from a control panel (either a central panel or a set of "yard" panels) where pushbuttons or toggle switches control turnout position. And if you want signals that react to trains, there are more wires between circuits that detect the position of trains, and those that control the lights (aka "aspect") on a signal head. And if, for example, you need to throw a turnout from two different locations, such as two ends of a siding or yard, the wiring gets much more complex.

With a control bus, one cable can run about the layout, connecting to each device, and they can all share that cable to send instructions and status reports back and forth. An operator with a handheld control can then throw any turnout from any location where the handheld can connect, or with a wireless handheld from anywhere.

A computer can also connect to a control bus, and software (either commercial or the free JMRI software) can be used to create electronic control panels, or to instruct the command station to program decoders, or to actually operate a train from a "throttle" on the computer, by clicking a mouse rather than turning a physical throttle knob. And while that may seem merely "cute", consider that you can get software throttles for smartphones today, so for the cost of an app you can add a walkaround throttle to some systems (depending on system, additional hardware may be required).

But today, because each control bus is proprietary, for the most part you can't use accessories made for one system with another manufacturer's system. That means you're locked in to using accessories from the manufacturer of your chosen DCC command station. (to be fair, Loconet has some third-party accessories because Digitrax do license their control bus, but the way they do it appears to discourage manufacturers, and very little is available).

Now before I get carried away with my own enthusiasm, it's important to take a breath and mention that the standard adopted in August is merely a first step. It defines the wiring and basic signaling of the control bus, the "physical layer" in networking terms. This is an essential foundation for everything else, but it's just a foundation at this point. You can do some cool things with it today using some not-yet-standardized OpenLCB protocols, but the real benefit lies in the future.

And getting to this point was a long (about five years) and sometimes acrimonious process, but then standards development efforts often are. Many more standards will be needed before this is "done" (such standards are extensible, so they're never really done; DCC is still adding things today such as RailCom). The OpenLCB group appears to have a strong vision of what these will need to be, although details are hard to come by. But they'll have to get those plans nailed down and run through the NMRA's standards process. And that's likely to take a number of years before NMRAnet will be a complete and standardized control bus specification.

As a first step, S-9.7.1 has a lot of positive aspects that speak to a well-considered design. The NMRAnet developers have clearly learned from the experiences of others. It uses standard Ethernet cables (which are cheap, and easy to make yourself with the right tools), but it doesn't use Ethernet hardware (which isn't as cheap and does a lot of fancy things that aren't needed here). And the physical layer itself is replaceable; the same control protocols will run over the S-9.7.1 network (which is based on an ISO specification for simple distributed network of devices, called a “Controller Area Network” or CAN) or other technologies such as wireless, or the Internet.

And the developers are using standard open-source methods to license the software and documentation of the OpenLCB specification behind the NMRAnet standard, so people can easily use it to build new hardware or systems for sale. There may still be issues there, particularly with some of the requirements imposed by the software's GPL license (but they appear to be using the older V2 GPL, which is less burdensome than V3, at least from the manufacturer's perspective).

Licensing like this is typical in the open-source software world. It lets groups manage the evolution of a package, to prevent well-meaning but incomplete changes from being mistaken for more reliable ones. Licensing can be abused, but without it there can be problems such as conflicting implementations and developer confusion, which can hurt both functionality and adoption.

Why is "open" and "standard" important?

Because it's an open standard without a competitor controlling it, and because the NMRA standardization points to a single solution that others will also design their equipment and software for, manufacturers should be more willing to use it in their products. And increased choice means more products for consumers, and more competition to lower prices for us end-users.

And because NMRAnet will eventually provide for both throttle and accessory control, this means that accessories and throttles from one vendor will (eventually) work with command stations from another. In the long run this means that we should be able to use handhelds from several companies with command stations from anyone, and have computer-based control/display software from yet others, all working along with locomotives carrying decoders from dozens of companies. If your module club choses to use a command station from vendor X, you'd still be able to use your favorite handheld throttle and turnout motor/controllers on your module, and it would all work together.

Now some of that is not here today. The OpenLCB team has more standards in the works, some or all of which will eventually be adopted by the NMRA. And more manufacturers need to get on board. In particular the ones with proprietary buses with restrictive licensing need to develop, or allow to be developed, interfaces that will allow their systems to work with NMRAnet equipment.

I'm a bit concerned that the OpenLCB vision seems to end at the "hook wires and switches to boards" level today, although some of the rather vague high-level descriptions and development notes hint at a broader vision that they don't seem to have articulated more specifically anywhere public. But I'm confident that more will come in time, either from them or from someone else addressing that lack once the basic system is in place.

NMRAnet's Future

Today NMRAnet can be used for some simple control tasks, if you're a do-it-yourselfer and not scared off by connecting wires, switches and other things to a circuit board (see below). And the potential is there for it to be so much more.

There could be a day, not that far off, when an eight-year-old gets a new train for Christmas, plugs in a few wires, downloads an app, and is running trains and throwing turnouts wirelessly under the tree in a few minutes. Digital control that is as simple and easy as DC was when I got my first train for Christmas, but much more extensible. That same kid could then build a yard with several turnouts, drag-and-drop pictures of them on a screen to create a control panel, and start selecting routes through the yard ladder with a tap of a finger.

There's a lot yet to be done to get there, but I can see the 21st century version of model railroading in my mind's eye, and it's looking pretty good.

And that's why I care. Because the future of this hobby depends on getting kids interested in it. And kids these days live digital lifestyles. If you aren't part of that, drawing them in gets harder every year.

And frankly, I want to drag-and-drop my own control panels and run trains from my iPad with a few taps. Don't you?

NMRAnet Today

While I'm not playing with NMRAnet or OpenLCB yet, and likely won't for some time as I'm deeply invested in Digitrax LocoNet hardware, I want to call attention to what you can do with NMRAnet today. This is barely out of the proof-of-concept stage, and the selection and pricing reflects the low volume of this market, but the capabilities available are already significant for anyone with the usual level of model railroading electronics skill (i.e., wiring switches, LEDs, and a bit of soldering).

At this point, the out-of-the-box functionality available is a "virtual wire", allowing switches and LEDs to respectively control and be controlled across the NMRAnet bus. But it's a virtual wire where one end can be on a computer running JMRI, and the other could be connected to a device like a block occupancy sensor or signal-head LED. You can do a lot with a virtual wire. And a hobbyist willing to get into Arduino programming or connect more complex electronics to the boards could do significantly more.

There are already two vendors with commercial products available, and a third in development:

TCH makes both a USB interface for connecting a computer, and 32-line "producer" and "consumer" boards, the former designed to be connected to their block-occupancy detectors or to physical switches or similar things, and the latter for devices like turnout controls. These boards use a ribbon-cable connector, which to my mind is a big negative (I'm a fan of screw terminals for this kind of thing), but that's a matter of taste. They also make a 16-consumer/24-producer board (I can't tell if it uses the same connector or not).

With prices around US$60 (US$40 for the USB board) these are a bit expensive, but you get a lot for the money in terms of connections and they're not as expensive as some DCC solutions. With this density, these would be very useful for building a control panel, but if all you want to hook up are a few turnouts, a 32-output board is a bit excessive.

Railstars makes the Io, with 8 inputs, 8 outputs (with screw terminals!) and 32 additional lines (soldered) that can be input or output. The price is US$150, which is rather high compared to the two others.

Railstars also makes the Io:duino, an Arduino with integrated NMRAnet interfaces for US$90. This was shown in the August NMRA demo acting as a DCC command station in tandem with the RAILbooster DCC power station (US$100). Combined with JMRI (for a software throttle) and the TCH USB module, that would get you a complete DCC system for about $230 (plus some power supplies), which is competitive with standalone systems with computer interfaces. However at this time there doesn't appear to be a command station Arduino program available from anyone, nor JMRI support for a throttle for one, only the libraries that would allow someone to write their own, so it's not yet an out-of-the-box solution for DCC.

RR-CirKits (makers of the LocoBuffer-USB I use for my computer connections to LocoNet) is reportedly working on a version of their Control Point board for NMRAnet (currently available for LocoNet for US$86 with 8 occupancy detectors plus 8-inputs, 8-outputs, and 32 LED drivers).

What's missing are low-density modules suitable for controlling a small number of devices (like Digitrax's DS64 for four turnouts @ US$60), however as that function can also be provided by stationary DCC decoders (if you use DCC) it's not likely that the volume of demand for an NMRAnet solution would justify development, or provide a sensible price, at this time.

References

There are a number of additional sites that may provide interesting reading on this or related topics.

NMRA Standards
NMRA DCC Standards
NMRAnet Standards

OpenLCB Specifications
OpenLCB Development Documents
OpenLCB “Dashboard” (summary of existing implementations and products)
OpenLCB Licensing
OpenLCB Draft Documents

Tags: Arduino, DCC, JMRI, LocoNet, Railstars, TCH, RR-CirKits, NMRA, NMRAnet, Signals