LCC Setup - Railcom

[reinhardtjh]

I don't think UWT-50 is meant to be used with two hands, especially because the body is slim and fits inside the palm well. You are supposed to use your thumb to either move the potentiometer or the scroll wheel, while holding the throttle with your fingers.

UWT-100 is a great all-around throttle modern, but UWT-50 really hits the spot both price and feature wise. If you haven't had a chance to try UWT-100 I really suggest you do, because the ergonomics are excellent, imho much better than the new Digitrax "curvy" edition.

Also, both UWT-100 and UWT-50 support LCC (Layout Command & Control, newly NMRA adopted protocol) - the next generation upgrade for controlling accessories, to go along with DCC.

LCC is a huge move forward, and long awaited one as well (been a few decades since DCC came out).

These new throttles will work with the upcoming TCS Command Station as well, which will also support LCC. What's cool about all this is that both throttles and the Command Station are software upgredable, so when new functionality get added into LCC (after NMRA adopts more features from the OpenLCB protocol) you just need to flash the new firmware and voila.

To give you an example of what LCC can do, here's my West Staging electronics panel:



Bottom left is a custom LCC Command Station I built based on an Open Source project on Github. To the right of that are RR-Cirkits Tower/Signal-LCC Nodes and SCSD-8 controllers for my Atlas remote turnouts (solenoids).
Above those are 3 custom Railcom IO LCC boards which control Track Power On/Off, perform Block Occupancy Detection with Railcom, and provide Current Protection, on each channel (there are 6 channels per board).

@trainzluvr

I've been following conversations on the Open_LCB and the LayoutCommandControl lists on Groups IO. I'm interested but uncommitted as of yet.   I'm curious about the Railcom boards you show.  You say they are custom. Did you design them yourself?  Or is there a GitHub or something somewhere to look at?

[trainzluvr]

Hi,

The Railcom IO node was designed by Balazs Racz, and when I first saw it in his LCC clinic I thought: "This is exactly what I need for my layout!" The board basically offers great value for the time invested to put it together (individual track power control, block occupancy detection with Railcom, and short circuit protection, all in one).

I contacted Balazs and he kindly shared the PCB design with me (it is not public, although the code is). Unfortunately, I cannot share the design myself, but you could probably contact Balazs directly and enquire about it.

This path does require both hardware and software skills. I had the PCB made overseas since it was economical, while I ordered the parts from local suppliers. Then there's the soldering of SMD components, compiling the firmware and flashing the micro-controller board, then troubleshooting any potential issues (either hardware or software). Obviously, there's help available but this does carry a higher entry level than most Arduino style projects, for example.

Also, if you are looking to design a piece of hardware on your own, something similar to this node or another kind, the OpenLCB group has a pretty good gathering of brains across multiple disciplines, that could be tapped for help.

Finally, if this is not your cup of tea, no worries because there will be at least one Railcom BOD board coming out from a known vendor, probably later this year.

Presently there are choices in every direction and, in my humble opinion, no better time to jump on the LCC bandwagon, with the upcoming TCS Command Station and another LCC Throttle, as well as the Open Source ESP32 Command Station, and many new commercial LCC nodes that are being worked on behind the scenes.

[reinhardtjh]

Thanks. I've seen the name in the Groups IO list.  I also have looked at his GitHub projects.  I'll probably keep lurking and see what develops in the coming months.  I'm a long way away from needing anything specific but I'm interested in the idea of being able to operate at least main line turnouts from across the room if I'm operating alone.

Electronics design and building and software programming are no strangers to me so I'm not worried about that.

Thank you for the information, it's been helpful.

[peteski]

Thanks. I've seen the name in the Groups IO list.  I also have looked at his GitHub projects.  I'll probably keep lurking and see what develops in the coming months.  I'm a long way away from needing anything specific but I'm interested in the idea of being able to operate at least main line turnouts from across the room if I'm operating alone.

If your goal is just remote operated turnouts then why not use DCC accessory decoders?  That is old-school technology, and it works quite well.  I have couple of friends who use that technology to operate turnouts and signals on their layouts.

[reinhardtjh]

If your goal is just remote operated turnouts then why not use DCC accessory decoders?  That is old-school technology, and it works quite well.  I have couple of friends who use that technology to operate turnouts and signals on their layouts.

It's an option.  There are basically two camps.  The DCC (and Loconet in my case) side where you would use a computer running JMRI (or one of the commercial programs) as a central controller and the LCC side where each node can run pretty much autonomously and for 90% (or more - still investigating) you don't need a central computer, the LCC nodes talk between each other and handle everything.

[trainzluvr]

DCC is an option but in my humble opinion, not a future-proof solution at this point now that LCC is a NMRA adopted standard.

The other issue is that buying into any DCC solution is buying into a proprietary system, forever. It does not matter whether it's NCE, Digitrax, ESU, Roco, etc. they are all "closed". And you can't mix and match easily.

With OpenLCB, the protocol is open and any manufacturer could develop a product around it. Backed by NMRA guarantee to model railroaders that LCC would be compatible across the board (a standard) it means you do not have to worry about connecting variety of nodes from different manufacturers.

Also, one of the biggest LCC gains is that there's no need for a computer to operate the railroad. Granted, it is required to initially configure nodes, but after that operation is stand-alone. You could turn a portion of your layout on, and just run solo switching in one of your industries yet still reap benefits of everything talking to each other (signals, turnouts, block detection, etc) in that area.

LCC also supplements DCC, and there are many DCC layouts already that run LCC nodes and are slowly replacing their DCC accessories. At the same time it off-loads traffic from the DCC signal, which exclusively becomes motive power only.

LCC still handles DCC accessories addresses, and commands from the DCC bus are translated into EventIDs (such is the case with the ESP32 Command Station for example and most likely with the upcoming TCS one).

On large layouts where there are many trains, operators and accessories, DCC does not stand a chance at all in providing a reliable operation because there's only so many bits you can squeeze into the DCC signal until it chokes.

There are other reasons of course, such as almost limitless number of nodes on the network, very complex logic that could be built or routes, that does not require running a computer to manage it all. In a sense LCC decentralizes your layout, while at the same time any node has access to the entire LCC network and messaging moving about it.

[C855B]

It appears that you're here to sell us on LCC. An 'A' for your enthusiasm, not so much for LCC.

I retired from a lengthy career as a computer systems engineer specializing in distributed system integration. Based on that experience, spending some time in the LCC online groups, and having the NMRAnet/LCC specs in front of me - I'm not a fan. Dick, Balacz and the others are smart guys, but nothing I've seen to date has convinced me of anything other than LCC is a camel, with a threshold risk of collapsing under its own weight.

You might avail yourself of these (much earlier) threads on TRW discussing LCC:

https://www.therailwire.net/forum/index.php?topic=37723.0
https://www.therailwire.net/forum/index.php?topic=47834.0

With maybe a couple of new suppliers on the hardware side since then, I don't see much benefit over DCC.

[reinhardtjh]

DCC is an option but in my humble opinion, not a future-proof solution at this point now that LCC is a NMRA adopted standard.

And so is DCC an NMRA adopted standard.  True, LocoNet and the others, not so much.

The other issue is that buying into any DCC solution is buying into a proprietary system, forever. It does not matter whether it's NCE, Digitrax, ESU, Roco, etc. they are all "closed". And you can't mix and match easily.

Not necessarily forever, nor exclusively.  There are a number of NCE users who have implemented a stand-alone Digitrax LocoNet to control accessories and do signalling.  And nothing is stopping any other DCC make's uses from doing the same.  Though in the opposite direction, again, not so much as there is little incentive.  LocoNet works well as a slow Ethernet type network and while there aren't so many commercial manufacturers other than Digitrax and RR-Cirkits, there is a fairly healthy DIY community (which is also true of LCC).

With OpenLCB, the protocol is open and any manufacturer could develop a product around it. Backed by NMRA guarantee to model railroaders that LCC would be compatible across the board (a standard) it means you do not have to worry about connecting variety of nodes from different manufacturers.

I think you meant connecting nodes of a variety of different protocols, but I understand your intended meaning.

Also, one of the biggest LCC gains is that there's no need for a computer to operate the railroad. Granted, it is required to initially configure nodes, but after that operation is stand-alone. You could turn a portion of your layout on, and just run solo switching in one of your industries yet still reap benefits of everything talking to each other (signals, turnouts, block detection, etc) in that area.

But all it takes is a Raspberry Pi running JMRI to control a layout. And if that's not enough then  there are other larger, but still cheap-ish computers available.

LCC also supplements DCC, and there are many DCC layouts already that run LCC nodes and are slowly replacing their DCC accessories. At the same time it off-loads traffic from the DCC signal, which exclusively becomes motive power only.

Which can also be done by running a separate DCC bus for accessories/signaling/turnout control/etc with no more extra wiring then a separate LCC bus would take.

LCC still handles DCC accessories addresses, and commands from the DCC bus are translated into EventIDs (such is the case with the ESP32 Command Station for example and most likely with the upcoming TCS one).

On large layouts where there are many trains, operators and accessories, DCC does not stand a chance at all in providing a reliable operation because there's only so many bits you can squeeze into the DCC signal until it chokes.

I think there are operators of larger layouts that would take exception to your statement.  There are ways around the bandwidth of a DCC bus.

There are other reasons of course, such as almost limitless number of nodes on the network, very complex logic that could be built or routes, that does not require running a computer to manage it all. In a sense LCC decentralizes your layout, while at the same time any node has access to the entire LCC network and messaging moving about it.

There are pros and cons to that.  On one hand, centralization means when something breaks, you've got one spot to go to fix it.  If the logic is distributed across many nodes then you may have a number of places where you will have to fix.  It can go the other way was well.  Just depends on your preferences and what you feel is important.

It appears that you're here to sell us on LCC. An 'A' for your enthusiasm, not so much for LCC.

I retired from a lengthy career as a computer systems engineer specializing in distributed system integration. Based on that experience, spending some time in the LCC online groups, and having the NMRAnet/LCC specs in front of me - I'm not a fan. Dick, Balacz and the others are smart guys, but nothing I've seen to date has convinced me of anything other than LCC is a camel, with a threshold risk of collapsing under its own weight.

You might avail yourself of these (much earlier) threads on TRW discussing LCC:

https://www.therailwire.net/forum/index.php?topic=37723.0
https://www.therailwire.net/forum/index.php?topic=47834.0

With maybe a couple of new suppliers on the hardware side since then, I don't see much benefit over DCC.

I didn't mean to stir up a religious war over DCC vs LCC.  I was just curious about TrainzLuvr's Railcom boards.  There are points on either side.  So far, I've seen nothing either way that is an overwhelming point to either side.  A lot depends on what you like/want and are capable of.

[C855B]

Tha's OK, John. I mostly wanted to point out to the noob    that there were opposing viewpoints among the cognoscenti.

[trainzluvr]

In all honesty, I am not here to sell you (on) anything. And by the sound of some of the comments, you've already made up your mind about LCC. That's fine, we all opt to use what works best for our current situation.

In my case I actually started with DCC alone, and was going to use Roco Z21 as my Command Station. I thought it was the new wave, that would cover all use cases for me. Then I realized I would need to go back in time and use Loconet to accomplish all of my other modelling goals.

A requirement for me was something future-proof, a forward looking technology. I did not want to invest into a proprietary system like Loconet or NCE, simply because I do not believe in closed source, or secret knowledge on a need to know basis (e.g. NDA for Loconet documentation). Besides, those technologies and their way of thinking belong to the past century and should remain there, imho.

It also appears you might have somewhat misunderstood the purpose of LCC. From what is being said, LCC is not DCC, not for a long while, or if ever. LCC is here to supplement DCC because after 30 years it had become apparent that DCC is inadequate, insufficient, and needed help. Yes, DCC still might work for you, right now, but it does not work for everyone.

If I recall correctly reading about it, DCC had the same resistance at the beginning (1990s) from the DC modelers. That changed with most people after seeing the capabilities of DCC, although we have some modelers who still run DC, for variety of reasons.

I think it's understandable that LCC is receiving the same opposition right now - humans do not like change once they are used to something. Eventually everyone comes around because one cannot ignore progress - it goes forward whether one likes it or not.

[C855B]

...

If I recall correctly reading about it, DCC had the same resistance at the beginning (1990s) from the DC modelers. That changed with most people after seeing the capabilities of DCC, although we have some modelers who still run DC, for variety of reasons.

I think it's understandable that LCC is receiving the same opposition right now - humans do not like change once they are used to something. Eventually everyone comes around because you cannot ignore progress - it goes forward whether you like it or not.

I get the feeling you're talking down to us. Be careful with that.

You thump "future growth" and "progress", as a pro systems engineer I see LCC as a dead-end. Firmware-driven custom microcontrollers in purpose-built applications is an obsolete concept, no better than DCC, just a little more recent. And then there's CAN Bus, in my view a big mistake. If you want to talk "future", look to Arduino and Pi developers especially in robotics, and node comm via hard Ethernet or even 5GHz WiFi.

Look for more development using low-cost consumer-market processors for MRR control functions. Whether it uses LCC, DCC or whatever on the comm layer is irrelevant.

[trainzluvr]

I get the feeling you're talking down to us. Be careful with that.

Not at all, and I'm sorry you've read it that way. It was a statement of fact, thus: "whether you like it or not."

I will edit it to say: "...whether one likes it or not."

I don't like some (new) things, but despite my grumpines about them, I cannot do much once the global force pushes them forward. I either accept that or remain grumpy. The latter is really not good for health, long term.

[trainzluvr]

You thump "future growth" and "progress", as a pro systems engineer I see LCC as a dead-end. Firmware-driven custom microcontrollers in purpose-built applications is an obsolete concept, no better than DCC, just a little more recent. And then there's CAN Bus, in my view a big mistake. If you want to talk "future", look to Arduino and Pi developers especially in robotics, and node comm via hard Ethernet or even 5GHz WiFi.

Look for more development using low-cost consumer-market processors for MRR control functions. Whether it uses LCC, DCC or whatever on the comm layer is irrelevant.

Everyone is playing with Arduino and RasPi, but they are just gadgets. Once you pass the point of blinking a LED or reading some temperature sensor, you realize that there's no further potential in that platform. Then you need to move on in order to actually make something more useful thus resorting to more purposeful MCUs.

I woudn't call Tiva Launchpad a custom microcontroller though, it's a gadget platform just like Arduino and RasPi. Yet, it runs the Railcom IO nodes on my LCC network right now, despite it being < 100MHz MCU from the last decade, which is coincidentally still being used for many electronics courses in (under)grad schools. For that matter, it could've been a STM32 instead, different manufacturer, same principles.

And the circuit design of that Railcom IO node is pretty novel (things are done in software thus everything could be adjusted without having to pop components in/out).

CAN-BUS is a pretty proven technology, else why would they run it in cars and airplanes. It delivers reliable and fast communication, all the time, and under high traffic loads.

Obviously people have developed other solutions, using as you say low-cost consumer-market processors (which TIVA and STM32 also are). But they had time and inclination to devote resources into a custom solution that only they would/could use and maintain. Not as robust, maybe fun to build, but that's all.

The idea behind LCC is that as an adopted standard everyone will start working with it (eventually). If NMRA thought it was worth while, why doubt it. Did they make a mistake back when with DCC?

[greenwizard88]

A Raspberry Pi 3 running JMRI is not a fast experience. It's slow, unrefined, and (depending on the version of JMRI) quite buggy.

LCC allows my signals and control panels to keep working while I reboot my Pi. If I can get a Railcom detection board that can be programmed to detect when 2 trains on a loop are getting close, and adjust one appropriately, that would be far far more useful than everything that JMRI can do.

trainzluvr, is this yet to be released railcom board a TCS? (yeah yeah keep your secrets) My biggest concern these days with LCC is the lack of industry support.

[C855B]

A Raspberry Pi 3 running JMRI is not a fast experience. ...

No, it's not. Pi 4 does fine, a 400 even better. You're right, Raspberry Pi OS can be clunky but I've had few - read "no" - problems with it on a 4B. Anyway, I'm in the process of porting my JMRI XML to a 400 running Ubuntu. Certainly a smoother experience, we'll see if the better but bulkier OS can handle the workload.