Getting started with LCC (Layout Command Control)

[Kiran]

I thought I will start this thread to see if there are any LCC users out there on the forum. I could also use this to document my experiences with the technology as I attempt to implement LCC on my layout under construction. I am not an expert in this by any means. So feel free to correct me if I am talking nonsense. 

 

So what is LCC?

 

Here is what NMRA has to say about it: https://www.nmra.org/lcc.

 

There is even a book written about LCC https://www.amazon.com/Introduction-Layout-Command-Control-Practical/dp/0988825902

 

Here is a presentation about LCC from folks who have been very involved in the development of the standard via OpenLCB https://www.nmra.org/introduction-layout-command-control-lcc. One of them who happens to be a colleague convinced me to go down the LCC route.

LCC Clinic by Balazs Racz covers a ton of information about setting up a layout with LCC.

But here is what I understand. DCC is great for running multiple trains on your layout at a time. But it has limited bandwidth and it is essentially, for the most part, a single way communication system. The command station sends a set of commands to a specific decoder and that decoder  goes and does something. This will work fine if you are just running 3 or 4 trains on a layout. But some of us might want to do more. One could have a large-ish layout at home with a yard (depot), a large station, a switching yard, etc. You may want to implement block detection so you know where your trains on the layout at any given time. You may want to be able to throw your turnouts remotely or based on occupancy status. And then you may want to have signals and/or lighting for buildings and things on the layout. Finally, you want to have some automation on your layout or control the layout with software such as JMRI. All of these things can be done with DCC by using accessory and lighting decoders. But the DCC bus, as mentioned earlier, has limited bandwidth and so things can slow down especially for larger layouts. If that locomotive doesn't respond to your speed step down command in time, it might be because the command station or the bus have a long list of commands queued up. LCC will take some of the command traffic off the DCC bus. Your trains will use the DCC bus while all the accessories such as block detectors, turnouts, signals and anything else can work on the LCC bus. LCC also supports 2-way traffic or it is bidirectional. 1 LCC device (or node) can potentially talk to another and exchange information. So you can potentially automate things like throwing a turnout in the correct direction for a train based on block occupancy status without requiring a computer/proprietary logic controllers.

 

Why did I decide to use LCC on my layout?

 

When it is complete, my layout will have approximately 70ft of double track mainline and a similar length in single track branch line. There will be a larger staging yard/storage for trains and a smaller yard on the branch line. I am planning a large urban station and 3 or 4 smaller stations. There will be a lot of turnouts. I want to have LED signals on the mainline and maybe semaphores on the branch line. I have a ton of block detection sensors. I use long blocks as well as short blocks. Short blocks are for spot detection such as at the end of the platform. I am planning to have interior lighting in some buildings that I want to turn on and turn off. I also want to eventually have announcements in stations and be able to detect which train is coming into which platform so that I can play appropriate announcements. I also want the option of being able to program automation sequences so that a bunch of trains can run automatically if I don't feel like running trains on my own. Again, all of this is potentially possible with DCC and JMRI software but for future extensibility, a colleague convinced me that LCC is a better option. 

 

The good thing is that LCC can coexist with my existing DCC products. I have NCE command station and booster SB5. I have begun investing in some NCE accessories such as BD20 block detectors and Switch-Kat decoders but I haven't gone too far down this route yet. It won't be a huge financial hit if I abandoned NCE layout accessory products.

 

How did I get started?

 

At the outset, let me tell you that the learning curve is rather steep. Most folks using LCC effectively are very advanced users with strong technical chops. But they are very helpful. I joined the layoutcommandcontrol@groups.io group and started asking questions.

 

For all essential purposes, at this point, there is only 1 company that makes LCC products. That is RR-Cirkits and their products are listed at http://www.rr-cirkits.com/description/index.html. I contacted the company and Dick Bronson, the owner gave me a lot of great suggestions. I ordered a few starter products. I prefer to experiment on a small layout to get a hang of things. So I setup a simple layout with 4 blocks using Kato Unitrack and insulated unijoiners.

 

LCC uses CAN bus which has proven reliable in a lot of applications. On your layout, you will be creating a LCC bus using CAT 5 or CAT 6 cables and RJ45 connectors. LCC compatible devices (or nodes) are daisy-chained using CAT 5 cables. Each LCC node, depending on what type of a device it is, can support multiple LCC or non-LCC compatible devices. For instance RR-Cirkits Tower-LCC is an LCC node that can support up to 16 input or output lines. Most layout accessories such as sensors or turnouts need 1 or 2 input/output lines and so you could theoritecally connect and control 8-16 accessories. Depending on what type of accessories you want to control, you will need one of the daughter boards from RR-Cirkits such as the BOD4-CP or SCSD-8. BOD4-CP is an interesting board because it can be used for block detection for up to 4 blocks as well as to control 2 turnouts.

 

To start with, I ordered the LCC starter kit, a Tower-LCC, a BOD4-CP and CT4. The last one is a set of 4 coil transformers that you install on your layout and pass the feeder wire for the insulated block through the hole in the CT. It detects when a DCC equipped locomotive or rolling stock is inside the insulated block and sends this status to the LCC bus. All the initial configuration is done through the JMRI software.

Edited January 4, 2021 by Kiran
Adding LCC clinic

[cteno4]

Historical note one of the original JNS founders, captainoblivious, worked on the early versions of LLC when it was called NMRAnet.

 

jeff

 

 

[gavino200]

Thanks Kiran. Is it possible to mix DCC based block detection and turnout control with LCC? 

 

I'm interested in LCC based you this excellent thread of yours. I know that I'll be very dissatisfied if my DCC gets slow and buggy. However, I've already ordered a DCC block detection and turnout control unit. Is it possible to use some DCC block detection and then add on LCC block detection and turnout control later? Or Does the block detection all have to be LCC for the system to work?

 

[gavino200]

1 hour ago, cteno4 said:

Historical note one of the original JNS founders, captainoblivious, worked on the early versions of LLC when it was called NMRAnet.

 

jeff

 

 

 

Thanks. That was an interesting read. It got a little tense in there for a while, but ended up on a good note. 

[Kiha66]

Regarding the LCC book, it was written by someone in my local club.  I have an advanced copy if you'd like to borrow it, I don't feel its the most useful resource unfortunately. 

[gavino200]

Nice video about LCC. Interestingly presented by TCS who seem to expect to be manufacturing LCC components in the future. 

 

What I'd like to find however is a diagram of what a simple LCC detection and turnout/signal control system would look like. Also, does it need JMRI to operate it? Or will it work with other train control software?

 

Also, or related, I'd like to know what level of programming if any is needed. I could probably cope with copying and running code, but my actual understanding of computer code is zero. It's greek to me. Is that a deal breaker?

 

 

 

Edited January 3, 2021 by gavino200

[Kiha66]

From what I understand, LCC works without a central computer control.  In simple terms each item just does its job, and either sends out or receives signals.  A "producer" reacts to outside stimulus (such as a button press or track occupied) and sends out signals on the LCC bus.  A "consumer" reacts to signals on the LCC bus, and then reacts as programmed (such as changing a signal color, or throwing a switch).  The benefit is that canbus can easily handle all these messages being sent at once, and adding a new item does not require programing or changing any of the existing system.  The logic is also easier to figure out, as each item only needs to know how to react to a few stimulus rather than requiring the entire system to be programmed at once.

 

So the way a signal system would work is you'd have each block of track with a occupancy detector.  A LCC producer node would then send out a message that says "block ## is occupided" when it gets a signal from whatever detector you used.  This message would be received by all components on the system.  They then check if this is a message they are looking for, and if so they react as their internal logic for said component dictates.  

[gavino200]

3 minutes ago, Kiha66 said:

and if so they react as their internal logic for said component dictates.  

 

And the internal logic is what you program using JMRI?  Can it be programed by other operating systems too?

 

I have to say, I like the sound of it. 

[cteno4]

1 hour ago, gavino200 said:

Thanks. That was an interesting read. It got a little tense in there for a while, but ended up on a good note. 

 Yeah it was not a great interaction Ghan did not realize the effort that had gone into the submission of the specs, truly huge volunteer effort.

 

jeff

[chadbag]

1 hour ago, gavino200 said:

Nice video about LCC. Interestingly presented by TCS who seem to expect to be manufacturing LCC components in the future. 

 

 

Their command station is supposed to support LCC.

 

https://tcsdcc.com/commandstation

[gavino200]

2 minutes ago, chadbag said:

 

Their command station is supposed to support LCC.

 

https://tcsdcc.com/commandstation

 

As far as I can glean, LCC is separate from the command center. Are you interested in LCC or are you committed to using the Digikeijs detection modules? Do you know if you can mix and match both. I ordered my Digikeijs system this morning.

[inobu]

LCC is no different than Digitrax's Loconet in its basic functionality. Its is a protocol that runs over a CAN network. The CAN network allows devices to

communicate with one another. It is a 8 wire network platform configured like Loconet. 

 

The communication that occurs over LCC and Loconet still needs a software component to access and process the messaging

transferred from each device on its network. 

 

You don't need a command station per-say but the component in the Command station that reads and processes the messaging.

The best example is Digitrax Loconet. You can run loconet without a command station as long as you have a device that terminates

the Loconet signal and a means to extract the messaging, JMRI for example.

 

Loconet is a proprietary protocol owned by Digitrax where as LCC is the same concept managed by NMRA

 

Inobu

[Kiran]

2 hours ago, gavino200 said:

Thanks Kiran. Is it possible to mix DCC based block detection and turnout control with LCC? 

 

I'm interested in LCC based you this excellent thread of yours. I know that I'll be very dissatisfied if my DCC gets slow and buggy. However, I've already ordered a DCC block detection and turnout control unit. Is it possible to use some DCC block detection and then add on LCC block detection and turnout control later? Or Does the block detection all have to be LCC for the system to work?

 

I am still a beginner and so don't rely only on what I know :). Having said that:

1. You could potentially have part of your layout use DCC-based block detection and another part use LCC-based detection. But then, you have 2 separate systems which may or may not be able to talk to each other in the future. One way for them to talk to each other would be to use JMRI to control your layout. This is because in JMRI, you can combine block detection sensors from DCC/LCC theoretically. For example, if I had NCE BD20 block detector connected to an NCE AIU01 which is putting the block occupancy status on the NCE DCC bus but I have a turnout that is controlled via the LCC bus, I could have JMRI automatically throw the turnout if JMRI detects that the block is occupied. But then, you would lose the primary benefit of LCC. If the block detection and turnout control were on LCC, you could control the turnout based on block occupancy status without having to use JMRI.

2. Also, if I understand this correctly, block detection and signaling are by far the most common causes of the DCC bus getting busy because the system has to constantly check the occupancy status to change signals.

3. I could have used the BD20 block detectors from NCE that I had instead of the RR-Cirkits coil transformers but it was just easier to get the CTs. So depending on what DCC block detection system you have ordered, you may be able to use some of the components from it.

 

It really depends on how large your layout is likely to be and how far you want to go the automation and signaling route. If you are only going to have 7 or 8 blocks and a small number of signals, you should be OK with DCC based systems. My ambitions have grown over time though :).

[chadbag]

1 hour ago, gavino200 said:

 

As far as I can glean, LCC is separate from the command center. Are you interested in LCC or are you committed to using the Digikeijs detection modules? Do you know if you can mix and match both. I ordered my Digikeijs system this morning.

 

Read the link I gave.

 

For now I am using all DCC based stuff (Loconet with the Digikeijs CC).  When LCC gets more mature and has more vendor support I may branch out.

Edited January 3, 2021 by chadbag

[Kiran]

3 hours ago, gavino200 said:

 

As far as I can glean, LCC is separate from the command center. Are you interested in LCC or are you committed to using the Digikeijs detection modules? Do you know if you can mix and match both. I ordered my Digikeijs system this morning.

I am waiting to see how TCS implements support for LCC in their command station. There are some big gaps in the standard right now. For example, there is no easy way to address a turnout other than using an event ID which is a 16 character long alphanumeric string and no one is expected to remember that. 

[Kiran]

3 hours ago, gavino200 said:

 

And the internal logic is what you program using JMRI?  Can it be programed by other operating systems too?

 

I have to say, I like the sound of it. 

JMRI is available for a bunch of platforms (including Raspberry Pi). My next post will talk about configuring the nodes and I believe JMRI is the only way to do the initial configuration for RR-Cirkits LCC devices. But JMRI is free and open source and pretty simple to use. www.jmri.org.

 

No, you don't need to write code to get it working. You will need to copy and paste what are called event IDs but that's about it. The UI is complex and not the most intuitive but it is still pretty much graphical user interface.

[gavino200]

3 hours ago, gavino200 said:

 

As far as I can glean, LCC is separate from the command center. Are you interested in LCC or are you committed to using the Digikeijs detection modules? Do you know if you can mix and match both. I ordered my Digikeijs system this morning.

 

I read the article. Thanks. It does seem to be that TCS is committed to at least making their units compatible with LCC. 

 

Regarding Digikeijs, since it uses Loconet, then like inobu said, it isn't really a DCC based detection and control system. Rather it's a "layout control system" (in the general sense) that communicates using loconet while at the same time seperately controlling locos by DCC. It's similar to Digitrax. Same same but different. 

 

A question which is perhaps not very smart. How is the Digitrax or Digikeijs system a "DCC" detection and control system if they're using loconet? How is it that the DCC banwidth issue could affect their layout control elements? 

 

I addressed this to Chad as he's my Digikeijs compadre, but I'd like to hear from anyone who has an answer. Thanks 🙂

[chadbag]

 

I may be wrong but Loconet is a way to send DCC stuff not over the rails.  The trains are still identified by the DCC address (ie, your detection block will send back the DCC address of the train in the block when using Railcom or probably Digitrax transponding).  Things like switches still are addressed by a DCC "switch" address, etc.  But I have not delved that far into the underbrush of the whole thing as of yet.  Just done set-up and run stuff and that is how it appears to me.

 

LCC would be a different protocol over a different bus.  

 

Also, there is an LCC/Loconet hub on the RR-Cirkits website.   I am not sure how it all ties together.

 

[gavino200]

5 minutes ago, chadbag said:

 

I may be wrong but Loconet is a way to send DCC stuff not over the rails.  The trains are still identified by the DCC address (ie, your detection block will send back the DCC address of the train in the block when using Railcom or probably Digitrax transponding).  Things like switches still are addressed by a DCC "switch" address, etc.  B

 

 

That's how I understood it yesterday. What a difference a day makes. From relative clarity back to confusion.

 

 

5 minutes ago, chadbag said:

ut I have not delved that far into the underbrush of the whole thing as of yet.  Just done set-up and run stuff and that is how it appears to me.

 

Gotcha.

 

 

5 minutes ago, chadbag said:

 

LCC would be a different protocol over a different bus.  

 

Yes, that's what I understood Kiran to be explaining. I definitely see the value of having a separate bus. I really never heard of bandwidth limitations until Kiran mentioned them today. But I do plan on doing a lot of signalling, and automation. I know  I'll be pissed it the system become glitchy, and slow. 

 

 

5 minutes ago, chadbag said:

 

Also, there is an LCC/Loconet hub on the RR-Cirkits website.   I am not sure how it all ties together.

 

 

In that case do you know if Railcom will function with LCC. From the NMRA conference video and the TCS video it sounded like they would be compatible. 

 

Anyone know if an LCC "layout control system" can use Railcom?

 

I'd like to delve into the issue of bandwidth problems a bit more before getting to hyped about LCC. @Kiran I think I recall you mentioning that the bandwidth delay was something you experienced yourself on your test setup. Is that so? Or is it a second hand report?

 

If it weren't for this bandwidth issue I'd be happy going uniformly with Digikeijs. 

[gavino200]

Interesting article here. This guy argues that DCC systems don't run out of bandwidth but rather the bus just isn't very suitable for layout control for other reasons. I don't know enough to tell if he's just splitting hairs. 

 

https://sites.google.com/site/markgurries/home/technical-discussions/dcc-bandwidth

[gavino200]

It's late and I've been "researching" this for a while now. I've come across quite a few people saying that the Bandwidth slowdown is something of a red herring, but that there are other good reasons for favoring LCC. The manufacturer neutral argument is valid, I think, but it's not very important to me. I'm mainly interested in whether LCC can do anything to enhance or simplify my detection/automation experience. 

 

I find a few people claiming that setting up automation with LCC would be easier than doing so with DCC. The reason given is that the protocol/language is more modern and simple. Avoids CVs, complex addresses etc. I like the sound of this but am also skeptical as a novice. Often very technically adept people think what they are talking about is simple when in fact it isn't. 

 

The two way communication argument is also frequently given. The LCC system can get feedback from switches, and signals and can know what their position is at any time. This begs a question for me. How does a non LCC system function in this regard. Do you have to turn the system on with all the switches in a given position so that the system can "know" what's going on. That sounds like a nightmare. I can imagine multiple accidents stemming from switches being in the wrong position. If that's the case, then that alone would be a reason to go with LCC

 

How about programming, addressing, etc? I've been focusing on hardware and wiring, assuming that eventually I'd pick a software program I like and start learning it. I'd like to avoid unnecessary pain at the software/programming stage also, if possible, as it's not something I enjoy in itself. 

 

Can anyone tell me roughly what the process of setting up block detection and some basic automation would be like at the software level using a standard system (Digitrax, NCE, Digikeijs)? And what is the process like with LCC? How are they similar? How are they different?

 

Another interesting article I found: https://dccwiki.com/Layout_Command_Control

Edited January 3, 2021 by gavino200

[inobu]

DCC is a combination of a power supply, data transport and signal protocol all wrapped up in one system. 

 

DCC (Digital Command Control)

 

The commands to control the trains are ones and zeros formulated into framed data packet. The voltage on the track switches back and forth to create 

the 1 and 0 data bits. The decoders in the trains will read these data packets and extract the framed 1 and 0. This is the protocol. There is a bridge rectifier

circuitry that filters out the alternating DC voltage and makes it usable for the decoder to operate and run the motor and LED's

 

We also have Accessory  commands. These command are framed packets with an Accessory header created for stationary decoders. These decoders control and operate non mobile devices. One of the most common is the switch turnout device. Some of these stationary decoders are no different than a regular train decoder only it supplies DC voltage to throw

a switch. Because these decoder are connected to the track its commands are sent on the rails as well.

 

On Track Off Track Bandwidth

 

To better understand the bandwidth factor we should look at the Digitrax DS64. The DS64 is a stationary decoder that operates either on the track or off the track.

The DS64 has 3 means to power itself.

 

1. An input from the track

2. An auxiliary input.

3. DC input

 

When you apply power via the track the DS64 will only look for commands on the track. It will ignore the Loconet capabilities and monitor the track only. This is

where the track can be inundated with messaging from all DS64 connected to it. This is where the issue of bandwidth arises. Digitrax's answer was Loconet.

 

Loconet

 

Remember the track is a data transport median. Digitrax devised a secondary data transport median called Loconet. This secondary transport off loaded the

ancillary messaging off of the track and onto the Loconet bus. The DS64 is equipped with loconet ports so it can use the alternate communication path to 

receive and transmit switch conditions. Loconet has its own protocol owned by Digitrax.

 

LCC

 

The NMRA is adopting LCC as an open source adaptation of Loconet. LCC is offloading the messaging from the DCC track messaging. This will relegate

the track to support all train control messaging and have LCC to support the supporting messaging (switch,signaling,detection).

 

Here is the best read on LCC

 

As of right now it looks like RR-CirKits is selling LCC stuff but not much more.

 

Like Chadbad said there still more development that need to happen before one can make an argument to switch over from Loconet, Railcom to LCC.

Notice I said Loconet and Railcom. I did not mention DCC because it has nothing to do with the switching over. DCC controls the trains and we are talking

about controlling the layout ancillary devices. 

Inobu

 

 

Edited January 3, 2021 by inobu

[roadstar_na6]

Coold you technically use LCC with a DC layout then?

[gavino200]

Thanks inobu for your informative post. Both Kiran and you are doing a nice jobs of clarifying the issues around DCC and LCC. As someone with limited tech knowledge I really appreciate the effort you guys put into describing difficult concepts in everyday language. 

[gavino200]

7 hours ago, inobu said:

On Track Off Track Bandwidth

 

To better understand the bandwidth factor we should look at the Digitrax DS64. The DS64 is a stationary decoder that operates either on the track or off the track.

The DS64 has 3 means to power itself.

 

1. An input from the track

2. An auxiliary input.

3. DC input

 

When you apply power via the track the DS64 will only look for commands on the track. It will ignore the Loconet capabilities and monitor the track only. This is

where the track can be inundated with messaging from all DS64 connected to it. This is where the issue of bandwidth arises. Digitrax's answer was Loconet.

 

It slowly became clear to me that many of the comments and articles I read last night on my midnight reading spree, are comparing LCC to a pre-loconet situation. I understand that the NMRA doesn't want to get into mentioning any particular solutions, such as loconet, by name. Unfortunately this has created a sort of "elephant in the room" situation. My current plan is to use a Digikeijs system with loconet and railcom. I'm really only interested in comparing LCC to a loconet system. 

 

 

7 hours ago, inobu said:

 

Loconet

 

Remember the track is a data transport median. Digitrax devised a secondary data transport median called Loconet. This secondary transport off loaded the

ancillary messaging off of the track and onto the Loconet bus. The DS64 is equipped with loconet ports so it can use the alternate communication path to 

receive and transmit switch conditions. Loconet has its own protocol owned by Digitrax.

 

Thank you, and to clarify, likely redundantly like a five year old, Loconet is a two way communication system. The loconet devices do in fact send information from the periphery to the center. Specifically, with Loconet you don't have to set all the junctions a certain way every time, before you start? Am I right about that?

 

Another discussion point that I've encountered concerns the LCC protocol. Generally the LCC protocol is compared to DCC protocol in these discussions. But like you say, loconet has it's own protocol. For me any meaningful discussion of protocol should compare LCC protocol to loconet protocol. Furthermore, I was under the comfortable impression that if I used a control software package like JMRI or train controller, I would only really have to concern myself with learning the software interface, and not ever really need to understand the inner workings of it. Have I been naive about that?