For ESP32 there is OpenMRNLite which is what I'm using in the CS (slight modifications to it that haven't been rolled up or released in OpenMRNLite yet). For AVR or other single-threaded envs there is https://github.com/openlcb/OpenLCB_Single_Thread. LCC is definitely the "future" direction of things.. I can answer any questions you might have for it.
This is my hope as well. I drive my switch machines with NCE Switch8 boards which don't update JMRI turnout positions when you toggle them with the panels on the layout. LCC seems to talk both ways, so I assume when it matures this can all be resolved. I like to build little projects with Nanos for automation, so I would love a stable library and cheap interface circuit...
Yes, LCC is definitely bi-directional in nature. LCC itself is pretty stable/mature at this point with multiple libraries available as the implementation (OpenMRN, OpenMRNLite, OpenLCB_Single_Thread).
The standard and code may be mature and stable but the market is just starting. I get the feeling that the overhead is greater and the H/W costs more, so the market adoption has to overcome that and prove the value. I could be wrong but I don't expect to see an LCC interfaced Switch8 anytime soon out of NCE. Looking at the single thread link you posted, the supported platforms seemed to be higher end (no Nano level). I would think that this will limit the number of clients deployed on a layout. It only takes a few cheap components to get a Nano to read DCC instructions so a node is pretty cheap. I have only been looking at LCC for a few months and not that deeply, so I could be missing something (not the first time ).
wow, that's a lot of code to digest. gonna take a lot of coffee to aid in that digestion. my first thoughts are that it looks pretty heavy to load on an Arduino. perhaps why you use ESP32. i wonder if a Raspberry Pi could be used as an MQTT/LCC gateway? MQTT, for those not familiar with the protocol, needs a Broker (aka, server) to function. this can run on an Rpi, and then it is just a matter of bridging MQTT and LCC within the Rpi. with MQTT, the device would either publish, or subscribe to a "Topic" on the server, and either push (publish) a value, or pull (subscribe) a value. Mike (Atani), you know LCC far better than i, are the two protocols compatible enough to pass info to and from? or is the structure way too far apart? I am still digesting LCC, while at the same time as brainstorming (for those not in the know, i tend to process info externally, so please bear with the ramblings of a mad man ). ~Travis
The OpenLCB_Single_Thread implementation is targeted to the lower end Arduino devices that do not support multiple threads. The Nano is also one of the targets for it that is being used by the devs if I remember correctly. The components to interface with LCC are comparable (MCP2515 connected via SPI). Likely what would make it simpler is if there was an adapter board for the Nano similar to this. I don't have any Nanos but I do have a few ProMini boards kicking about but there is absolutely no "standard" layout for those with the inexpensive clones on the market. But I'd be happy to mock up a PCB if someone wants to give it a try. Most definitely, it can also act as an LCC "Hub" (central point for LCC nodes to communicate with, similar to an Internet Hub in that regard). They should be, but you would need a translation layer between them. JMRI might have an MQTT translation layer available already (there are refs to mqtt in the code). It has taken me quite some time to get to where I'm comfortable and understanding of most aspects of it. There are still areas I'm learning though.. Some additional resources: https://groups.io/g/layoutcommandcontrol and https://groups.io/g/openlcb
Sounds perfect, I'll dig in once I get your system working with the LCC hub. I want to do something similar to my DCC interface board, two versions shown here.
Those are some very nice looking boards I'd imagine something very similar for the LCC interface using possibly a buck converter to power the nano from the LCC CAN bus (~15VDC 500mA, convert to 3v3 or 5v @500mA or similar for the nano), an MC2515 connected via SPI to the nano, 2x RJ45 (LCC CAN) and as an optional set of components: jumper to set a 150ohm resistor across the CAN A/B pair as a terminator.
Thanks! And, yes, I was just looking at the schematics to the board you referenced. I hadn't realized the LCC CAN bus delivered power until then. Some interesting options in there. Should be easy to replace my Switch8 setup with these once I get it all figured out.
Keep in mind that the power supplied by the bus is limited to 500mA max per spec. The voltage is anywhere from 7-36VDC (I think!) But the PowerPoint offered by RR-CirKits is 15V@500mA on both outputs. Nodes pulling power from the bus must also declare how many mA they consume, part of why the ESP32 CS doesn't draw/provide power to the LCC bus today (maybe in the future).
kinda reminds me of NMEA 2000 ( https://en.wikipedia.org/wiki/NMEA_2000 ) for boats. it also uses CAN, provides power (more in the case of NMEA 2000: 8A), but NMEA 2000 has a specialized connector and cable, rather than the common RJ45. a very simple terminator can be built, rather than providing for it at every node. just a RJ45 connector with a 120Ohm resistor shorting the CAN pins. ~Travis
Yup and this is one thing that RR-CirKits offers as an RJ45 plug with a shrink wrapped PCB. It draws a tiny bit of power from the bus for an LED to tell you there is power on the bus but otherwise nothing.
Just to add I most impressed by the work you have done Atani on this. Makes my progress on my throttle look a bit pathetic. I am still working through the LCC docs, which are heavy going in places. Looking forwarding to having ago with the new PCB's though
Never sell yourself short! Progress is still progress even when it seems small compared to the progress of others. Thanks! It has been a process to get where I am so far on this project and it is only improving with time. So far the new PCBs are only minor tweaks to the current one which is good. I'm hoping to have a completely tested PCB this weekend with the LMD18200 and L298 with JMRI interacting with the CS directly via LCC and not DCC++ protocol...
a thought i had, and as i am unsure how your PCBs are designed it could be off-base, rather than re-doing the whole PCB for every revision, why not build it to be upgradeable? like a computer motherboard for example. have the basics for the ESP requirements, then breakout the pins to a multi-connect bus. like either a stackable design, or a card-edge/slot design, or a IDC/ribbon cable bus design? If i ever get my large CNC router to accurately mill out a complex PCB, i was thinking of changing my DCC++ setup to use a MEGA2560 Core module ("MEGA2560 Core" search on eBay), and build my own "motherboard" of sorts. ~Travis
It mostly is today but there are some clearance issues on the current PCB and a couple PD resistors that got missed on the first run. These are all fixable problems on this first run of PCBs but I want it to be as easy to use as possible for others. I don't mind having a jumper wire or two as needed on this first set. This sounds like a great idea. There are a few other possibilities with this as well, I think I've seen the rPi in a similar packaging (compute module and woo woo woo). It is a great approach and is similar to what I'm doing except I'm putting the necessary parts for DCC signal and LCC on the PCB with a plugin esp32 module (DevKit-C or TTGO-T1).
yes, similar, but your DCC and LCC components are fixed, and need a different PCB to change the hardware for them, if ever needed (i am an engineer by heart, so i may be over thinking this ). just a though though... ~Travis
Yeah, fixed but flexible in the code... with the PCB though I'm aiming for "standardizing" the defaults so the configuration requirements for the PCB will be relatively painless, ie: plug it into power and connect to the AP that it creates to configure WiFi etc. This functionality will be available for the non-PCB builds as well. I don't think I'd go so far as saying it is over thinking, it definitely is something to consider if there is need for different hardware revisions beyond the minor tweaks that are planned right now. For certain the v2 PCB (if/when it is created) will have some differences in hardware on the PCB and will not be as "DIY friendly" as the v1 boards are today (all SMD components is the plan for v2)
I have to redraw my suggestion : "replaces the 2n7000s and resistor with a 1/2 lm339" : the "RAILCOM-VREF" voltage is too low to make the gate commute correctly, so I had to create an additional voltage reference called "RAILCOM-VGATE" the Railcom Reference Voltage circuit must be extended as follow : and the "RailCom FET gate enable" circuit may work this way :
Hey folks, been a long Summer but I'm trying to get back into the trains again. So I left off with getting ready to set up another arduino for S88, but then I see everyone talking about loconet. OK I really like the idea of the star-topology so let's work on that for a couple days only to discover this project isn't really supporting it. Hmm Wait S88-N supports the star topology and is supported here, ok let's look into that... oh wait, what's the LCC everyone is talking about now? Well crap, ok let's look at that then. *WHEW* it's been exhausting! All right, so LCC / OpenLCB appears to be the way to go since I'm starting from scratch anyway. Great. Atani, I saw your link above for the single-thread code on github, seems promising because I want to use a nano board anyway, and that has the ISP header to connect directly to the SPI bus on the CAN chip. I ordered some MCP2515 boards off ebay to work with, just have to wait for the boat from China. One question about the library -- I assume there will be no problem using pin 2 of the nano as my CS line? Are there any complete code solutions being used currently with DCC++ESP32? For example, something that would drive an IR LED at 38khz, read the corresponding receiver, and send that info over LCC? That's my basic starting point for block detection so I thought I'd check if that sort of code already exists. And now my big question (at least for me)... How exactly is the LCC information presented on DCC++ESP32? Is it pushed out as text codes through the telnet port like DCC? If so, is there a lookup table you can point me to that shows the codes, similar to the one for the DCC++ commands? Or does LCC have its own separate connection somewhere else? I guess I should get the code updated on my station, looks like you've been busy this Summer!
