<rant> Probably a stupid question, because the answer must be obvious with just a bit of googling. Alas, I haven't found it yet, hence this post. I came across this: https://github.com/openlcb/documents/find/master , and I figured out that if I type '/standards/pdf' into the search field, I get a bunch of pdf files, but it's not exactly what I would consider structured and readable (e.g., no links from the 'executivesummary.pdf' to anything else.) There is an index.html, but it is rendered as html source code in my browser, which actually makes sense, since this is github, and tells me these are not the droids I'm looking for.... Similarly, I came across this here: http://old.openlcb.org/trunk/documents/FirstLookDescription.html , but the 'old' in the name seems to be a dead giveaway that this is probably not current. https://openlcb.org/ advertises some book, https://openlcb.org/openlcb-and-lcc-documents/layout-command-control-lcc/ is again an unstructured list of files (technical notes and standards), and https://openlcb.org/about-openlcb/introduction-to-openlcb/ is a bit less detailed and technical than what I'm looking for; the links dead-end in some glossary. Searching JMRI for LCC leads to this: https://www.jmri.org/help/en/html/hardware/can/index.shtml , which looks promising, but might also contain dead ends. The NMRA website has documents similar to openlcb.org, but the last of those are from 2016: https://www.nmra.org/lcc It feels a bit like standing in a maze of twisty little passages, all different... </rant> Is there a description of LCC, maybe with an Arduino or RPI implementation example that interacts with JMRI (I assume LCC should integrate with JMRI?), somewhere?
A description can be found here: https://openlcb.org/about-openlcb/introduction-to-openlcb/ ESP32/STM32: https://github.com/openmrn/OpenMRNLite rPi/Tiva/Linux/Mac: https://github.com/bakerstu/openmrn Many other Arduino platforms: https://github.com/openlcb/OpenLCB_Single_Thread OpenMRNLite is a trimmed down version of OpenMRN that is tailored for the Arduino IDE and is preferred over OpenLCB_Single_Thread where possible. OpenMRNLite can be found via the Arduino IDE Library Manager as well. I'm also the maintainer for the ESP32/ESP32-S2 support in OpenMRN and use ESP32 Command Station as a testing grounds of sorts for new features in OpenMRN. There are a few example applications here: https://github.com/bakerstu/openmrn And a bunch more here: https://github.com/RobertPHeller/RPi-RRCircuits (There are a number of these that build on top of OpenMRN or OpenMRNLite) Yes, it will interface with JMRI through a couple methods: Physical CAN device (LCC-Buffer, SocketCAN, or similar) TCP/IP (GridConnect) You will need at least one OpenLCB node to interact with via JMRI. It's only stupid if it is not asked. Asking leads to learning and learning is always a good thing. It's actually mostly current but there was a shift from an old web config to a new one in which not all content has been migrated yet. The current specs can be found here and pending drafts here. The documents on the NMRA site are the last standards that NMRA adopted from OpenLCB. There should be a few updates in the coming months for some of the more recent drafts that are now in final reviews.
Thanks a lot for the links! Seeing an implementation makes it much easier, at least for me, to understand this stuff.
Years later, the situation hasn't really improved. I have found some enlightenment in a blog here? https://greatnorthwesternrailway.blogspot.com/search/label/LCC And on the RR-Cirkits page, but you have to jump around a lot. "Clinics", "Notebook", and some of the entries under "Manuals" are helpful, sort of. http://www.rr-cirkits.com/ Rotsa Ruck!
There is a pretty good forum dedicated to LCC on groups.io: https://groups.io/g/layoutcommandcontrol. Note that it also references the http://openlcb.org/ website, as well as providing information of its own. OpenLCB was the former name for LCC before it was adopted and standardized by NMRA. LCC involves a lot of things that could be thought of as independent (e.g. command station, throttle communications and track-side accessories), so there is a large amount of information, but as mentioned above, navigating it all to find what you want can be challenging.
This isn't quite accurate, OpenLCB is the organization that manages the specifications and is independent of NMRA. The OpenLCB group submits a collection of standards which are then adopted by the NMRA as LCC. The LCC group on groups.io is more focused on the user facing topics and development topics are discussed over on https://groups.io/g/openlcb. And there are a few other groups which have some discussions on LCC/OpenLCB but not as focused as the groups.io ones.
Thanks for the clarification. The relationship between OpenLCB and NMRA/LCC was confusing to me (and likely to others as well.)
No problem, there is certainly a bit of confusion possible with how it is arranged. However, the distinction between the two groups has blurred a bit more recently as a number of the OpenLCB members have joined other working groups within NMRA to help clean up, merge RCN specs, and generally modernize almost all DCC standards as of today. It's a large effort and some of their tasks have already shown up in the most recent standards (S-9.2.1 and S-9.2.1.1 as example, some of the new types are from RCN specs/developments). Also note that some of the features of OpenLCB which are often referenced as LCC standards (such as the traction protocol) have not officially been adopted by the NMRA as LCC. These are mostly held back due to refinement of the standards documents based on real-world implementations and feedback. It is likely these will be submitted for adoption at some point later this year. A couple highlights of areas that haven't been submitted for adoption: CAN Physical standard has been updated to assign reserved pins 4 and 5 as ALT_L and ALT_H, these are currently used by a few command stations as a power station interface as defined in S-9.1.2. In all usages I'm aware of this is implemented as a full scale voltage interface (12v 250-500mA current limit). Additionally these pins can be used for RailCom feedback from boosters to the command station if all components support such feature. Traction Protocol, as discussed above the standards are being refined and converted from a working note into standard / tech note format. Train Search Protocol. This is used by throttles (or possibly other nodes) to find a train on the OpenLCB / LCC network by searching in a few fields: legacy protocol address (DCC / Marlin), node name, node description, node id. RailCom / transponder feedback over OpenLCB, this is being discussed but has not reached a point of writing a working note yet. I'm sure there are others but I can't think of them off hand. Documents are staged here for reviews prior to submitting to NMRA.
I've been a proponent of LCC for quite some time. I'm not fond of LocoNet-ing everything, because 1) LocoNet is propriatary, and 2) it runs off of the DCC bus, which can cause chaos when things go wrong. But LCC is not it. It's a great protocol, some nifty hardware support, but the documentation or lack there-of just makes me want to rip my hair out. But if you thought that was bad, I'm trying to make a software throttle. Something that can connect to the CS-105, and the documentation is nearly impossible to find, half of it is still in preview form, and it makes the end user documentation for LCC products (I'm looking at you RR-Cirkits) look just fantastic.
You're definitely right about problems with their documentation. I should know more in a couple of days; I just ordered a system to see if I can use it for staging ladder control, including selective power shut off and fouling point reporting. Let's see what documentation comes with that.
Everything to do with the traction control protocol is still in draft form and can be found in the following links: https://github.com/openlcb/documents/blob/master/drafts/TractionS.pdf https://github.com/openlcb/documents/blob/master/drafts/TractionTN.pdf https://github.com/openlcb/documents/blob/master/drafts/TractionWN.pdf You will also want: https://github.com/openlcb/documents/blob/master/drafts/TrainSearchS.pdf The reason these are all in "drafts" right now is that they have not been submitted to NMRA for adoption. The TCS UWT throttles are using OpenMRN as their implementation which provides the full LCC stack, including traction control. The only piece that is "missing" is the train search implementation. There is an implementation of this available here which I believe is part of what the TCS UWT uses internally. I'm one of the maintainers for OpenMRN (primarily for ESP32 platform) and developing commercial products using OpenMRN with an ESP32-S3 MCU (TCS is following suit with one of their products). If you are developing for Mac / iOS using Swift you can take a look at this library which has been used to develop an LCC throttle and is available on the app store (at least was last I checked). If you run into any questions feel free to reach out to me and I'll provide info that I can to help you be successful in your projects. The core protocols are 100% documented and are linked from openlcb.org and on the NMRA website (latest adopted standards as LCC). It's sometimes not the easiest to follow documentation though. What did you order for testing? You likely will need some external hardware (such as relays) to disconnect the power to the rails or throwing points.
The RR-Cirkits concept is centered around a network card that manages switch handling and I/O through a variety of specialized I/O cards. I will be getting stall motor drivers and SPDT relay cards; the network card can handle LEDs and pushbuttons itself (I hope - see earlier comments about documentation). They also have DPDT relay cards, current sensing detection cards, and signal driver cards, and probably others I can't remember. All of them plug into the network card, called a Tower LCC. My big concerns are learning about JMRI - LCC is apparently not well documented for it, at least as far as I've been able to find, and digging out my resistor collection from a box in the garage. Thirty years ago they were organized (in a PAPER egg crate); then I moved and threw it all in a box. I have to learn colors all over again. I should probably make a resistor substitution box, too. I so wish Radio Shack had stuck around.
Yes, the IO bits can handle LEDs and buttons, just keep in mind they operate on 5v TTL so plan accordingly for the resistors needed on the LEDs. Don't forget Signal LCC which works great for signals (LEDs). LCC in JMRI in itself is quite simple, it's when you start interacting / configuring LCC nodes that things can get quite complex. RR-CirKit's nodes in particular (Signal-LCC and Tower-LCC) have considerable configuration settings which can allow them to do almost anything, if you can figure out the right options to pick! I would suggest joining/reviewing https://groups.io/g/layoutcommandcontrol/topics which has been used by a number of users for configuring their nodes accordingly, Dick Bronson is also quite active on there helping users. I have the following devices on my test setup: Signal LCC Tower LCC 2x BOD-4 (connected to Esp32OlcbIO and not Signal / Tower) 2x IO test boards 2x Esp32OlcbIO + Servo/PWM "hat" on one for turnout control and block detection Gateway (commercial product to be announced this summer) Throttle (commercial product to be announced this summer) 2x Command / Base Stations (one that is on the market now and one to be announced this fall) I can't share too many details on the last three other than they are not RR-CirKits or TCS products, the existing base station being tested with is on the market now as are the compatible throttles (if you can find them). But these will be publicly announced in the coming months and will be shown at upcoming train shows (possibly TrainFest 2023, definitely Amherst 2024). Same here, I also wish Fry's Electronics was around still as they had a lot of interesting stuff back in the late 90s and early 2000s.
The main concern/limitation for using the Tower LCC board to drive external logic-level loads is that, if an external power supply is used for the external device(s), it should be an isolated supply, grounded to one and only one Tower LCC board. If you have more than one TLCC board, then you need a separate, isolated power supply for whatever each TLCC is controlling. This prevents any stray ground currents from travelling on the LCC bus ground and creating problems there. A two-prong-plugged wall wart or corded brick supply is isolated. Three-prong-plugged wall warts and corded bricks may or may not be isolated. Also take care that whatever the external hardware is driving or sensing should be isolated from any common ground or related hardware controlled by other Tower LCC boards.
Isolator-8 should work for this if you need it. Do you have a reference for this? I haven't heard this specific issue with Tower-LCC, but it does make sense.
In the thread "LCC solution for controlling Unitrack switches" I posted on the layoutcommandcontrol group on groups.io, Dick Bronson responded with concerns about isolation and the high current/voltage involved with the motor driver boards. TB user TrainzLuvr had posted a youtube video controlling Unitrack switches (turnouts) from a Tower LCC board using an Adafruit DRV8871 DC Motor Driver Breakout Board. AdaFruit developed the breakout board for the IC, for use with Arduino and similar breadboard systems. The breakout boards are available from Adafruit and Mouser. The DRV8871 motor driver IC used on the Adafruit board is made by Texas Instruments. However, after Dick's comment, I analyzed a system of multiple motor driver boards controlled by multiple Tower LCC modules, and found that if they shared the same motor driver power supply, then transient return currents could occur on the LCC bus ground connections between the modules, perhaps causing erratic operation. Therefore I recommend that motor driver boards controlled by separate Tower LCCs (or other controlling LCC modules) be powered by separate, isolated power supplies to eliminate any motor driver return currents in the LCC bus ground. My setup will have the motor driver boards very near their controlling Tower LCC board, with longer wires to the solenoids on the Unitrack switches. Compared to Isolator 8's, separate, isolated 12V wall warts are cheaper and easier to integrate than control signal isolation between the Tower LCC and the motor driver boards. The isolation prevents any stray currents from leaving the Tower LCC, so as long as the motor driver boards are driving isolated loads (switch solenoids). Just don't share a single, isolated 12V power supply across motor driver boards controlled by different Tower LCC's.
Hi Atani very interested in adding servos to the ESP32IOBoard example but have not figured out how to change it ( including using the servo CDI). For my first tests i am just trying to get a directly attached servo on the ESP32 working but am thinking about writing a PCA9685 driver for 16 servos. I see that the lib has a openlcb::ServoConsumer module but have not figured out how to use it. Is your code published in git that i can take a look on how you setup the servo? any direction here is appreciated. BTW I am using openMRNlite, https://github.com/openmrn/OpenMRNLite/tree/master/examples/ESP32S2IOBoard for the config.hxx i have added #include "openlcb/ServoConsumerConfig.hxx" constexpr uint8_t NUM_SERVO = 2; using AllServos = RepeatedGroup<ServoConsumerConfig, NUM_EVENTS>; ~~~~ CDI_GROUP_ENTRY(producers, AllProducers, Name("Inputs"), RepName("Input")); CDI_GROUP_ENTRY(servos, AllServos, Name("Servos"), RepName("Servos")); ~~~ in the ino was trying but not sure how to setup the PWM object using macros: openlcb::ServoConsumer servo1( openmrn.stack()->node(), cfg.seg().servos().entry<0>(), <how to i setup the PWM obj?>); openlcb::ServoConsumer servo2( openmrn.stack()->node(), cfg.seg().servos().entry<1>(), ???);
https://github.com/atanisoft/Esp32OlcbIO has the updated options for including servo control via PCA9685. Note that I'm not actively maintaining that at this time due to other commitments but will provide assistance as needed. I'll also be producing a new all-in-one board soon for controlling turnouts (including threeway!) via servos. See the link above, it's a bit rough in a few areas but it should work as a reference. Be sure to use the latest published version if you are using the arduino-esp32 2.x versions. If you run into issues feel free to reach out and I'll assist where I can. Most of the active esp32 developers are using OpenMRN in an IDF context rather than arduino context, an official version of this will be published soonish (a few bug fixes still to be made).
