DCC++ESP32 Base Station

Atani Dec 10, 2017

Tags:
  1. Atani

    Atani TrainBoard Member

    767
    564
    15
    Unfortunately Arduino IDE is a non-option for the CS code due to a number of factors, but two are big problems:
    1) no support for custom build steps (used for generating index_html.h for the web interface to have it cached in memory as a compressed blob)
    2) no support for custom partition maps

    There are other factors but these are the biggest ones which do not have a good solution for at this time. The custom partition support is coming at some point but is currently not available in a reliable manner.

    Hopefully only a small number of things will need to be adjusted, I can probably add support for a non-monitored power district which would use just one pin (ENABLE). The signal pin should be common to all OPS tracks with only the current sense and ENABLE pins dedicated to each district.

    There should be plenty of "free" pins as you will only need the additional "ENABLE" pin for additional districts. The board extenders (I2C or shift registers) can be added but there is no direct support (yet) as I haven't had need for them. I prefer to have the CS only know about the DCC side of things (this includes turnouts) and leave sensors and outputs to purpose built devices (which can talk through various protocols).

    I'm open to having a few extra config flags in the Config.h to turn off features to shrink the binary but having them doesn't hurt either if they are not actively used (I'll add a TODO item to reduce the overhead when sensors are not actively defined as well).

    Yes, it is a mandatory component as it is the basis of the ESP32 IDF library which is the underlying layer for all ESP32 code (Arduino or otherwise).

    There are some but not many direct usages, I've got a few changes to the code on the development branch which add a few more references but I've intentionally kept the code relatively free of FreeRTOS usages as they don't generally make sense for most use cases. The only primary use cases are for task creation to move some pieces of code to higher priorities (DCC signal generation as example) that are not tied to the "loop()" function (which runs at priority 1, just above IDLE). There are a few other usages but most of them are abstracted out by code from OpenMRNLite (LCC stack, most of which is disabled out-of-box).

    I'd suggest using either VS:Code or Atom as the IDE and install the PlatformIO IDE extension for either. This will take care of pulling in only the pieces that are required, which is not a lot really.

    If you have a different IDE that you prefer you can opt for PlatformIO Core which is a commandline only tool and then install the Espressif32 framework which will give you all of the needed tools to compile and send the code to your ESP32. For commandline you can do this by running these commands from the DCCppESP32 directory (where platformio.ini exists): pio run -t build -t flash
     
  2. crusader27529

    crusader27529 TrainBoard Member

    227
    163
    8
    [QUOTE="
    Hopefully only a small number of things will need to be adjusted, I can probably add support for a non-monitored power district which would use just one pin (ENABLE). The signal pin should be common to all OPS tracks with only the current sense and ENABLE pins dedicated to each district.

    There should be plenty of "free" pins as you will only need the additional "ENABLE" pin for additional districts. The board extenders (I2C or shift registers) can be added but there is no direct support (yet) as I haven't had need for them. I prefer to have the CS only know about the DCC side of things (this includes turnouts) and leave sensors and outputs to purpose built devices (which can talk through various protocols).

    I'm open to having a few extra config flags in the Config.h to turn off features to shrink the binary but having them doesn't hurt either if they are not actively used (I'll add a TODO item to reduce the overhead when sensors are not actively defined as well).
    [/QUOTE]



    Thanks for the advice Mike.....I installed Atom and the platform.io extension, and was successful in compiling blink and your code!

    Unfortunately, I couldn't tell if your code worked, as I've no idea(yet) how to actually use it.

    Time to dig into the code.

    I don't need any current sense pins beyond the program track, as all the enable/disable/overcurrent/auto-reverse functions will be done in the remote boards that drive the IBT-2 modules. So, that would also free-up more pins.

    It seems to me that with some minor changes that your PCB could support whatever I need with only the minor change related to NOT sensing any current except for the program track. What pinout are you using for the ESP32 module(I assume that it will connect with headers like an Arduino NANO)???

    What CAD/CAB/PCB design tools are you using? I use KiCad, which is free with no size limits, but the learning curve is steep........
     
  3. Atani

    Atani TrainBoard Member

    767
    564
    15
    Ok, in that case you will want to route the OPS current sense to GND as a short term solution. I'll add a way to define a non-monitored interface so you can switch to that easily with small code updates.

    Use the serial monitor in atom (PIO Monitor) and check that it is printing that it connected to WiFi and prints the IP etc. You can then connect to that IP via a web browser and interact with the CS or you can direct JMRI to connect to that IP (or hostname possibly).

    The PCB I'm working on will use a TTGO T1 board (https://github.com/LilyGO/ESP32-TTGO-T1) for the ESP32 and provide an track outputs for OPS/PROG and an LCC interface (RJ45 jacks). For your remote setup this PCB may work but it will have fewer pins available than the current setup since there are additional features included. However, the LCC interface does have support for remote "boosters" which pull the OPS signal from the CS via LCC and generate the DCC track side signal remotely without any current sense feedback to the CS (it doesn't know or care about it). I need to dig into the specs for this but I believe it also uses RS485 to encode the raw signal into an A/B pair (I'll confirm and share once I know for certain).

    I'm also working with KiCad, I'm still learning it a bit and while it does have a bit of a learning curve it isn't too bad once you get the hang of it. I'll be checking in the files once I have everything ready and reviewed.
     
  4. crusader27529

    crusader27529 TrainBoard Member

    227
    163
    8
    Trying to monitor the serial port, I get this......obviously, it's the port I used to load the code into the ESP32:

    PS C:\Users\Geoffrey McDermott\mystuff\arduino\esp32dev\DCCppESP32-development> pio device monitor --po
    rt COM12 --baud 57600
    could not open port u'COM12': could not open port u'COM12': WindowsError(5, 'Access is denied.')
    PS C:\Users\Geoffrey McDermott\mystuff\arduino\esp32dev\DCCppESP32-development>
    >>

    Tried multiple baud rates, but I don't think that's the problem. I don't see any other SW trying to use that comport.

    Shut down Atom, restarted, that worked once I determined the baud rate was 115200......found where to use my network SSID and password, and it obviously connects, still don't know what to do from there, but I'm happy!

    I think I'll use your setup, more or less completely, but not use the HW LCC and fancy stuff you've added.

    I'll add an interface board to connect to the HW that I'm already using to drive the external stuff, and that'll allow me to adjust for the pinout differences from your TTGO ESP32 and the base development ESP32 that I have. That will give at least 2 different ESP32 modules(I may make adapters for more types) that can be used with YOUR system, or with my system.

    Any idea when things will get to the next stage, specifically with the HW/PCB layout? I can help with that, and with some planning, the various parts that the user might want to install can be as simple as attaching a ribbon cable to the module they want to use with the system. Think about it.

    I'd really like to colaborate with you on this...............
     
  5. Atani

    Atani TrainBoard Member

    767
    564
    15
    I've seen this only when the monitor was closed incompletely. I'm not sure where in Atom exactly but there should be a way to see what is running currently, in VS:Code there is a tab at the bottom of the window that contains this. If you can't find it you can always use taskmanager and kill pio.exe or pioplus.exe (whichever is running) and PIO should restart the process automatically for next use.

    Great, if you use the built-in monitor option from PIO it should default to 115200 as that is defined in platformio.ini (without it, it will default to 9600 baud)

    From the ESP32 dev module "standard" there are only a couple trivial differences to the TTGO T1 board, namely a 5V and GND pin swap (GND between 19 and 21 on DEV module vs 5V on TTGO T1) and two additional pins on the DEV board (one being the 5V pin and other CLK which is not externally usable). The other minor difference is the pin spacing, the DEV module is 0.1" wider from pin row to pin row. So the adapter board would not need to do much more than route the 5V pin and drop the extra CLK pin. Another option is take the circuit/PCB I'm working on and slightly expand it and re-route without needing an adapter plate for the default PCB I'm working on.

    The LCC integration would be on board and require an MCP2551 DIP8 chip, a few resistors/caps and the RJ45s. I'll have kits available that will have everything available in a solder ready setup as well as make the PCB files available for oshpark or similar.

    I'm currently reworking the circuit slightly to fix a problem with the L298 h-bridge since it won't work very well with commercial boosters (it has a chance of not detecting a short circuit under very specific circumstances). Once I have that sorted and a bit of clean up done I'll be ready to share the circuit for review.

    I'm currently leaning towards LCC with a couple extension points on the PCB (I2C and Serial). Ideally most extensions can be simply extensions off of these interfaces but having extra pins broke out to ribbon cable headers is very doable. I'm planning on having a couple "ready-to-compile" options available in platformio.ini, currently there is only "esp32" which is generic and requires configuration of the features you would want to include. I'll be adding "esp32-pcb-lcc" which will be usable for TTGO-T1 + LCC + PCB in a ready-to-flash setup where no configuration is required. We can add additional ready-to-flash options with instructions on how to run the build to generate the binary for the configuration. The current defaults will all remain where the user can define whatever specific pins they want to use but with the PCB there will be a few pins that are pre-selected by the PCB.

    I'm eager to extend the usage of the CS code further, ideally including LCC since there are a few major developments coming later this year regarding LCC from TCS.
     
  6. crusader27529

    crusader27529 TrainBoard Member

    227
    163
    8
    Excellent!

    What type of developments from TCS?
     
  7. Atani

    Atani TrainBoard Member

    767
    564
    15
    They are working on a WiFi enabled CS to pair with their WiFi throttle that will be available later this year. The throttle supports WiThrottle and LCC as the transports. This is partially why I'm tracking both of these as additions to the ESP32 CS code, I haven't sorted through the spec docs fully for the LCC side of things yet but I have basic support already and JMRI is able to communicate with the CS via LCC (WiFi or CAN network based) to control DCC locos or accessories.

    I also have one of the throttles on order for testing interopability with the ESP32 CS code both via WiThrottle and LCC. It will already work via WiThrottle with JMRI as a proxy to the CS (DCC++ protocol), but I'd like to have it work without JMRI as a proxy.
     
  8. crusader27529

    crusader27529 TrainBoard Member

    227
    163
    8
    GREAT! The major issue that I have with DCC++ is that it doesn't have any support for commercial throttles, and assuming that TCS uses the standard, that opens up a ton of opportunities. Many don't really like the touch screen for control, and would prefer something with tactile feedback, like a hand-help throttle with buttons and maybe a speed knob, sort like the ESU CS solution, which is NICE, but expensive.

    Do you know if ESU (and any other wireless throttles) use the same standard, using WiFi?
     
  9. Atani

    Atani TrainBoard Member

    767
    564
    15
    This is a general problem with DCC++, it doesn't support most of the "standard" protocols that other CS (and devices) support. I have been working on LocoNet support in the ESP32 code as well and it does technically work now but it is somewhat limited. I'll be working on expanding that a bit more soon.

    TCS is setting the standards here somewhat. There is no definitive "standard" that everyone implements or supports. TCS will support WiThrottle and LCC out-of-box and who knows what else they might add later.

    Unfortunately I can't confirm either way on this but I can say that WiThrottle support is becoming more widespread and there is no specific reason that it shouldn't be supported by more devices. Even Digitrax supports WiThrottle now via their WiFi interface device.
     
  10. crusader27529

    crusader27529 TrainBoard Member

    227
    163
    8
    I know you have nothing else to do(HA!), but you ought to put together a simple video of actually interfacing with JMRI and maybe some other simplistic functions. It'd help many to decide how much effort those on the fence should put behind your project.

    So far, I'm into this 100%, primarily because you are actively developing the project. I also intend to have PCBs made for sale(little or no profit) because most probable users won't want to go through the process to get PCBs made, or to even use platform to compile the code. The best way to get around the ability gap with software would be to have a file in the home directory where the ESP-DCC++ binary/executable is located that would define the WiFi parameters to connect and eventually for other protocols, so a recompile wouldn't be needed. I assume that you're familiar with the Debian structure for wpa_supplican.conf.....that would be a good model to configure WiFi at least. It's your project, but having a pre-compiled binary versus all the other stuff would be easier for almost everyone. Obviously, anyone could add or modify the 'source' code in any way they would want, assuming enough skill.
     
  11. bocabob

    bocabob TrainBoard Member

    24
    9
    2
    One of the things I like about this project is the availability of information and guidance. Atani is super responsive to all levels of questions. The GitHub readme is laid out well. I had no great difficulty building the compile and test environment and understanding the state of the project. But I am probably in the top 5% in the hobby on computer literacy. I think of the project as being at the top of the development pyramid, it takes someone who wants to tinker with computers to be interested. As the project matures (which seems to be moving at a good clip), the bar is lowered to people who can follow a cook book set of directions. The next step on the adoption curve is the availability of kits or finished goods with simple instructions. Commercial products would need a very simple way to update the code.

    I think videos are great for some. Personally, I prefer web page documentation with links embedded in the steps, but everyone learns differently. To promote adoption, one has to cater to the variability of style, ability, and use cases. From what I read, I think Atani is on this path. It sounds like we are close to having a reference platform with a kit available. The hardware issue seems to have caused some wheel spinning in the past but also probably has helped exercise the software.
     
  12. Atani

    Atani TrainBoard Member

    767
    564
    15
    You are 100% right! I do need to put out more documentation, which can include videos, on how everything fits together and how best to utilize the system for various tasks. The esp32 is capable of quite a number of things and currently the CS is only barely scratching the surface of it's actual capabilities.

    We are in near perfect agreement here! I am planning on shifting the CS code over to dynamic reconfiguration without recompilation through a configuration portal exposed by the webserver. With this shift the CS can be reconfigured and a simple restart will enable/disable functionality. This will include a more comprehensive configuration screen of some sort for the WiFi parameters, similar to the WiFiManager libraries which are available today for the esp32 (though, these all have integration issues which is why I haven't looked at including those directly).

    Yes, the pre-compiled binary in a ready to deploy manner is the ideal approach. There are only a few hurdles preventing this at this time, one being everything is driven by compile time options. Once I get the next version out I'll be exploring the options of moving to dynamic runtime configuration via a config file of some sort stored either in SPIFFS or on an SD card (TTGO T1 offers an SD slot on board). The user won't need to modify this file directly but they can if they choose to, it will be some form of plain text (likely json as there is a parser already in use by the CS for this).

    Yes, I plan on the same. I'll be offering the following options:
    1) bare PCB (no parts)
    2) bare PCB + parts
    3) populated PCB

    All at cost. My goal is to shift the users over to explore LCC as an option for extending the control of the railroad empire. The CS itself won't be managing the extended devices unless they are on the DCC only side, there are a lot of options available now for LCC which can make many aspects of the layout management easier (block detection, signals, random lighting, turnout control, etc) without requiring anything more than a simple CAT5 cable to connect "nodes" together (or WiFi if the node supports it).

    YAH! Thanks for the awesome feedback, I'm always trying to improve the documentation of the project to make it easier to adapt for various needs.

    The project for basic usages is relatively stable with only a few issues which need to be fixed for the general usages (performance of the web interface being one of these).

    Working on this :) I'm hoping to have something ready for users to pick up and run with soon.

    Even hobby programs need this and this is partially why I have built into the web interface a simple way to update the CS without directly connecting it to your PC to upload new code. If you build the binary in PIO (or eventually download from GitHub!) you can go to the CS tab and there is a Web Update section which can be used to upload the binary. I'll be exploring support for streaming the binary to the CS from inside JMRI via the LCC firmware update routines soon.

    Yes, it has been a bit of an uphill battle for a number of reasons but it is also a very good exercise of patience and documenting the required connections to make it work.
     
    bocabob likes this.
  13. crusader27529

    crusader27529 TrainBoard Member

    227
    163
    8
    Two things.....first, when I configured my Arduino based system, I was successful min using the IBT-2 on the programming track. Concerning that, do you have any plans on including/requiring the 298 based module for programming, or are ALL the MD parts off-board?

    Second, concerning configurations, the text based config file ought to be used in such a manner that the config is read and stored on the ESP32.......subsequence reboots should use that config if a new one isn't made available, plus for any particular protocol, if no valid config exists, the CS should disable that particular feature.
     
  14. Atani

    Atani TrainBoard Member

    767
    564
    15
    For the PCB I'm working on it will include the L298 for the OPS and PROG outputs. However, it can just as easily be setup to break these out to a connector on the edge of the board that can be used to go to the other motor board types.

    Yes, the goal will be to provide a couple binary options (one with specific defaults enabled for the custom PCB, one for other boards). In the default case when no config file is detected the CS will startup a SoftAP and enable only basic functionality (L298 motor board, default pin setup, no S88/LCC/Nextion/LocoNet/etc). The user would need to connect to the SoftAP and configure the CS features from the web interface (including connecting to an AP)

    This functionality though will take some time to get right, it needs to just work for people to be able to use it successfully. That will include the initial flashing of the code to the ESP32 which will require documentation and additional binary bits (partition map, bootloader, etc... all of the pieces that esptool.py pushes to the ESP32 today via the IDE)
     
  15. mabcat

    mabcat New Member

    5
    1
    1
    I check back every day to see if there are updates on the PCB. Looking forward to it greatly!
     
  16. ghruei

    ghruei TrainBoard Member

    24
    4
    2
    Regarding easy of use of this project. There is an issue in that moving from the Arduino IDE to VSCode + PlatformIO (which is what I use) due to the initial effort in getting it all setup. However for me the biggest issue has been trying to get the hardware to work reliably. I am still having major issues with this side despite I thought I had it working well. I have got a few components on order to try and elimate the motorboard. I really think the current hardware I have does not like me considering it has now destroyed 3 decoders, though with my luck I may be better waiting for this PCB.

    With throttles I am trying to build a wireless throttle of my own using one of the several ESP32's I now have. I prefer physical controller rather than a touch screen. I planning it will talk directly to the DCC++ basestation as it seems just simply enough to send out the relevent commands. If I get any success I will put it on here.
     
  17. Atani

    Atani TrainBoard Member

    767
    564
    15
    The basic DCC++ protocol can be used for this or you can leverage a few extra commands that may make your usage a bit easier, like Tex/tex/fex which operate on address rather than the ID/slot. The DCCppThrottle project currently uses a Nextion for input and leverages both the http and socket based interfaces (socket is used only on development branch currently). I'll be releasing a version of this throttle with the next CS release.

    I think your use-case may be different than other people's use-case of the ESP32/CS code. I'd be eager to understand a bit more of it as I have yet to destroy any decoders.
     
  18. crusader27529

    crusader27529 TrainBoard Member

    227
    163
    8
    I think I'm ready to see your PCB layout so I can decide on how it would connect to my side of things, specifically what else that might be needed in the way of jumpers or extra connections, at least.

    I like the ability to drive commercial external boosters, and my configurations do the DCC signal inversion already, so I can just use the basic signal. I also use the base signal to implement the reverse function on the MD without actually trying to reverse the power to the tracks, just the signal to the MD.

    Originally, I used the IBT-2 for ALL power districts, including the program track, and it worked well, but it's such a waste. Using the L298 onboard(or offboard) is a better idea. If it's onboard, is the implementation use any surface mount parts? We both know how much fun trying to solder SM components without the correct tools(air soldering gun), and most non-HW types have a hard enough time just soldering in general, make SM parts a non-starter.

    Your schematics would be nice also......I'll sign any form of non-disclosure if needed.

    One more thing.....my original implementation had an operational issue where when the Arduino was reset and the I/O pins were floating, the RS485 parts would interpret that as an enable to the MD, but since the Arduino was reset, the DCC signal wasn't being generated. The result was full DC voltage applied to the tracks, and the locos that would run on DC or DCC would take off for a second. I simple pullup wouldn't work because of the way I used the enable signal to control the onboard Red/Green status LED for each power district, as the pullup required to solve the issue prevented the Arduino from controlling the enable pin(not enough current drive). I resolved it without a major redesign by inverting the enable signal that controlled the RS485 so a float(usually interpreted as a high) actually was a disable sent to the MD. In the way I plan on using your design, I won't have that problem, but it's one thing that you need to verify on your design........
     
  19. ghruei

    ghruei TrainBoard Member

    24
    4
    2
    Ok. Trying this again. With the decoders it is the motor control side which is damaged the other functions still work. So I can use them for something else at least.

    I have been experimenting with the Arduino ESP32 board format. A0 pin is jumpered to A4 and A1 pin is jumpered to A5
    Currently neither the prog or the ops works. Switching the debug it is showing the messages about the timer are missing again.

    [OPS] Enabling DCC Signal
    [OPS] Adding reset packet (25 repeats) to packet queue
    [OPS] Adding idle packet to packet queue
    [OPS] Creating RMT feeder task
    [OPS] RMT feeder task starting up
    [OPS] Disabling DCC Signal

    So I wondering why this is?
     
  20. Atani

    Atani TrainBoard Member

    767
    564
    15
    Timer?

    There is a bug with the RMT code corrupting the last bit of the checksum byte of the packet. I'm working on a quick fix for that, I'm not certain when that broke but I can say for certain that it is broken. I'd suggest use the master code for now.
     

Share This Page