Aside: I know I haven’t done post number three in the Signals series yet, on interlockings. I’m still planning that, but I need to spend more time on it, and I’ve been wanting to find time to write about LCC since March.

Three years ago, in 2012, the NMRA published their first standard related to a layout control bus, at the time known as NMRAnet. This was standard S-9.7.1 NMRAnet: CAN Physical Layer, which defined the electrical characteristics of the bus (e.g., details of the wire, connectors, bit rate, and voltage levels). Several companies were producing useful circuit boards based on the standard, although their functioning depended on capabilities not adopted at that time.

This standard, and the not-yet-adopted parts used to make the first implementations, were based on something called OpenLCB, which stands for Open Local Control Bus (not "Layout Control Bus"). Open LCB was one of several competing proposals for NMRAnet. The OpenLCB team demonstrated how this would work at the 2010 NMRA convention, and has a page of videos and other information from then. Over the subsequent two years it came out on top as the solution of choice. However, some of the potential demonstrated there does not seem to be fully fleshed-out in even the current standards. We're not done with the development of LCC by any means.

But we have had significant progress this year. Back in February the NMRA adopted 21 additional documents, 10 more Standards and 11 clarifying Technical Notes. They also renumbered them slightly, and changed the name to Layout Command Control, or LCC. These were formally adopted with a six-month comment period that ended on September first. Updates based on those comments are still possible, so the standards aren't quite done yet, but they're probably very close to their final form.

Beyond the documents currently adopted by the NMRA, OpenLCB has several others in various stages of development. There's a list of these on their Dashboard page. However at present their site is a bit of a mess, and most of the links from that page result in page-not-found errors, making it hard to determine just what they have planned for the future.

So, where does this leave us, and why do we need another kind of digital model railroad control anyway? Good questions, and as usual I have more that I want to say than will fit in even my usually long-winded posts, so more will follow on this topic.

Today I'll cover why LCC is needed and some details of how it differs from DCC. Next time I'll get into more specifics about how it works. A third post will cover what it can't do, or can't do very well, at present and how this may evolve in the future.

I should note that I’m not an LCC expert by any means. I’ve read the standards, and I’m fairly knowledgeable about programming and computer networking (the latter is what I do for a living), but I haven’t been involved in, or even tried to follow, any of the development activity. So my perspective is that of an outsider. An informed outsider, I hope, but I could easily be misunderstanding intent, and there’s very little in the way of implementations of LCC as yet, so I can’t easily sanity-check my ideas with testing (not that I’ve had time to do any, anyway).

Why LCC is Needed

Like DCC, LCC isn't required, of course. We've been running trains for more than a century using just AC or DC power on the rails and nothing else. DC power packs in later years provided a simple "accessory" power output, so simple accessories, like turnout switches or crossing gates, could be operated by a simple power switch. This, too, worked fine for decades, and can still work just fine today.

But the reason DCC has been successful is that it lets us do things we couldn't do before: slow speed operation, synchronized multi-unit lashups with one throttle, control over lighting and sound systems. And it did all that at a relatively low cost. DCC twenty years ago wasn't cheap. But today you can get a basic decoder for less than a quarter of the cost of a high-quality locomotive model, some for under US$20. Part of the reason it’s cheap is that the market for it is fairly large because it has the field mostly to itself, and that’s a result of it being a standard.

In addition to locomotives, DCC also allows for control of stationary "accessory" decoders. This has enabled control over both simple things like turnouts and crossing gates, and more complex systems such as turntables or setting routes through yard ladders with a single command.

But DCC is 26 years old now, developed by Lenz in 1989 and standardized by the NMRA in 1993. Some of the decisions made back then, based on the technology available, impose limits on it today. Replacing it doesn't make sense given the substantial investment hobbyists have made in equipment over the years, but augmenting it does. LCC basically provides a better way to do the functions of accessory decoders, as well as other things those can't do well, or at all. And using LCC for accessories frees up some of the capacity of DCC for running more trains, which is important on larger layouts.

LCC as a standard control bus has a lot of competition today from existing control bus systems, both proprietary like LocoNet, and more open systems like S88. Time will tell if LCC will displace them, but it has some strong advantages.

Scale and Limits of DCC and LCC

DCC was designed, first and foremost, as a way to control trains. Trains are mobile and on a large layout will need to move seamlessly from one power supply to another (i.e., from track fed by one booster to track fed by another). DCC also needs to support pre-existing wire that wasn't designed for digital signals, and even track as part of the "wire".

Those constraints led to the system being designed to be highly immune to electrical noise and other problems caused by low-quality (in the digital signal sense) wiring. And is led to use of a fairly simple means of subdividing a large environment: Boosters are effectively DCC repeaters, replicating the electrical signal at a restored power level, without making any other changes.

The consequence is that DCC operates at a relatively low speed for a digital communications system, around 12,000 bits per second (12 Kbps). This is sufficient to support about 200 DCC messages (called instructions) per second in one direction, or half that with responses. DCC was also fundamentally a one-way system (throttle to train), although it was later augmented for a limited return-message capability. And because DCC only has repeaters, and not bridges, it's not possible to gain more message-per-second capacity by subdividing the layout. Those 200 instructions per second are the most you can get on a DCC layout of any size.

Note: bit speeds and messages per second are both approximate, as the bit speed is variable and message size can also vary.

Two hundred messages sounds like a lot, but consider what those need to do. Each time someone adjusts a throttle, moves a turnout, or sounds a horn or bell, a message is sent. A yard switcher may be making a half-dozen throttle changes in a second as a knob is slowly turned. If signals or crossing-gate accessories are also being controlled each time a mainline locomotive or resistor-equipped car crosses a track block boundary, more messages are being sent.

On a club layout, or even a large home layout, that limit may become something of a constraint. And if there are more messages than capacity, what happens is that things get delayed. Turn the throttle and the train may not react as quickly as usual, which could be very bad for that yard switcher.

DCC instructions are fairly short and simple, designed to put a few 8-bit (one byte) values into Configuration Variables (CVs) to control things like direction and throttle setting. This limits the complexity of what you can do, although that's been sufficient for most things people have wanted to do. After all, the things that need to be controlled on a layout are relatively simple, or at least they have been. But with more capacity, there will be things we can do that we couldn’t do before, and didn’t realize we even wanted.

And finally, while DCC does have a return message capability, RailCom, it’s limited by the need to have lots of detectors placed on the layout. Only one decoder can be communicating backwards to a detector, so if multiple trains can be on track powered by one booster, multiple detectors will be needed under that booster. And there’s an interesting gap in the standard: when detectors are used separate from the command station, there’s no standard way for them to report messages back to it. It’s pretty obvious that a control bus is implicit there. That’s not surprising since Lenz came up with RailCom and Lenz has a control bus. But since DCC didn’t have a control bus, until now, there’s none referenced by the DCC RailCom standard. If you need to add a control bus to use RailCom, you can’t really use RailCom as a substitute for a bi-directional control bus.

LCC in comparison uses modern networking technology. Twenty-six years ago, a network interface cost hundreds of dollars and was a circuit board larger than an O-scale locomotive. That wasn’t practical to use for DCC. Today network interfaces are found as a chip set that costs less than US$5. Use of a real network technology allows for many more devices on the network, with more capability in terms of what they can do. It also means that gateways can be created to interface to other technologies, like wireless.

At this point you may be saying "but my DCC throttle is wireless". That's true, but what goes from your throttle to the command station is not DCC. It's a proprietary method used by one vendor (or a group of vendors who license the technology). It's basically a control bus of very limited scope, and often a one-way system like original DCC. LCC could be that control bus, and bring additional standardized capabilities to handheld throttles, such as reporting values from trackside speedometers or displaying the state of signals on the throttle (think Cab Signals), or the locomotive motor's load as a percentage of total capacity. And it means that throttles wouldn’t have to be bought from the company making the command stations, so picking a good, reliable command station wouldn’t lock you in to only using one brand of throttles.

LCC today runs at 125,000 bps (125 Kbps), roughly ten times the speed of DCC. LCC messages are longer, and can be chained to transfer even more data. This results in an approximate capacity of about 1300 messages (or "events") per second. That's highly variable and can be increased somewhat with shorter messages, and will be lower with really big messages.

More importantly, the physical network technology it's based on, the Controller Area Network (CAN) Bus, currently supports speeds up to four times that (500 Kbps), and because LCC is for stationary devices and because LCC networks can be subdivided by bridges, a layout could mix older 125 Kbps equipment on one CAN segment with newer, higher-speed, equipment on another, and the two would still communicate with all the capabilities of LCC. This means that long-term, LCC isn’t limited to the capacity it has today. Unlike DCC, it can grow to meet increased needs in the future.

Other Benefits of LCC

So by moving "accessories" off DCC and onto LCC, capacity (in messages per second) is freed up in the DCC system to run more trains. Although potentially important for clubs, that won’t matter to smaller layouts. But that's only part of what LCC brings.

LCC is bi-directional and doesn't require a central station. It's also based around "events" (although there are other types of messages) that can be received by more than one device. As mentioned above, this means more than just accessories sending status back to a computer. It means that one accessory (like a signal mast) and communicate its status to another (like a cab signal display on a hand-held throttle). Proprietary systems can already do that, but this is a way that anyone’s signals could work with anyone’s throttles. And that will ultimately sell more of both, which helps us all out by spreading out the development cost.

LCC supports simple event messages, with which you can do anything that a DCC accessory decoder could do, but it supports them equally well in both directions, so you can have block occupancy detectors reporting status and turnouts being thrown by distant switches on a dispatcher's panel (or on a walkaround throttle, although that requires a bit more than what LCC has today).

LCC also supports larger messages: "datagrams" can transfer up to 32 bytes of data as one action, and "streams" can move even more. Just how these will be used remains to be seen. One idea that comes to mind is digital voice over a stream. Imagine tower operators calling the dispatcher using a handset, without the complexity of wiring up a multi-station phone system. There's a lot of future capability in LCC that we can only begin to imagine applications for.

And as DCC eliminated the mess of block wiring underneath layouts, replacing it with a track power bus, LCC will eliminate all the wiring for accessories other than power supplies. Of course DCC accessory decoders could eliminate most of it also. What really matters are the things it does, or does easily, that DCC can’t do.

An Example

To provide a concrete example of what LCC could do today, consider a signal system using block occupancy detectors, with crossing gates, as shown below.

To do this with DCC, you’d need some kind of central system, such as a computer running JMRI software. You’d also need the equipment to connect that computer to DCC, and you’d need to write some scripts on the JMRI system to receive occupancy reports and set signal masts to different colors, which is not a trivial thing for the average modeler to do.



Without using a computer, you could implement a basic system entirely with LCC nodes that communicate with each other over the bus. Once they were initially configured, these would work automatically without any kind of supervision or any external system.

A detector is one type of node, issuing an event when its block becomes occupied, and another when it becomes clear. A signal is a second, going red when the block beyond it is occupied, and yellow if that block is empty but the next signal down the line is red, and remaining in that state until it gets another event from one of those detectors or the distant signal. It is also an issuer of events, sending one out each time it changes color. And finally a crossing gate listens to the block detectors on either side, and brings the gates down when one becomes occupied without the other being occupied recently, and up (after a short delay) when the first block clears.

Each of these is basically an LCC event consumer or producer (the signal node type is both) with a tiny amount of memory for recent events, a timer, and a small processing requirement. The crossing node would have the flasher control for the crossing, and could even include a simple servo-motor driver to lower the gate and a digital audio player to sound a recording of a crossing bell. The detector only needs a simple current-flow detection circuit, and the signal has merely a LED driver circuit supporting three LEDs.

It's also more efficient than DCC because there's no central station and each message can be used by more than one receiver. Assuming the track was signaled for bi-directional operation, each time a train moves from one block to another two detectors have to report status changes, and a total of five signal heads need to be updated. With central control, that's seven separate messages, eight if there is a crossing.

With LCC this could be done the same way, except that the messages are coming from the detectors and the signals as shown above, using essentially the same number of messages (one less if you have a crossing gate, since no separate message is needed for it; it just listens for the events the detectors are already sending). However you could also just have each signal listen for messages from the two adjacent detectors beyond it. That reduces the number of messages on a change to just two, from the detectors, and not send any.

But rather than save capacity, it’s probably more useful to have signals emit events reporting their color as they change. That way, if a central station is wanted (e.g., to show a track diagram with signals) it can listen for those messages and simply display them, requiring very little configuration. Because LCC has lots of message capacity, you can do that without being concerned that a layout with lots of signals would become overloaded.

The Cost of LCC

This kind of LCC node doesn't need to be expensive either, as long as there is sufficient volume of production. The two CAN Bus chips required cost a grand total of US$3 per set in quantity 100. That needs to have a processor and other supporting circuits added to it. But when you consider that cheap Arduinos sell for significantly under US$10 today, and have more than enough capability, it's not unreasonable to expect that we'll eventually have simple LCC nodes sold with and adding around US$20 to signals, occupancy detectors and crossing gates.

We're not there today, of course, and nobody is making this kind of LCC node yet. As we'll see next time, present-day constraints on LCC segments and low scale of production means that there's a bias toward large, complex, nodes that can do many things and sell for high prices (to recover all of the development costs over a small volume of sales).

As a hobbyist, you can also build your own LCC nodes using an Arduino and a CAN Bus shield. This needed equipment lists for around US$70, although it’s probably possible to get the necessary boards (an Uno and a CAN Bus shield compatible with the OpenLCB libraries) cheaper if you shop around. I’ve added a page to my Arduino section to discuss this, but I’ll note that I haven’t done anything with LCC yet myself.

Summary

it’s going to take time before we have all of that, but the potential is there. It will take time for manufacturers to get onboard and develop products, and for hobbyists to buy enough to motivate further investment. DCC took a long time to catch on too. But it's a feedback cycle: as retail costs come down and capability goes up, more people will buy into LCC, and the volume will drive costs down, and competition for those sales will drive capability up, and the cycle repeats. Along the way hobbyists who never thought they’d want a control bus will be seduced by one capability or another, and the market will expand further. And manufacturers chasing more sales will come up with new and interesting capabilities to lure in more customers.

LCC has the basics to get things started now, and the capacity and flexibility to grow over time. I'm optimistic about its potential for the long term.

I also have some more pessimistic concerns about the short term, and I'll get to those in a future post (probably the third in this series). But overall, optimism wins out. I may not use LCC on my next layout, as I'm a fan of many small nodes rather than a few big ones, but I certainly see it in my future.

Tags: Lenz, NMRAnet, LCC, NMRA