Layout Automation Using Layout Command Control, LCC, and ESP32

I look forward to seeing how this one progresses.  

A couple of thoughts here:  First, if you go with the ESP32, there is little reason to use CAN bus in the project as you already have a powerful WiFi system in place.  My suggestion would be to write the software in a way that updates a 'data' page on a web server connected to, or hosted on, the computer, then all nodes check that page every 100ms or so for updates.  Someone much more skilled in web design than I am could probably figure out how to send push notifications to individual clients, but I don't know how to do that so just polling every 100ms seems easier, and is plenty fast enough for turning on and off lights and switch machines.  

Another thing to consider is a combination of the ESP32 and Arduino depending on the application.  The ESP32 is a fantastic device, but it works fundamentally different than a proper micro controller like an Arduino, and it may be easier to use the Arduino for some tasks. There's also the ESP8266 which is much less expensive, but has less capabilities.  In both ESP models, these are stack processors, and the more you have them doing, the worse they are at it.  Timings can be affected when you go to fetch web data and the like, because they can only actually do one thing at a time, as opposed to a uP that can keep something happening in the background while processing a new command.  

If you're planning to run wires from one controller to all your switches, one Arduino Mega2560 ($10) will give you 15 PWM I/O's that can be used to control servos, and 54 GPIOs if you can get by with relays or dome other on/off device on the output( triacs FETs, etc).  Pre-made boards with 16 10 amp relays can be had for less than $15.  

on the other hand, if you want to have each switch machine able to be wireless aside from track power, you're better off with the ESP8266 here, as it will process simple tasks quite well and costs about 1/4 of what an ESP32 does.  (about $2 each)  The ESP8266 doesn't have hardware PWM, but it will support software implementation. It has one ADC, so with these functions you should be able to make it work to control a servo for a switch machine.

  Lets look at your list of needed devices and I'll offer suggestions:  1) 20 x LED controller and driver, 2) 20 x turnout control with a servo motor, LED control and frog power controller, 3) 24 x block detector, 5) 20 x accessory controller,  6) 6 x RFID controller.

The suggestions here are going for low cost over ease of assembly.  for example using two Arduino pro mini at $2 each instead of just 1 Mega2560 at $10.  I'm also not including things like wire or mounting materials.  I assume you can figure that part of it out.  In practice, I'd recommend using one Mega, or even a Leonardo with shift registers or I2C GPIO chips and combining several things onto one uP, but here's as individual systems:

The LED controllers are dependent on how many LEDs you are planning to run off of each channel.  If it's only a couple, you can use a simple transistor connected to the micro controller of your choice and it will be dirt cheap.  The pn2222a is a common part costing 2 or 3 cents each and will easily handle 300-400 mA of current without breaking a sweat.  That's enough for about 20 standard LEDs.  On the other hand, if you're looking to power strings of strip lights, or large blocks with hundreds of LEDs on each channel, the cheapest, easy method is probably to just use off the shelf, 16 channel relay boards for about $15 each.  All told for 20 channel at 10 amps each, you need 2 pro mini's linked over I2C, 1 16 channel relay board and a 4 channel relay board, thats a total cost of about $25.  $35 will get you 32 channels.  

For the turnout controllers, using servos, you'll need a PWM channel for each servo.  While it could be done in software on GPIO pins, the easiest way to do this is with the Mega2560 with 15 PWM channels each. Pretty much you need 2 Mega2560's and a transistor fro each output.  so about $22 will get you 30 channels.  As a side note, you can combine the LED controllers and Switch controllers and use just the 2 Mega2560's here for a total of about $45 for 20 LEDs and 30 switches. The hook up would be a PWM pin feeding a transistor, which in turn feeds the servo, and a pair of GPIO pins feeding transistors to power the direction LEDs.  That leaves 26 IO pins free on each Mega 2560 to be used for I2C between them and LED control. Powering the frog adds in the expense of a relay to the mix, so that's $15 for every 8 turnouts, and the relay can be triggered off the same GPIO pin that powers the LEDs for indicators.  

Block detection depends how you want to do it.  If you're going with an isolated rail method, simply using the train's wheels to bridge an isolated rail, all you need is an opto-coupler for each block, a GPIO pin on a uP, and an offset power supply.  all told for 24 channels you'r looking at about $15 in parts, less if we manage to combine the functionality with some of the other devices.  If you want to use optical sensors  you'll add about $5 per channel.  I can't think of the guy's name right now, but someone even did a proof of concept about a year or so back and wrote up a nice post on it, using a computer using a camera and image procession for block detection.  

The Accessory controller is identical to the LED controller.  

For RFID, I have little direct experience, however you can expect you'll need an RFID sensor for each node, and an I2C or SPI bus free on a uP to read them.  I don't see why it would cost more than $5 per channel.  

Putting it all together, you have a need for 80 Digital outputs (20 LED, 20 Accessory, 40 turnout indicator/frog power) 20 Analog outputs, and 24 inputs (block detectors), plus a number of I2C or SPI connected RFID readers.  I would do this with 2 Mega2560's linked together over I2C, which would give you most of the IO you need. You can make up the extra with an I2C I/O expander, shift registers, or a third Mega2560.  It all depends how much you want to deal with add on components. Going the expensive route of 3 Mega2560's you're looking at something around $120 in parts to do everything you want, with room to expand in the future.  

John,

Thanks for the reply.  I should have been clearer when I described the nodes.  The number in front of the x in the node description is the number of that type of IO for the node.  For example "20 x LED controller and driver" means each LCC LED node will control 20 LEDs.  My current layout estimate is 300-400 blocks, 600+ Signal LEDs, and 160 turnouts.  My first choice was also to use WiFi for the interconnect.  The hardest part of the electronics is going to be writing the software and getting it to work.  I chose LCC because it is an open standard and I will have significant help in getting the software to work.  I will have a significant number of nodes and I thought LCC was the only way to manage them.  LCC currently uses the CAN bus which is reliable, self assembling and all nodes can broadcast and receive.  LCC may be extended to WiFi in the future.  An LCC node needs to have the compute power to manage the CAN bus and do localized compute.  For example the compute needed to control LEDs in block signals can be done on the local LCC node. 

For ease of programming I wanted all the nodes to have the same base processor.  The ESP32 LCC Node board components will cost between $14-20 depending on the board function.  The better capabilities of the ESP32 over the ESP8862 made the extra $6 worth it.  The Arduino Mega2560 is an impressive IO board.  The difference in compute capability of ESP32 32  bit 240MHz processor with more memory than the Arduino MEGA2560 8 bit 16MHz processor led me to chose the ESP32 .

Thanks again for the comments.

Carl 

Alright, heres a couple more things,

First, when you say each module will control 20 LEDs I'm taking that to mean 20 channels that can be individually turned on and off.  How many individual LEDs are being controlled by each channel?  is it just 1 or 2 as indicators and track-side markers, or are some of these going to be large lighting districts and the like?  Keep in mind that the ESP 32 can only sink about 12mA per GPIO so you'll get an led at about half brightness if you connect directly to the uP.  Additionally, the esp32 can likely only sink/source a total current that is much less than all of it's IO at once, so you'll need an output buffer of some sort in any case.  If you're running less than 20 LEDs from each channel a 2 cent transistor will do the job just fine.  

Another thing to keep in mind is that CAN bus is a proprietary system owned and licensed by BOSCH.  If you want to put the name "CAN" on something, you have to pay the fee, just like 'BlueTooth'.  If it's used entirely internally, the chip maker has already paid the fees for actually making the chip with CAN bus protocols, however these legitimate chips are expensive compared to the knock-offs sourced from China for 75 cents.  Point in this is, if you're looking for an open source solution you may want to look at RS485 which is inexpensive an open protocol, and preforms well over long distances.  Or just use the WIFi from the start.  

Using the WiFi leads into the last point for the moment, if you're not using it, there is still no point of using the ESP module.  While the ESP32 is much faster and has more program space, it's sort of like saying a NASCAR car is much faster than a station wagon, when the race is against an old man walking with a cane... It's overkill for what's needed.  A $2 pro-mini will handle the task just fine if you're not making use of the WiFi anyway.  There are even much cheaper uP's out there that are up for the task of turning on and off LEDs and driving PWM signals.  For a good example, look up Dave at EEVBlog's series on the 3 cent micro-controller on YouTube.  ESP32 is wonderful, but it's overkill if not using the radio.  Also, keep in mind if you are already dealing with custom boards and SMT parts anyway, I2C port expanders and LED drivers can be had pretty cheap if you hunt them down.  

As for the difficulty being in the programing, that's mostly going to be in translating between your control software and the hardware.  that actual code to make LED's turn on and off and the like is really simple.  Mostly it depends what role the computer is taking on in your system, for example does it take in all data and send out all signals, or is it just riding piggy back onto of a system that runs it's self with the computer switched off?  

As far as a protocol, I've not looked into LCC as TMCC's standard is usually plenty. It's major limits being 'only' 128 turn-outs and 128 accessories can be controlled.  though there are hacks around this that a computer could take advantage of, such as using one of the accessory addresses to turn on and off banks of switches, so for example, you turn on accessory 1 to control switches 1-128, and turn off accessory 1 to control switches 129-256.  It would be annoying for control from the CAB remote, but would at least still allow full control of the layout from that remote... (well, only 99 switches/accessories per block). and the computer system wouldn't even care about having to do it.  

Guess thats all for now.  

Hi John,

A further clarification is that the 600+ LEDs mentioned above are block signal LEDs that need to be individually controlled.  Another 600+ LEDs will be used for lighting and don't need individual control.  LCC  was designed to independently control block signals and accessories.  LCC nodes need to have the compute capability to calculate the state of all their IO from information on the CAN bus.  LCC allows lighting complex prototypical block signals where switches are involve and more than one color in a signal can be on.  LCC allows prototypical crossing gates where they activate when the trains is 2-3 blocks away and then opens just after the train passes.  The distributed computing power of the LCC nodes allows computation of the state of 100s of IO every time the state of a block or switch changes.  This level of computation and control is beyond DSC, TMCC and most home computers.  The reason for the CAN bus is for all LCC nodes to broadcast and listen to all other LCC nodes.  The computation power of the ESP32 is needed to calculate the state of each IO with every change in block occupancy and switch state.  Since my retirement is 2-3 years away I hope that a WiFI alternative to the CAN bus can be developed that is acceptable to the LCC standards committee.  This is why I like the WiFi capability of the ESP32.  Thanks for you comment John.

Carl

carl552 posted:

This level of computation and control is beyond DSC, TMCC and most home computers. 

I'm somewhat offended by this comment.  A Commodore 64 is perfectly capable of running the I/O for thousands of devices, never mind any modern computer.  As a point of fact my father's layout was run by said Commodore 64 in the 80's with dozens of blocks, neon lights  and the whole assortment of WWII surplus relays and such.  My point on the previous post that TMCC is good enough was just that it is good enough to control the things that it can control.  you don't need another system in place to turn on and off accessories or to activate turnouts.  TMCC already does it just fine.  

Looking at the LCC spec, which has proven somewhat difficult as it is not clearly laid out like most protocols in electronics, it seems fairly straight forward, and designed to be much more capable than it actually needs to be in order to try and future proof it some what.  From what I can see you can send a payload of up to 256 bits of information to any of 4096 addresses on the system (12 bit addresses.). this is well within the ability of pretty much any modern microcontroller so it hardly matters which one you use.  

I will point out again that any open source project should avoid using a proprietary system like CAN, when open source alternatives are available, but understand wanting to stick with the system in the LCC standard.  Why a licensed technology was chosen for a open standard confuses me.  

In any case, using the ESP32, or whatever else, building a board that interlinks with others and does whatever with some input to make some output happen is pretty straight forward stuff in the software.  For the hardware, I recommend using Opto-couplers on all input and output lines to protect the uP.  Additionally any average opto will provide enough current to drive an LED or two for block indicators and the like.  In either case you will need a buffer transistor between the output lines of the uP and the Opto or LED it is driving, as the uP can not provide the current needed.  I mention this because it would make the most sense, to me anyway, to put all these support components on the same board with the uP.  

Pretty much you're making whats known in heavy industry as a Programable Logic Controller, or PLC.  Take data (X) in, if it matches pre programed things, do output (Y).  It's not complex and requires very little computing power.  Once you have base code written to interrupt the LCC standard on the CAN bus, that can be copied to all modules and there is not much more to it.  if X then Y to your heart's content.  

I'm interested in your project. I originally started my own LCC type system with Xbee units, but want to develop a low cost system for model railroads. I found the ESP32's and they're idea for this concept. Expressif developed the ESP_Now protocol the utilizes 250 Byte packages, which are larger the the current LCC canbus protocol.

Would enjoy talking/sharing ideas with you.

Carl,

What happened to this project?  Did you build your own LCC nodes?

I designed and built a LCC node for 18 inputs.  This node will primarily be used for block occupancy detection.  I designed and built a block detection board to go with the LCC input node for 6 blocks based on Prof Chaos' design.  The second LCC node is for 16 outputs that will control the Tortoise switches and all the accessories.  RR-CirKit LCC nodes are used for the block signal logic.  The RR-Cirkit LCC signal nodes have very sophisticated signal logic that would be very hard to duplicate and test.  The RR-Cirkit USB buffers and power sources are also being used.  All the nodes were designed using DIPTrace and PCB boards made by PCBway.  I had a test bench simulating a small layout with 2 siding working properly.  A wall cabinet fell of my garage wall onto the test bench.  When I complete the project of upgrading the garage cabinets I will post pictures of the the nodes and a video of the working nodes in the test bench.  I still think that LCC infrastructure the best and cheapest way to automate a layout.

I look forward to the demo video.  Hopefully nothing expensive was hurt in the accident.  Are you still meeting your cost estimates using the RR-Cirkit components? 

Going through old emails. I've been working with ESP32's and MQTT. There is now a JMRI interface with MQTT. No CAN bus wires. All wireless. I also have set up local yard control with the ESP32's Wi-Fi and a cell phone app.

And here I am, still using 8051's.

@A. Wells posted:

And here I am, still using 8051's.

Nothing at all wrong with technology that'll be coming up on 50 years old before you know it.

It still works.

Mike

@Mellow Hudson Mike posted:

Nothing at all wrong with technology that'll be coming up on 50 years old before you know it.

It still works.

Mike

Mike - FYI: I use SiLabs 8051's.  They are loaded with peripherals.  I also like being able to write low level code.  My 8051 library is task/callback orientated and is considered psuedo thread architecture.  As far as I know, I've never had an unserviced interrupt.

@A. Wells posted:

Mike - FYI: I use SiLabs 8051's.

As far as I know, I've never had an unserviced interrupt.

Impressive.  It proves the point nicely.

Mike

The OP is from 2018.  Interested in what happened between now and then.  Nearly 3 years.  Interested in the progress as the idea and magnitude sounds impressive.

John

The magnitude of his plans is truly impressive. I would like to know how it is going as well.

I have been working on developing hardware to do the same (for layouts) for exactly the same length of time. The problems are much more complex than they appear if you want to make it all work per the prototypes with CTC included. It is also way more expensive than the original post would imply. The components to make a working system involve a lot more than a processor or an Arduino.

As a side note, I personally shy away from 802.11 wireless and bluetooth to communicate with layout peripherals.  In my opinion it's overkill.

A. Wells:

I agree regarding WiFi and Bluetooth for interconnections. You have to use wires to get power to controllers and wires from controllers to signals, turnouts, and track circuits anyway. However, a wireless link to the locomotives can be done with WiFi, Bluetooth, or XBEE/Zigbee.

I think CANBUS is a good system for model railroads since it has acceptable speed, distance, and noise immunity. LCC uses CANBUS probably for these reasons. However, I find LCC to be poorly defined regarding how to use it from a developer's point of view. It does seem to allow easy interconnections but I cannot tell if it would meet my design goals. I have LCC planned as an option for the future depending on if I can ever figure out how to use it in my design. (Yes I have all the NMRA information and have watched all the videos). My system uses my own data formats that are small and fast.

I am working on the last couple of features (Time Locking and automatic ALL STOP after a train goes through a Control Point) before I make the product announcement for the stand-alone system. The development will continue into the second phase where the Layout Controllers and the locomotives will communicate. This will enable features like In-Cab Signaling on the Cab Controller and Positive Train Control.

I agree with your assessment of the current LCC specs. My layout has a DCC power bus, and a 5 volt power buss for led's, ESP32's, and servo motors. MQTT is seeing use in the auto industry, where the CANBUS has been employed. I think that covers concern about noise and interference.

The great thing about the ESP32 is the low cost. Most CAN hats for the ESP32 cost as much as the basic unit.