I just got my latest RMC and in their Timetable section, pages 36-37, there is an illustration at the bottom referencing LCC, and calling it the new NMRA standard. It seems to say you can program your layout without a computer. It doesn't seem to be an ad for any particular brand and there is no website referenced either. I often find my self out of the loop when it comes to new technologies and this is the first I have heard about LCC. What is it and what will it do?
electronic control for the rest of the layout
http://cs.trains.com/mrr/f/744/t/250022.aspx
Henry
COB Potomac & Northern
Shenandoah Valley
Here are the FAQs from the NMRA.
http://www.nmra.org/sites/default/files/standards/lcc_faq_handout.pdf
It has not been recently updated. There are in fact products available.
RR-Cirkits is one company that has products available.
OpenLcb is the group that is developing and testing the LCC standards.
http://openlcb.org/
It's a set of standards for controlling the layout bus like DCC. I don't know why they would reference it in RMC since there are no products out that use it yet. It's really just a bunch of propsed standards right now, some of which haven't even been reviewed by the NMRA.
The idea is that DCC is really meant for just controlling locomotives and is not that good at automating the layout. I can't really agree or disagree with this, but it's clear that there need to be standards for at least the following things that I've actually investigated that don't have them; LCC covers these and more:
Yesterday I downloaded the current packet of what's being reviewed from the NMRA website. I don't think we'll see anything for it in the next couple of years.
Here is their FAQ on what LCC is. I didn't find it that helpful, but YMMV:
To further confuse the issue, here is the non-NMRA website from wihich the NMRA has derived LCC:
Hope that helps. I know I was clear as mud.
Julian
Modeling Pre-WP merger UP (1974-81)
Layout Command Control is kind of a new, advanced form of DCC the NMRA has been working on creating, which should make control of trains, signalling, lighting etc. easier and more integrated. At this point it's not being manufactured or sold, it's still a work-in-progress.
http://www.nmra.org/news/facts-about-lcc-new-layout-command-control-standard-nmra
fieryturboI don't know why they would reference it in RMC since there are no products out that use it yet.
This is incorrect. There are infact products available. http://www.rr-cirkits.com/
fieryturboIt's really just a bunch of propsed standards right now, some of which haven't even been reviewed by the NMRA.
This is not accurate. There are 15 or so approved NMRA LCC standards. There are 4 that have been submitted for public comment before being finalized and submitted to the NMRA Bod for approval. These standards, unlike other NMRA standards, are not directly useful to the individual user, unless you are making your own components. They are standards for interchangibility just like DCC standards exist for interchangibility.
The intent is to have a compatible components from different manufacturers that can be used together in one system, instead of a bunch of different proprietary systems that have no interchangeable components.
wjstixAt this point it's not being manufactured or sold, it's still a work-in-progress.
See above post.
BMMECNYC This is incorrect. There are infact products available. http://www.rr-cirkits.com/
Wow, yeah, I may have to get the starter kit from them once I've got my track laid out. I had no idea that existed.
..but now that FAQ is wrong, and should be revised since it's a top hit on Google.
NMRA Because the NMRA just approved and released the LCC Standard to manufacturers, as of this writing (late June, 2015) there are currently no products that we know of that are ready for LCC.
Because the NMRA just approved and released the LCC Standard to manufacturers, as of this writing (late June, 2015) there are currently no products that we know of that are ready for LCC.
wjstixLayout Command Control is kind of a new, advanced form of DCC the NMRA has been working on creating, which should make control of trains, signalling, lighting etc. easier and more integrated.
i don't think it is a replacement for DCC to control locomotives.
I think it builds on Bruce Chubb's C/MRI, computer model railroad interface. At the very least,
greg - Philadelphia & Reading / Reading
gregc I think it builds on Bruce Chubb's C/MRI, computer model railroad interface. At the very least,
Possibly, though I'm more inclineed to think it draws more architecturally from MERG CBUS than C/MRI. It's inclusion/exclusion choices of what it controls are along the lines of C/MRI though.
I honestly didn't think anyone would crank out hardware this fast. Kudos to them, I'm definitely interested in using this instead of DCC-controlled layout stuff. It looks like it will be ready just in time as I'm ready to motorize the turnouts and add signals on my layout.
Actually, it derives mostly from OpenLCB.
There's nothing new int he design, the transport bus is CAN, which has been used for years in cars. Chipsets and software for all major microcontrollers has been available for a long time. The keys to getting hardware out thre were waiting until the NMRA finalized the addressing scheme and the command set. Pretty sure existing OpenLCB designs would work as-is with LCC, although there really weren;t many commercial products, it was mostly a DIY thing.
As a Digitrax user, I have to think long and hard about running another bus around my layout - Loconet can handle anything LCC can. If I used NCE or CVP, there isn;t much choice. The bus structure of those systems can't handle high volumes of bi-directional control information.
--Randy
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
fieryturbo..but now that FAQ is wrong, and should be revised since it's a top hit on Google.
I sent an email to NMRA national yesterday, requesting just that. I dont expect an immediate reply. I could also hit it from the other end through the OpenLCB or LCC yahoousers groups.
Edit:
As of the Portland convention last year, the CMRI and LCC people were discussing some sort of bridge between the two systems or compatibility of some type. I do not know how far this has gone.
gregci don't think it is a replacement for DCC to control locomotives.
It is not the intent. From what I have gathered attending the clinics at the NMRA convention, the intent is to add a standardized layer of command control for the rest of the layout (everything not on the tracks), with the option to control the trains with it if you want. The discussions on how to communitcate with legacy systems is ongoing. It has been done with Open LCB. You can even run a train from the other side of the world with this.
The presentation at the convention also showed an OpenLCB layout with a multiple brands of throttles all connected to the same OpenLCB bus. I dont know if this is something that can be sold by a third party manufacturer or if it has to be a DIY product or produced by DCC companies (Digitrax, NCE) due to copyright laws (something like that, Im not a lawyer).
Some good information here. Thanks to all who replied. If I understand what is on the NMRA website, LCC is nothing more than a system to seperate the stationary decoders from the DCC system and give them their own dedicated bus which will also be capable of two way communication. Sounds like a common sense approach to the problem of overloaded bus lines.
I am a lone wolf operator and have yet to use stationary decoders. I control my turnouts via fascia switches or ground throws. I even have the non-DCC Walthers turntable so it would seem in my present situation LCC would have little value for me. Eventually I would like to install a signalling system not because I need one for operations but simply for appearances. If LCC can simplify that then maybe it will be something to look at in the future. That is probably several years away at least. Perhaps by then the standards will all be in place and a simplified system available. I'm thinking it would be nice to be able to set a route when I'm ready to move a train and all the turnouts and signals would automatically be set appropriately. I'm a big propoenent of the KISS approach to everything.
jecorbettIf I understand what is on the NMRA website, LCC is nothing more than a system to seperate the stationary decoders from the DCC system and give them their own dedicated bus which will also be capable of two way communication
stationary DCC decoders are one way to control remote devices using the DCC bus connected to the track. LCC is a different protocol and would use devices incompatible with DCC. The NCE cab-bus is an example of a bus incompatible with DCC.
The Pacific Southern is at least one model railroad that has a custom bus and software for controlling the railroad (i.e. turnouts, signals and occupancy detection input).
jecorbettI'm thinking it would be nice to be able to set a route when I'm ready to move a train and all the turnouts and signals would automatically be set appropriately.
But like real roads, there is someone controlling routes (i.e. turnouts and signals through the system interface. It's one thing to define a bus and devices compatible with it. But the bus doesn't define the features that use it. Of course LCC may not be useful on smaller railroads.
gregc jecorbett If I understand what is on the NMRA website, LCC is nothing more than a system to seperate the stationary decoders from the DCC system and give them their own dedicated bus which will also be capable of two way communication stationary DCC decoders are one way to control remote devices using the DCC bus connected to the track. LCC is a different protocol and would use devices incompatible with DCC. The NCE cab-bus is an example of a bus incompatible with DCC. The Pacific Southern is at least one model railroad that has a custom bus and software for controlling the railroad (i.e. turnouts, signals and occupancy detection input). jecorbett I'm thinking it would be nice to be able to set a route when I'm ready to move a train and all the turnouts and signals would automatically be set appropriately. But like real roads, there is someone controlling routes (i.e. turnouts and signals through the system interface. It's one thing to define a bus and devices compatible with it. But the bus doesn't define the features that use it. Of course LCC may not be useful on smaller railroads.
jecorbett If I understand what is on the NMRA website, LCC is nothing more than a system to seperate the stationary decoders from the DCC system and give them their own dedicated bus which will also be capable of two way communication
jecorbett I'm thinking it would be nice to be able to set a route when I'm ready to move a train and all the turnouts and signals would automatically be set appropriately.
If I were invested heavily in stationary decoders I would have to think long and hard about adopting an incompatible system that would render them useless. It seems to me that if the idea is to seperate layout control from locomotive control it would make sense to adopt standards that would work with equipment people already have in place. Since I haven't yet bought any stationary decoders, it wouldn't affect me negatively if I were to adopt LCC but I can understand some people being upset that what they have wouldn't work with a new technology.
But there's no need for anyone to get upset. So what if you have existing stationary decoders that don;t work with LCC? How are you going to control them anyway? How would you control LCC stuff? The two most popular programs are JMRI and Railroad & Co. Both support all popular DCC systems AND LCC. Pretty sure RR&Co can do it, and JMRI DEFINITELY can interface to more than one system at a time and mix and match what is controlled in the logic and panel definitions. It's already being done, by people who have say NCE for DCC and then use a standalone Loconet or CMRI for the detection and signaling. You cna have a JMRI CTC panel where you flip the lever and it lines a turnout controlled by an NCE stationary decoder on the DCC bus while also changing the aspect of signsl that are in no way connected to DCC but instead driven off the Loconet or CMRI bus.
It's nice they set up a standard and all, but I can;t get super excited over this - that cat has been out of the bag for YEARS now and the majority of people already doing advanced stuff are using either CMRI or Loconet. Either brings a wealth of commercial as well as DIY options.
Me, I was thinkign about using a variation of CMRI, or at least RS485 communications, but there are some hard limits on the number of nodes you can have on a bus, which renders the idea of lots of small, simple control points not feasible. The specs usually say 32 devices max, but there are ways to get as many as 256, which would work fine. CAN bus as used in LCC is an option, but there aren't many CAN interfaces for Arduino for some reason, and the main one out there uses DB9 connectors, so you have to make adapters to RJ45. My current line of thinking has them using Ethernet. A real find would be cheap thinnet transceivers to wire it up as a linear bus with taps, old coax thinnet style, instead of every device running to a hub or switch. By the time I get to that point, there will likely be more and less expensive CAN bus options. I dislike the idea of centralized controlles with tons of fine wire stringing out all over the place to signal head and detectors, I'd rather have a small device (like Arduino Nanos) driving just the turnout and signals around it. I plan to do my own software though, I just can't stand Java and Python scripting.
The whole point of Layout Command Control is to move non-train control messages off the throttle network and onto its own dedicated bus.
Some, like LocoNet, can handle a lot of traffic, whereas others cannot. Which leads to slower responses.
By moving to a new dedicated bus, you can create a standard protocol for communications between devices, and get away from proprietary throttle buses. If you wish to build a signalling system you can use LCC devices from a number of suppliers and not be tied to a specific throttle bus with a limited number of devices available for it.
It also allows inter-operability since the protocol isn't tied to one manufacturer, and his whims about licences, features and cost. So others can get into the game easily, or you can make your own stuff with an Arduini or RaspberryPI device as a starting point. All you need is an LCC Library to interface with the LCC network.
If someone wishes to build an interface for the NCE-Bus, XPressNet or SX-Bus, they could with the proper licences, and allow you to use an NCE or Trix device with your current DCC System, with the proper interface to its throttle network.
The CAN Bus has already been used for years by Zimo and MERG, so it can be done.
one big advantage of DCC is that no special interface components are needed. The polarity change timing communicates the data which is easily captured using small pico processors. And of course, the connector is the track and wheels.
Presumably LCC minimizes the bus components as well. I'm not familiar with CAN. But rs-485 interace chips are very inexpensive (~ $0.10), require only a single pair wires, can be chained together and requires no system component (e.g. ethernet hub). The various 2 terminal screw terminal may be the most expensive (~ $0.10) components.
PIC or Atmel processors are inexpensive (~ < $1)
While the limitation of 32 end-points for something like rs-485 may seem small, each node could support 1-3 bytes of I/O -- 24 input and outputs. Inputs used for occupancy detectors and turnout position indications, and outputs used for turnout control and signals.
So, a simple node can be relatively inexpensive: processor, bus driver, parallel/serial shifter registers and many connectors.
On the other hand, a system supporting nodes with a small number of I/O (e.g. quad turnout controller) will require more nodes, more communication and bandwidth and more cost ($$).
However, it seems LCC is much more sopisticated based on the NMRA paper which describe a bus. It appears that the bus-specification includes messages for identifying components by manufacturer, function and ID on the railroad and control software that is .xml based. It seems to me that LCC may be intended for self-discovery of components (i.e. plug and play).
But unlike DCC which defined CV registers and had the well defined goal of controlling a locomotive, it seems to me that LCC may be intended for more than just the current devices and functions on railroads today.
I'd really like to see a concept paper describing how LCC would be used and on what size layout it becomes useful.
As I do more reasearch, there are 1/4 load RS-485 devices which allow 128 devices on the bus. The common modules you find cheaply on eBay and elsewhere use the MAX485 which is a full oad device and you cna use only 32 on the bus, but the MAX1487 is pin compatible and a 1/4 load device, exact repalcement for the MAX485. All are listed at the same price, the cheap adapters likely have fake parts like many low cost Chinese electronics.
I'm not sure whi CAN bus was chosen over RS485. Both are very common, meaning the parts should be relatively inexepensive (no specialied model railroad product here). Both work well in 'noisy' electrical environments (CAN in automobiles and RS485 is widely used in industrial automation). Can may have a slight advantage in the bus cabling, it does not need shielded cable whereas for longer runs of RS485 almost demand it, especially the faster you run it. CAN interface chips probably cost a bit more as anything made for automotive use almost has to be extended range temperature and operating voltage. The only real difference is in the addressing protocol which allows CAN to support more than 128 devices.
There are two parts to each of these systems, the link layer hardware protocol and then the software layer on top. The CMRI protocol is somewhat defacto for RS485 model railroad applications, and it has some limited discovery capability for nodes to identify how many ports of input and output they have LCC does have a more sophisticated protocol which indeed should allow device self identification. There are enough bits so that each different board from a given manufacturer can have its own ID which, when coupled with a database of products, would exactly identify each board (they learned from DCC and added extra bits, so unlike decoder ID where you cna get the manufacturer and maybe the family, but not the exact model since in many cases the exact same firmware is used in half a dozen different form factor decoders, you SHOULD be able to get exact product identity, as long as the manufacturers aren't lazy and actually use different values in those fields for different products). There was something odd about the definition though that I noticed, I posted about it before. Something to do with reserving what I think was too many bits of the address field or something, I forget exactly what, but my old post should uncover it. It is probably meaningless for any but the hugest of layouts, but it did make me wonder what they were thinking.
At least for now, RS485 seems simpler for the DIYer. As devices become available, that may change. You can freely use the CMRI protocol, or make up your own, since you know what your nodes are, you can define how to communicate with them. Fully implementing LCC may require a micro beyond the common 8 bit ATMegas or PICs. They are out there, the ARM based Atmel micros for one, and they are still cheap. But it depends on what you are doing. It's impossible to stop progress, but what's the cost of this progress? Even simple programs need gigs of RAM now, and each version just gets bigger and bigger as more features get tacked on - many times things half the users don't even want or need. But Version 5 has to be made 'better' than version 4 somehow. Who programs a modern Intel CPU in assembly? It's next ti impossible because there are so many opcodes. Higher level languages are almost a must. I still remember the 91 instructions of my first 8 bit processor. Still have the computer, and it works. It's more than fast enough to run railroad things. I'd build my control system around it if the CPU and supporting components weren't so rare. Things like detection, signaling, and controlling turnouts do not require super high speed transmission lines and ultra fast multi core computation. Even sequencing structure lights in a realistic fashion doesn't require much computational power. 15kbps is on the slow side for RS485 (even the slower chips can do nearly 20x that, the fast chips nearly 200x!), but it is insanely fast compared to how real railroad CTC signals were send to control points.
LCC is an accessory bus that operates beside, and in conjunction with, your layout's traction control. Similarly to DCC, it allows users to buy compatible products from multiple sources. It is a set of protocol standards and tecnical notes directed at manufacturers (an DIYers).
OpenLCB is the open group of people, the ideas, and the technology powering LCC. Since LCC is extensible, the OpenLCB group continue to discussion and develop new aspects and protocols which can/will be merged into future LCC editions. It is an open group, and if you are interested in imagining, influencing or developing the future, please join us.
Below is a summary of LCC design points. However, I wanted to respond to some of the previous posts. LCC is the common infrastructure on which manufacturers can develop innovative products. That infrastructure allows additional features such allowing mutlitple LCC bus segments, integration with legacy buses, and self-descripton and discovery of nodes. It is superficially similar to CMRI, Loconet and CBUS, but with much expanded capabilities. Because of these, it will require more computing resources to reach its full potential -- however, since computing power per chip is increasing very rapidly without increased cost, we do not think this is an issue. For example, present 32-bit ARM processors have more speed, power, and memory than similarly priced to 8-bit processors, further consider the capabilities of the $5 Raspberry Pi. LCC is designed to use many transports, including Ethernet, Wifi, RF, and other local buses. CAN was chosen as a local transport since it is well-known and robust with built-in error detection and correction. RS485 could be used, but no-one has implemented on it (yet).
One point that needs to be made explicity is that: No-one needs to abandon their present hardware. If "it ain't broke, don't fix it". LCC products will work along-side or connected to your present hardware, although you will need an adapter.
LCC is designed to be:
To achieve the above, LCC has:
Hope this helped,
DavidOpenLCB/LCC Dev Team
PS: LCC Standards docs are available at: http://www.nmra.org/index-nmra-standards-and-recommended-practicesand http://openlcb.com/openlcb-and-lcc-documents/layout-command-control-lcc