LCC III - Messaging

Back in October I started what I thought would be a relatively easy, if perhaps a bit long, post on messaging in LCC. I was trying to cover it in detail, explaining how the ideal LCC had to be adapted on CAN Bus. That proved distracting and I put that material aside to just focus on the basic messaging capabilities of LCC rather than the implementation on CAN Bus, at least to the extent I could.

In the process of doing this, I've managed to chase myself in circles more than a few times. The LCC standards are very confusing, even by NMRA standards. We're talking about documents written by volunteers rather than professional standards-writers, and generally without a whole lot of editing. I've been reading NMRA standards for more than 25 years and I'm used to having to work at it to puzzle out the actual meaning. But still, the lack of clarity in the LCC documents is exceptional.

I'll detail problem areas throughout this post, but it basically boils down to things either being omitted entirely from the documents or being covered in one of the other technical notes than the one you’d expect. And there's a fair bit of using two different names for the same thing and, conversely, using similar names for two different things.

The revised post is about messaging in LCC and what you can do with it now, and additionally I'm coming at this as a review of the LCC standards, not anything external to them. The OpenLCB team has written a lot of words about OpenLCB, and that’s often helpful, but what matters in a standard is what's actually incorporated in it, either directly or by reference to or citation of an external document.


LCC II - How It Works - Physical

This is the second in a series of posts on the NMRA's new Layout Command Control (LCC) standards. The first post covered the reasons why a control bus, and specifically LCC, were important, as well as providing a fairly high-level view of how LCC works. Today we'll get into some very specific details regarding the physical aspects of the network, specifically the CAN Bus wiring and usage. Next time, I'll cover the actual messaging on the network (i.e., what you can do with it).

LCC I - Layout Command Control

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.

NMRAnet - Why You Should Care

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. Read More...

Standards, The NMRA, and Japanese Trains

I recently renewed my NMRA membership, and that set me to thinking about their role in standards-setting, and what it means for the hobby, and about the application of standards to the Japanese-prototype Model Railroading I do today. I’ve been an NMRA member for 20+ years, and the reason I originally joined was to get access to their standards, back when that meant buying a three-ring binder full of paper. Today, those Standards and Recommended Practices are available online, free for anyone to download (the Data Sheets are still members-only, but those are less critical although full of useful information), and I think that’s one of the best things they’ve ever done, even if it does give people one less reason to join.

LocoNet: A DCC Control Bus

DCC is really about getting power and control information to the track. But there’s another side to it: how do the commands from the throttle (the controls) get to the DCC system, and how do different parts of the DCC system communicate with each other? The first part isn’t covered by the NMRA’s DCC standards, so each manufacturer does the throttle-to-command-station link in their own proprietary manner. The second part is partially standardized, as the NMRA has Recommended Practice RP-9.1.2 Power Station Interface to describe how a command station sends commands to booster stations, but they don’t say anything about how devices like stationary decoders or occupancy detectors report their status, although there’s a draft of a standard for an “NMRAnet” control bus being developed which will probably fill this gap, someday.

Track Voltage, Motor Voltage, and DCC

As I’m finishing up the wiring for the two upper-level loops (one of which will be DCC-only, the other will be the switchable DC/DCC line), I’m also getting my DCC electronics set up and ready for use. There are several aspects to this, and I’ll cover others in future musings. But today I’m going to write about track and motor voltage. I could have just used the command station as it came, and it probably would have worked fine. But I like understanding exactly what’s going on under the hood, and so I ran a number of tests and spent some time researching what the track voltage should be, and why, and what that meant for the motor on a train. And if I ever add a booster, it will be important for it and the command station to be set to output the same voltage (this avoids problems when a train bridges between two power districts), so I may as well pick a voltage now.

Subway Track Cleanup, Etc.

This weekend went largely to the beginning of the final (I hope) laying of the subway track, which has been in place, in whole or in part, through more than six months of construction. As a result, it has gotten a bit dirty. All track was pulled up, cleaned with isopropyl alcohol on a cotton pad, and relaid. At the same time, insulated unijoiners (black, in the photo above) were inserted to divide the track into electrical blocks (for power feeds and future occupancy detectors) and power feeds were wired up to terminal strips under the table. I didn’t get it all done, perhaps a bit more than half, but I should be able to finish it during the week and run trains by next weekend.

December 2009 Status - Subway Track in Place

The subway level track is nearly complete, with the underlying foam and cork glued down, and the Unitrack in place. Read More...