G'day mates, I have a situation that I want to fix with technology. In specific, our club layout has a big 8-track fiddle yard leading to a double-track run across the front of the layout. Being publicity junkies, we always have a train crossing the front of the layout, with a second train queued in the tunnel mouth ready to run, and other trains also waiting in the wings or speeding along the returning loop behind the curtain. It takes a bit of nimbleness to be clutching onto 4 mobile phones controlling 4 instances of WiThrottle locos without banging into anything. It makes the older blokes tired. It shouldn't be this hard. But I haven't seen much on DCC signalling that enforces ATS or anything like it. What I want: * Operators sitting back and drinking beer while 8 different locos go slowly back and forth across the layout * Kids and their parents amazed at how much interesting stuff is going on * Operators who aren't drunk yet engaged with the crowds, lending out controllers and handing out pamphlets What I need: * Double-isolated sections of track right before signals with possible STOP aspects * STOP aspects enforced by DCC++ broadcasting all-speed-0 into addr 0 in the isolated sections * When an aspect clears, DCC++ restores normal DCC signal to the isolated sections * When a train approaches the fiddle yard, allocate it to an empty road * When no train is at the mouth of the fiddle yard, pick one and restore normal DCC to its track * Optionally, flip between nice standard DCC provided by SPROG for mains, and ghetto DCC++ coverage for enforced stops * Optionally, use the ESP32 to run signalling about the sections it's enforcing Where I am: * Got the ESP32 wemos lolin with OLED * Got it to boot and run eventually (plenty of thoughts on how to make the docs smoother) * Not hooked up to the motor board yet. I got one of those 42A ones and I don't have the inverter IC yet * So I obvs haven't seen one single train move via my DCC++ setup yet * Not sure how to get DCC++ to spit out the "all trains stop" command onto the isolated sections Updates as they happen, suggestions welcomed! In my wild fantasies this would be a useful module for anything where the signals weren't just 'hints' and trains needed to actually STOP. I just thought of some sidings with unprotected ends that might benefit from this kind of protection.
I don't see DCC++ESP32 being the 100% solution to your wants, it will require additional logic which the DCC++ESP32 CS code does not support today (and very likely won't support). I'd suggest using JMRI on an inexpensive RPi with an LCC bus to provide the signals, isolation track (via a relay reacting to signal aspects), and routing the trains to the tracks in the fiddle yard. There are LCC nodes available to provide block detection, signal aspects, and more. JMRI supports this today as well. The DCC++ESP32 project supports LCC today (v1.2.0 is limited in what is supported but v1.3.0 will have more support). The less work you have the CS do the better really, it needs to manage X locomotives that are somewhere on the track and it needs to do so in a manner that is as fast as possible. By increasing the complexity of the logic in the CS you will encounter a point where the DCC signal will be impacted negatively.
Thanks! On review I see there were some things I didn't explain clearly. JMRI will be available, and providing DCC to locomotives on the mains will be done by our NCE station (or Pi-SPROG while testing). I'm looking at DCC++ESP32 as a way of generating all-stop commands for the isolated sections. I don't have any ideas for how to run signalling yet so I was also thinking to put signal driving onto the ESP32. It seems nice to minimise wiring by putting LEDs, detectors and relays on the same device and sticking it under the fiddle yard exit. It would be fine to have JMRI do signal logic, routing, etc. Is anyone producing a cheap CANbus board for LCC with ESP32? I looked into LCC and the main thing giving me pause is ESP32s are $12 which is great, CANbus breakouts are $40 with the wrong connectors, nobody has a board for the RJ45 connectors, you could cobble one together out of 2 RJ45 breakout boards and 12 bits of hookup wire? That's an extra $50 per device and an absolute rat's nest on a breadboard. Then I start hearing vague whisperings of LCC-over-WiFi and think maybe if I wait I can save all that plus skip the Cat5 under the layout.
That can be done somewhat, the eStop packets are only sent once currently and I need to update the code to send them continuously (planning to do that in v1.3.0). But there is still a problem with two CS sending the signals out unless you are planning on having a relay swap the rail power from the NCE system to DCC++ESP32. The DCC++ESP32 side doesn't know what the NCE system is sending to the rails today so it doesn't know the commands to send the locos etc... It depends on the ESP32 board and where you source them, I get mine for $5 direct from a manufacturer. On the CAN bus side, the best option is an MCP2551 IC, available as a breakout board or DIP-8, and it is about $2 (or less). I'm working on a PCB for DCC++ESP32 using a TTGO-T1 ESP32 with RJ45s+MCP2551 for LCC, I don't have a specific timeline yet but it will be a self-contained PCB which I'll be making available as a kit or as a ready-to-plugin variation. LCC over WiFi is in progress, I'm working on the drivers for that with a couple others in the LCC development team. We currently have a POC for it using the ESP32 and it does work but it has a few performance issues which limit it's usability. We have a replacement driver available that should work much better but it is not available in the general distributions yet, hopefully soon. Mike
Agreed, relays seem straightforward and they fail safe if someone gets tired of block control and pulls the ESP32's plug. That pricing is much more doable. Just before I saw your reply I stumbled on this: https://groups.io/g/layoutcommandcontrol/message/1066 . Made me realise that ESP32 LCC can be done cheaply with a few through-hole components, as you say. Doesn't seem like Carl has his board design entirely worked out, or produces them for other people yet. If I could wish for things it would be for a board that took one of the OLED-equipped ESP32s. Maybe not everyone wants to lose two GPIOs though.
Carl's board is not available generally. I also wouldn't recommend it at this point. We have a couple new designed already underway and I'll have a couple options: CS, Booster, Detector. I'm focusing on the CS first but the Booster board will be quickly produced as well. I'll post the files once they are ready for testing, for now I'm using solderless breadboards to test circuits for the PCB as I get things setup. So far I do have a basic design for the CS and now have components to test everything except current sense (need high wattage resistors still). But it will have the L298, RJ45s, MCP2551, TTGO-T1 esp32. And a few other components for driving bits. Sent from my ONEPLUS A5010 using Tapatalk
