Hi, this is my first Trainboard post so by way of introduction I will say that about a year ago I dusted off my attic layout after 14 years gathering dust while I focused on Scouting with my two sons. While that remains a priority for me, I am carving out more time for trains. There was a lightning strike in those 14 years, so the first order of business was to replace the fried circuit breakers and get the DCC working. I then finished my yard track, turnouts, and control panel, which led me to the turntable automation. That led me to an Arduino solution and an awful lot of reading. So, I automated the doors on my roundhouse, looked up and said “What’s next?” And now I am here, after reading 89 pages of the introduction forum, 30 of this and several others I have decided to replace my arthritic DCS-100 with a DCC++ solution. After all that research, I have chosen the ESP32 as the more advanced platform. I was tempted to go with the Locoduino Library approach, as it seems a good clean method and well presented (even with the Google Translation). I really appreciate all the work that has gone into this solution, from its inception, through the forks and all of the contributions. More compelling is the vision of enhancements from Mike and others. I write this as I await the slow boats from China to deliver my parts. I’ve set up PlatformIO, can compile with no issues, and am learning to do more than just download on GitHub. On my fork, my first change will be to add support for LMD18200 / MAX471 as I ordered 5 of these when I thought I would implement the Locoduino library. Of course, this will also mean that I will need to implement multiple main power districts (as implemented on my layout). Aside from that, I expect a fairly good plug in to what I run as I already use JMRI.
First off, Welcome! I'm a former scout myself, reached Life scout rank and had only a handful of merit badges and the project to go for Eagle but my interests shifted at the time and I moved on from it. I'm not sure how you plan on using these or implementing it but I'm eager to see how it works for you. Feel free to submit a PR with the changes and we can pull them into the code. I suspect most of the work will be in just adding a define for the LMD18200 for 3A max and probably 2.75A as limit (similar to Pololu). The LMD18200 chip appears to have current sense capability so it may be possible to wire that output to the ESP32 analog pin(s) though some circuitry may be required. I'd suggest using just one OPs output from the CS and split it from there via boosters or similar. The majority of the ESP32 boards available can only monitor at most six current sense inputs. Adding additional power districts in the DCC++ESP32 code is doable today, each additional district will require two pins, one for enable (can be almost any GPIO pin) and one for current sense (must be one of the analog pins above 30). The signal pin will be common to all OPS outputs (partially why adding a booster *AFTER* the OPS track output is possibly easier). I'm right there with you on waiting for parts, I've got a few orders that are slowly making their way to me from China. Some of which will be leading to the custom PCB I'm working on for the CS, others are destined for my signals (addressable RGB LEDs). In my setup it will be 100% LCC connectivity with standalone boosters receiving the DCC signal from the CS via the LCC bus with the CS only driving staging and programming track. I'll be sharing the details on that in the future after I have the PCBs in hand and tested fully, but LCC integration is on the roadmap for v1.3.0 which tentatively will be next month. v1.2.1 will be coming out within a week with a handful of fixes that missed v1.2.0.
Yes, the use of the LMD1820 is well documented on the Locoduino site @http://www.locoduino.org/spip.php?article187 They use the MAX471 for the current sense. Their tests show that the chip provides a superior signal form to some other drivers. As you say, I expect it is simply a matter of defining another motor driver. I have read the multiple power district thread and there was also discussion in the introduction thread, so I have an idea on implementation. I'll get it going with just main and programming first, then see about adding additional drivers one at a time. My only concern is the speed of the shut down. Some people have noted that down stream circuit breakers and auto reverse devices have been too slow. My layout has a number of auto reverse sections, so I need them to work. But one step at a time.
Interesting.. I haven't seen any issues with current sense on the esp32 myself, there are known limitations on the arduino AVR side though. The approach used by that thread is not really supportable on the esp32 side, it is an interesting approach though. The current ESP32 code does support additional power districts but there are limitations on the number of supported districts. Adding the additional districts can be done around this point by calling registerBoard, be sure not to pass true as the last parameter otherwise you will be current limited to ~300mA (prog track is restricted to a much lower threshold). I'm not sure what sort of slowness has been observed, I don't have any auto-reverse sections on my layout but I'd be very surprised if they are too slow to kick in (especially considering these are commercial products likely). It would be interesting to see more on this if you have issues.
Welcome and awesome! Very interested if you add the lmd18200 and max471. I have used on the arduino and found the current sense to be far superior to the Arduino motor shield. I like the setup overall better as has more power as well. Of you get it working I'd like to work on a custom PCB with it where things plug and play similar to what Atani is doing for the original chip.
Not content to wait for the slow boat, I got an esp32dev from Amazon. While the build seems to work, I am getting an error on upload that I can't figure out. I hope this is just me not knowing something obvious... Processing esp32 (framework: arduino; platform: espressif32; board: esp32dev) ------------------------------------------------------------------------------------------------------------------------------------------------------- Verbose mode can be enabled via `-v, --verbose` option CONFIGURATION: https://docs.platformio.org/page/boards/espressif32/esp32dev.html PLATFORM: Espressif 32 > Espressif ESP32 Dev Module HARDWARE: ESP32 240MHz 320KB RAM (4MB Flash) DEBUG: CURRENT(esp-prog) EXTERNAL(esp-prog, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa) Library Dependency Finder -> http://bit.ly/configure-pio-ldf LDF MODES: FINDER(chain+) COMPATIBILITY(strict) Collected 34 compatible libraries Scanning dependencies... Dependency Graph |-- <SPI> 1.0 |-- <ArduinoJson> 5.13.4 |-- <AsyncTCP> 1.0.3 |-- <ESP Async WebServer> 1.2.0 | |-- <AsyncTCP> 1.0.3 | |-- <ArduinoJson> 5.13.4 | |-- <FS> 1.0 | |-- <WiFi> 1.0 |-- <ESP8266_SSD1306> 4.0.0 | |-- <Wire> 1.0.1 | |-- <SPI> 1.0 |-- <LiquidCrystal_PCF8574> 1.1.0 | |-- <Wire> 1.0.1 |-- <ESPmDNS> 1.0 | |-- <WiFi> 1.0 |-- <Wire> 1.0.1 |-- <EEPROM> 1.0 |-- <Update> 1.0 |-- <LocoNet2> 2.0.1 | |-- <EEPROM> 1.0 |-- <NeoNextion> 2.2.1 |-- <WiFi> 1.0 |-- <FS> 1.0 |-- <SPIFFS> 1.0 | |-- <FS> 1.0 |-- <OpenMRN-lite> 1.0.0 | |-- <WiFi> 1.0 Retrieving maximum program size .pioenvs\esp32\firmware.elf Checking size .pioenvs\esp32\firmware.elf Memory Usage -> http://bit.ly/pio-memory-usage DATA: [== ] 19.4% (used 63624 bytes from 327680 bytes) PROGRAM: [====== ] 59.7% (used 977366 bytes from 1638400 bytes) Configuring upload protocol... AVAILABLE: esp-prog, esptool, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa CURRENT: upload_protocol = esptool Looking for upload port... Auto-detected: COM6 Uploading .pioenvs\esp32\firmware.bin esptool.py v2.6 Serial port COM6 Connecting........_____....._____....._____....._____....._____....._____....._____ A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header *** [upload] Error 2 ============================================================= [ERROR] Took 47.44 seconds ============================================================= The terminal process terminated with exit code: 1
The board doesn't appear to have responded to the normal upload restart sequence. Does your board have two buttons on it, en and boot? You may need to hold boot or en while it boots up. You can connect the serial monitor and it should respond with entering download mode or similar with the right combo. I believe it is usually boot that needs to be held down while en acts like a reset button. Sent from my ONEPLUS A5010 using Tapatalk
Awesome! The EN is the reset. You have to hold down the Boot the entire build and upload cycle. So, push them both and hold the Boot while you upload. So now I just need to debug why it does not connect.. Backtrace: 0x4008d1cc:0x3ffbe410 0x4008d3fd:0x3ffbe430 0x400fcee4:0x3ffbe450 0x4008201d:0x3ffbe470 0x4016e517:0x00000000 Rebooting... ets Jun 8 2016 00:22:57 rst:0xc (SW_CPU_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 modeIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:928 ho 0 tail 12 room 4 load:0x40078000,len:9280 load:0x40080400,len:5860 entry 0x40080698 [DCCppESP32.cpp:187] setup(): DCC++ ESP starting up [DCCSignalGenerator.cpp:124] SignalGenerator(): [OPS] Configuring signal pin 19 [DCCSignalGenerator.cpp:124] SignalGenerator(): [PROG] Configuring signal pin 18 [WiFiInterface.cpp:158] begin(): WiFi details: HostnameCCpp32 MAC:B4:E6:2DE:41:81 SSID: GAMBLEHOUSE [WiFiInterface.cpp:161] begin(): Waiting for WiFi to connect [W][WiFiGeneric.cpp:357] _eventCallback(): Reason: 201 - NO_AP_FOUND [W][WiFiGeneric.cpp:357] _eventCallback(): Reason: 201 - NO_AP_FOUND [W][WiFiGeneric.cpp:357] _eventCallback(): Reason: 201 - NO_AP_FOUND [W][WiFiGeneric.cpp:357] _eventCallback(): Reason: 201 - NO_AP_FOUND [E][WiFiInterface.cpp:186] begin(): WiFI connect failed, restarting E (11377) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time: E (11377) task_wdt: - loopTask (CPU 1) E (11377) task_wdt: Tasks currently running: E (11377) task_wdt: CPU 0: IDLE0 E (11377) task_wdt: CPU 1: loopTask E (11377) task_wdt: Aborting. abort() was called at PC 0x400fcee4 on core 0 Backtrace: 0x4008d1cc:0x3ffbe410 0x4008d3fd:0x3ffbe430 0x400fcee4:0x3ffbe450 0x4008201d:0x3ffbe470 0x4016e517:0x00000000 Rebooting...
It looks like it doesn't like the SSID name. Take a look at the development branch as I put a wifi scan into it for this situation. You should only need to pull in WiFiInterface.cpp for that. Sent from my ONEPLUS A5010 using Tapatalk
Glad you sorted it out. It may be nicer if the error message was a bit more clear as to why the connection failed. I suspect the WiFi scan I've added to the development branch (soon to master for v1.2.1) would help narrow down the failure, especially if I add a check for SSID match, since we can possibly detect a password issue. I'll add this to the tracking list and try to get it implemented for v1.2.1 which I'd like to get out this week with the handful of fixes identified after v1.2.0. Sent from my ONEPLUS A5010 using Tapatalk
Yes, it is very cool. Thank you very much! With very little work I have the system up on WiFi talking to JMRI with a 0.96 OLED display and powering a BTS7960B. I had to disconnect the current sense line because there was an escalating over current value leading to a reboot cycle. I want to research it to see if I screwed up before asking for any help, but I get voltage to the tracks without the sense pin connected.
Be very careful on not having a current sense line connected. You have zero protection from the CS side to cut current when a short occurs. I didn't have much luck with the pair of BTS 7960 boards I have unfortunately, both of them emit a buzzing sound when active so I'm not sure what is going on exactly. I may dig into them again at some point but for now I'm ok with just the Arduino shield to power my staging yard and prog track (still need to set that up in staging) I also have a pile of L298 chips on the way so I can build a few booster PCBs. I haven't decided yet if it will be a pro mini driving it or an esp32. Either would be sufficient to drive it. Either option would work equally well for my setup since I can connect to LCC either way. Sent from my ONEPLUS A5010 using Tapatalk
No worries, it's all on the bench for now. I'm still in the learn and play mode. Tracking says my LMD18200s should be here today but unusable as the MAX471s are apparently on a row boat with the clone motor shields. I'd like to get the BTS working since that is my strongest alternative to the LMD. The way my layout is wired has a central power location (from driving with a DCS-100) with separate protected districts. An 8 amp BTS should run it just fine but I'd rather break it down to several LMDs so that if one main district goes down it is reported. The circuit breakers I have don't talk to anything, so if that function can move to the ESP32 it would be much better.
After a lot of research of forum posts, data sheets, etc. I believe I have it solved. It seems that the VCC is sensitive to low voltage and if you try to drive it with the enablement pin at 3.3 volts you risk dropping below the threshold and put the board in a fault state. The current sense has two modes. When in the fault mode it drives the output very high (over 2 volts). So I reworked my daughter card to separate pin 7 (VCC) from pins 3 and 4 (Enable). Seems to work as designed with the short circuit cutting power.
Despite some circuits out there, I'd suggest powering VCC and GND via dedicated power supply and use the ESP32 to only interface with enable/signal/sense pins. Is that for the BTS 7960 or LMD18200?
BTS 7960, my MAX417s haven't arrived yet. I got some other sensors but they're hall effect (ACS712) and output plus or minus on half of the VCC, so would not work with the current code. Sent from my SM-G920V using Tapatalk
ACS712 is not very reliable for the DCC signal since it is closer to AC than it is DC (polarity shifts). I wonder though if your finding is why I had problems with the BTS7960 buzzing when powered. I'll need to look at it more later...
I would run it on the DC input to the motorboard as I doubt the board drain would be significant to me. So, the latest is that I got it running an engine on a short test track. There was a 10 second lag from a loco command to the engine response. I could see the command in the monitor immediately after entering it in JMRI but the lag was consistent over many iterations, always being 10-12 seconds. I then went to try something else by hitting the F1 button on the JMRI throttle. It crashed the ESP32 and the engine went to full speed and crashed off my test track but the worst part is that JMRI won't start up now. and I have no idea how to clear it. I tried creating a new profile but still get this popup.
I haven't seen this or used the JMRI built in throttles. I'll add this to the to be tested list. Yikes, if you can setup a serial monitor to watch the console and capture the stackdump so it can be decoded and possibly fixed. As for JMRI, it looks like it corrupted the profile or settings but I'm not sure how/where.
