I'm not certain on the nano but I can't think of any reason it shouldn't work. There is no such project Note the rename and this project is *ONLY* for CS. The CS itself uses OpenMRN for interfacing with LCC and I'm one of the maintainers for the project, specifically for the ESP32 support. I've added the necessary support to the lib based on what I'm finding needed for the CS and some features which will simplify the library for consumers (like simplifying wifi configuration). There are a few helpers in the lib for interacting with GPIO pins (monitor for state change and produce event, listen for events and change state of GPIO, etc). This wouldn't be LCC specific, you would want to develop the code for interacting with the IR and wait on the LCC side until you have that code reliably producing "occupied" and "unoccupied" events. At that point you can create an event producer to emit the corresponding event for the block. There should be an example for the single threaded lib for the events, if not we can get one added to arbitrarily emit events. For the OpenMRN based builds you would setup a ConfiguredProducer for the event pairs and trigger the required event. The CS listens for only a few CS related events (e-stop, power-on, power-off, traction protocol events, etc). Occupancy events would fall into the category of "CS doesn't listen to" as it doesn't do anything meaningful with them, and it shouldn't! The signal masts on the other hand would want to know about occupancy so they can update aspects as well as produce events for other masts based on their aspects. Not exactly but close. The LCC interface has two possible endpoints: 1) Physical CAN connection, 2) WiFi connection to hub. By default only the WiFi interface is enabled and it is configured to search for an LCC hub to connect (JMRI has one but I'd recommend a standalone hub). The DCC++ command set is *VERY* limited in scope and can not be mapped in a 1:1 manner to LCC events outside of a small set of well-known event IDs that the CS explicitly listens for (see Event IDs here). More than you might know v1.3.0 should be considered semi-stable but there are a few known issues thus it has not been released, it may not ever be released as well. The development branch is mostly stable but there are still a few major changes coming still, see the todo list here. The biggest item on the list still is the Traction Protocol support in LCC, the code is still being worked on to implement the pieces needed for LCC based throttles (the TCS throttle coming out soon is one).
Wow ok I'm REALLY out of the loop here. So is the new code base fully compatible with the DCC++ESP32 code I already have loaded up? I'm assuming this is only a rename and not a whole new code base? Regarding LCC, did I understand this part right -- that the command station only recognizes LCC data on the wifi interface and does NOT connect to the CAN bus? If so, are there any plans to add this support (since it appears the ESP32 has a native CAN interface)? About the DCC++ commands, I don't think I made my question clear. If I telnet to my CS I can see a text output of the DCC information. I understand that LCC is a completely different system, I'm just trying to understand how I would see the data updates for LCC. I was originally asking if the CS also mirrors that data out on the same telnet port, but I get the feeling it doesn't. And this business about a hub... does that mean I would actually have to buy an LCC hub to even get started working with this? I guess I assumed that the CS handled everything similar to DCC or S88, and that I only needed to set up an arduino reading the sensors in order to have a fully operational system? It looks like my last code download for DCCppESP32 was in December, not even sure what the version number was at that time.
Yes it is 100% compatible, it is more of a rebranding to drop the DCC++ moniker as this isn't a DCC++ derivative (never was really, just offered the same text protocol interface). The CS will use WiFi by default but you can enable the CAN interface as well. The CS PCB has on-board CAN interface and defaults to enabling it. The two systems are independent and the DCC++ protocol interface is more of a bridge to the internals and is not guaranteed to receive all outputs (especially going forward from the development branch, there are more changes coming for this). The LCC hub is more of a software based repeater for the LCC bus over TCP/IP. It advertises itself via mDNS as a hub and acts as a bridge from WiFI <-> CAN or WiFi <-> WiFi. JMRI provides one but there are a few known issues with it, the OpenMRN stack provides one that will compile cleanly on Linux like envs (rPi works nicely for this and can host JMRI!). So no you don't need to buy anything to have this work. The CS itself can act as a hub but it is disabled by default due to limitations on the esp32 for incoming connections (max number of active sockets is limited) The CS can manage S88 and other sensors but the functionality has serious functional limitations. It is better to offload these sort of tasks from the CS so it can focus on generating the DCC signal for the track (it's prime responsibility). You *CAN* have an LCC node act as the bridge point from S88 -> LCC events, there are a lot of discussions for similar bridge like devices (LocoNet is one of the other big ones). To get going though, you can use S88 if you like but know that it won't generate LCC events for the S88 inputs changing state. Generating events for the S88 sensors can be done though, I just haven't had a chance to look over the specifics on it just yet. My primary focus has been on the PCB and getting things stable for it (with the PCB all outputs and sensors are disabled automatically since the PCB uses every available esp32 GPIO pin). I'll be working on the outputs and sensors before the next release so I'll try and get the details modeled up for generating events off the S88 bus (though it likely will be limited to only a couple buses by default in the LCC config side) master would have been 1.2.x and development branch likely some version of 1.3.0. The big shift over to LCC was in April for a few things on master (v1.3.0) and everything else on development branch. v1.3.0 will be skipped at this point in favor of v1.4.0 (likely rename to v2) as there are major architectural changes in the code and functionality.
So is the new code base still going to support the original ESP32 with the variety of hardware options or are you only going to be supporting the board you're designing with the hardware that it uses? I'm starting to think I need to just stick with a simple S88 network. I just need to read some IR sensors and LCC is sounding awfully over-complicated for the task. Was I correct that S88-N is useable by the CS?
The code will support both. I'm in the process of standardizing on the PCB and the ESP32 module for easier adoption purposes as the PCB includes everything you would need for the CS (two h-bridges, LCC CAN, power supply, etc). LCC is no more complicated than S88 would be, you have a sensor which emits two states (on, off) and these are bound to events on the LCC bus. In the case of S88 this is only simplified in that the sensor device only emits the state when the clock pin is triggered. In the case of LCC though it would emit the event immediately upon state change. So for the sensor device it would not really be more complicated, it is just a difference in how the state gets broadcast. Yes, it will be supported but not with the PCB. It will also be limited to a max of four buses of 512 sensors since the LCC event mapping will need to be pre-computed during compile time (it will be configurable with a default value). With the shift to LCC I'm working on offloading non-CS tasks to purpose built devices, I'll have an S88 -> LCC bridge as soon as I have the PCB side of things stable. I'd encourage you to shift over to that at that time.
I'm looking back at S88 again just to test it out, and one thing I'm noticing in both the old and new code base -- it talks about needing a data pin but I don't see any place where that pin number is defined? The other three pin definitions are obvious but I'm stumped on this one even after looking at all the references to 'dataPin' in the code. Can you point me in the right direction? Also I pulled the latest code from github and one huge change stands out -- there is no longer a Config.h file to set all of the pin references and apparently everything is configured through a web interface now? So how do I get the same configuration transferred between multiple ESP32s? I always have at least a couple of chips that I swap between as I work on the code and having that information hard-coded meant there was no chance of errors with the pinouts. And regarding your reference pages for the software -- "Building the ESP32 Command Station code" does not actually give any information at all regarding the use of PlatformIO or building the code. Isn't this a command-line compiler? I guess I assumed there would be an example of the command needed to compile the code once I get the software installed.
S88 data pin is defined when you define the S88 bus. It can be configured via the web or via text protocol. The only hard limit on the number of S88 buses is the number of free "data" pins. Config.h was broken into smaller chunks and is still present under the include tree. You can configure it through there still, the development branch will have slightly different config options than master at this time. I'm working on transitioning to a more dynamic model where the config is defined at compile time for defaults but can be redefined at runtime via the web interface, this is partially available on the development branch but it is not fully functional or stable yet. This is one reason I'm looking at shifting to dynamic config rather than static config, once you have the CS setup the config typically won't change from one version to the next. Once you have your CS configured it should continue using that config regardless of the CS code version unless you explicitly request it to reset to defaults or reconfigure it yourself. It can be run as a commandline tool or as part of an IDE. A lot of people use it in VS Code. For commandline you can run: pio run -t build -t upload... that should compile and upload the binary to the esp32. In the IDE there is a similar build and upload option. I'll make some adjustments to the page to improve it further as the current content there is pretty much a direct copy of the old wiki data and it is not entirely useful as written.
Ack how did I miss that whole folder? OK thanks! I'm assuming you are storing the config in EEPROM space? My concern was where I blow an ESP32 and want to drop in a new chip with the same pinout, without having to reconfigure the whole setup. With arduinoIDE I could just keep a copy of the hex files and flash a new chip with all the configuration already done (I assume platformIO is similar). Just wanted to point out that option as you move forward with the code. Ah ok, seems like I've always seen that code referenced from the command line, I didn't know it had an IDE component as well. I'll have to get it installed soon. I picked up a 3D printer (Ender 3 pro) at the end of January and have barely touched the trains since then... but I'm finally getting back around to them. Just so many other things going on that need attention around the house (sigh).
There is no EEPROM on the esp32, it is emulated via a segment of flash space. The config is stored either on an SD card (preferred) or on SPIFFS (default). So, when you flash the new binary to the esp32 it should pick up the existing config and use it. If you are starting with a blank esp32 (with no existing config) the CS code should seed the defaults based on the compile time settings. From the web interface it is also possible to revert to this default config with the "factory reset" button (new on development branch). I know the feeling. It's been a rather busy summer and my layout has been neglected for a variety of reasons.
now let's have a look at the lmd18200 datasheet, this is its the CS functionalities need 3 cases : - obviously the 2 dcc levels : source1_sink2 and sink1_source2 - and the high impedance (or open or no active or etc.) state the high impedance state disconnects the power from the track when the esp32 is in reset mode, or in case of emergency (short, overload, etc.) or while listening to the railcom feedback datas for this, 3 input pins have to be animated : - the Dir pin determines the dcc level - the pwm and Brake pins determine if the H bridge is active or in high impedance state you can see, in any of the 3 cases, Brake = /pwm so if we just invert the pwm pin in order to create the Brake signal (transistor, inverter gate), we can save an esp32 pin
This makes sense and a simple NPN/PNP can be used as inverter. Another pin can also be saved by routing the RC-SHORT bit into the CS input from the LMD18200. Let me digest this a bit more and work through the PCB suggestions/corrections you have sent over.
Atani, with your PCB solution what is provided for LCC implementation? In other words, what else will I need to get to complete the LCC network? I have been doing a lot of reading on this and have a good idea on how I will implement my Nano based nodes for my automation needs but I didn't want to jump ahead and buy a bunch of stuff from RR-CirKits that will be redundant with your CS implementation. I believe that JMRI will interface with DCC++ and LCC simultaneously. Will that all happen through your CS WiFi connection or will I need an LCC Buffer-USB?
The PCB provides for the CS to connect via a CAN connection to the LCC bus for publishing of a handful of events as well as consuming a handful of events. Not much more than that, it is really just a basic LCC node in this regard. Nodes that consume/produce events as well as connectivity between them. It can but I'd suggest drop the DCC++ connection entirely once you move to LCC. The DCC++ interface has a number of limitations and JMRI already can talk the corresponding LCC commands (including throttle commands!). I'd suggest using the LCC-Buffer as your connection between JMRI and the LCC network. However, the CS can use WiFi to connect to the LCC bus if you setup an LCC hub (perfect use for an rPi with JMRI on it!). The CS itself can act as a hub but I've disabled the option to enable it from the web interface due to unreliability in the network stack, pulling the CS CDI over WiFi with the CS being the "hub" will crash the CS at around 3.5kb transferred. The instability of the network stack is one of my current focuses before the release goes out. If you want to try it, pull the development branch code and flash it to an esp32, start an LCC hub and check the serial console for lines like: Code: [UPLINK] Connecting to raspberry-pi:12021 ... Note that the development version of the CS when using the "pcb" build profile will default to a softap only configuration which you can connect to and configure the CS via the web interface. Note that the PCB profile does default to using an SD card (disable it via platformio.ini if it crashes on startup due to mount failure, I'll be fixing that before the release goes out). Also note that the web based throttle *WILL* crash the CS requiring a restart due to a bug in the websockets implementation currently in use. I'm working on a replacement for the webserver code (which includes the websockets) which should alleviate this issue.
Thanks, that answers my main question! 1-So I wouldn't go wrong getting the RR-CirKits LCC Starter Kit 2-Are you saying that with the PCB CS set-up connected to LCC that I will be able to use Engine Driver to control trains through the WiThrottle to JMRI connection to LCC? In the past I have connected JMRI via WiFi to the CS which worked well, so can my PC be the hub you mentioned? 3-I think this jives with the PC hub configuration.
Yup, I have one myself. I stashed the power point in the "center" of the layout space (where the CS and power supplies are) with a terminator in the A side and the B side connected to the CS (2ft cable I think) and a cable running out of the CS to the LCC-Buffer with the other terminator in it. Once I have my staging area wired up for LCC block detection It will connect to the bus somewhere between the CS and the LCC-Buffer and other nodes on the upper levels. I may end up with a second Power Point in the future for upper levels. Yes, it should be possible. JMRI can translate to/from LCC and WiThrottle. The CS itself will also have a WiThrottle endpoint at some point in the future as well. Yes as long as the hub advertises itself via mDNS so the CS (and other nodes) can find it. I'm not aware of any windows version of the LCC hub, though it shouldn't be all that challenging to make one. It is a shame that the JMRI built-in hub is somewhat broken, there are some plans to fix it though. There is also the ModelRRSystem LCC Router (Tcl based) that may work on windows, this has the added benefit of supporting the binary form of the TCP/IP connections (though it is not used widely yet). The other option outside of JMRI and ModelRRSystem is to refresh the Windows build support for OpenMRN and compile the hub app, this may require a lot of work though. Yes it should likely. But if you have the LCC-Buffer you won't need the hub as you can use the CAN connection.
I pulled down the current master code last night and just uploaded it to my ESP32. I have motor control over my loco, however as with the previous version I still have no working function keys. I confirmed this through the telnet port, when I turn one of the functions on/off nothing is shown in the text output. I can manually enter a function command through telnet and the loco picks it up, but the buttons on the web interface seem to have no effect. Is this a known issue, or do I need to set up something under the new Command Station code before the functions work?
That sounds like a bug in that the processing of the message was not completed as the code should have printed out that the function state changed. I remember some sort of bug in this area but can not remember what it was now or if it was indeed fixed. There is a critical bug on master which is why v1.3.0 was not released and won't be released, this bug being related to the DCC signal generation flooding the packet queue. I tried a number of fixes for this but found that the queue would get bogged down as the number of active locos increased and after four or five active locos the queue could not keep up and would delay packets from being delivered to the track by five to ten seconds which is not acceptable. After finding that bug the release of v1.3.0 was put on indefinite hold and the ground up rewrite of the DCC signal generation code started. This is what is now available on the v1.5.0 branch which is not 100% compatible with v1.2.x versions already released. As part of the migration to v1.5.0 it will be necessary to run an erase flash command before flashing the v1.5.0 code to the ESP32, this does imply reconfiguration of stored turnouts, sensors, outputs, etc. I had intended on supporting a migration path from older versions but there appears to be a problem currently with the SPIFFS storage of existing config data which I have not found a clean solution for. If no solution can be found then the erase flash and reconfiguration will become necessary, which in most cases is likely not a bad thing and would be necessary for those moving from SPIFFS to SD anyway. As for the v1.5.0 release, which will bring along all functionality that was intended for v1.3.0, there are a couple issues which I'm working on before merging the development branch to master and finalizing the release of v1.5.0. Right now these issues are: DCC: Investigate issue with RMT peripheral signal voltage levels. Web: Testing all endpoints to ensure 100% functional parity to previous versions since v1.5.0 replaces the entire http and json handling code. DCC: RailCom Testing (currently disabled on development branch) Web: Loco Roster features being expanded in the web ui (functions and labels to display on throttles!) Web: Refresh tables upon add/edit/delete action completion. Hooks are present but not wired up fully yet. Issue #1 is the most concerning as some motor shields appear to not respond to the DCC signal changing from HIGH to LOW when driven by the RMT peripheral of the ESP32. @esfeld initially reported this issue but I haven't been able to confirm it yet but have reached out to a contact at Espressif and I have received a couple suggestions on how to debug this further as well as a possible workaround. Issue #2 has one odd crash which I have not yet narrowed down but has been reproduced by a few people at random intervals, the LwIP/TCP stack on the ESP32 crashes at times due to a null pointer deep inside the code and the available backtrace is not very meaningful. The remaining issues are lower priority "nice-to-have" type of issues being tracked and thus will not hold up the release of v1.5.0.
Ah ok... Since the code I installed last night identified itself as 'Command Station' instead of "DCC++ESP32' and the whole structure of the code had changed I thought this WAS the new code release. If I pull code from the development tree, should that be somewhat functional at this point? I'm actually trying to figure out an issue... I got my first Soundtraxx tsunami2 decoder (steam 2), but when I try to issue F2 or F3 for the steam whistle, all I hear is a hissing sound (all other tested sounds are fine though). Since the function buttons on the web interface don't work, I actually have to go to my computer in another room, send the telnet command to turn on the function, then go back to the train board to see what's happening. So I don't know if I just miss the initial whistle sound, or if it's really not working, and I'm hoping I don't need to send the unit back to Soundtraxx.
The rebranding effort was done in v1.3.0 which is on master but it was not released. If you pull the development branch it should be mostly stable. There are definitely a few areas which may crash and if you find one please decode the backtrace and send it over via email/PM on here or an issue on GitHub. Congrats on a great sound decoder! It sounds like you are catching the tail end of the sound. I'd suggest maybe setup JMRI with the WiThrottle server and connect to that via a mobile phone with the WiThrottle app on it. Or use a telnet app on a phone to send the required command to enable the function. The other option is move a computer closer to the layout and use JMRI directly to interact with the functions on the loco.
