Hello trainboard. wanted to pick collective brain with issue I encountered. what works: JMRI has connectivity to IBT-2/Arduino DCC++ base station. I was able to run trains directly from JMRI as well as WiThrottle. I Built ESP32 DCC++(latest prod version), established connection to it via wifi, verified correct pin setting and construction of transistor signal split circuit - trains run, response to throttle input are without perceived delay. What doesn't work. PC and JMRI do see the ESP32 board on COM7 and board powers up. in JMRI however (configured to serial com) the track power button/indicator stays in the unknown state, locomotives will not respond to the throttle input. DCC++ monitor sees commands issued by throttle with significant delay. unplugging the USB causes the loco to lurch forward full speed for about a second, while red status line of unreachable COM7 annunciated in JMRI main window. Additional symptoms OLED on the ESP32 controller is not fully refreshed when connecting to serial - this makes me suspect some sort of issue with the port. when working with Arduino DCC++ base station (on COM6), connection will fail if I plug Digitrax PR3 . JMRI still sees base station connected, but DCC++ monitor again shows throttle commands with significant delay - again, this makes me suspect some sort of issue with the port. steps taken to diagnose: behavior above is not limited to specific hardware USB port. tried different cable as well as using USB hub. forced update drivers (CP210x USB to UART Bridge VCP Driver). no issue with other peripherals noted Question: any idea on source of the issue or how to remediate? (win10, i5 43xx) thanks! PS, Mike atanisoft, many thanks for your great work with ESP32 !
Successfully recreating the issue on different machine was a hint. Walking through code (to the best of my abilities) I found nothing that looks like serial communication so it looks like all of the above is working as designed. I assumed ESP32CS would communicate over serial, I guess Wifi being mandatory module should have been the que. I probably can live with connection over wifi. with that i found that all locomotives that are on track on occasion can suddenly lurch full speed forward for about a second. it looks like brief interruption of JMRI->ESP32CS connection after which things resume to work normal. what part of the code can cause this? any idea how to remediate?
I would advise sticking with the version v1.2.3 of ESP32 CS for now. There are known issues with "master" that I will not be fixing. I'm working on the "development" branch currently where things are still in a state of flux as I stabilize the functionality. Which motor shield and ESP32 are you using? There has never been any support or intention to support the legacy DCC++ protocols over serial with ESP32 CS. In fact, with v1.5.0 it will be not be the recommended approach for connecting from JMRI. The primary protocol going forward will be LCC (OpenLCB) and DCC++ will be maintained only for legacy support and functionality will be very limited with some features not being supported at all.
Thanks Mike. board is Lolin with OLED, motor controller is IBT-2 (used the 10A in the config) I will revert back to 1.2.3 for now, looking forward to see what 1.5.0 brings (no rush)
That should be a decent ESP32, the only downside is the lack of usable pins being exposed. That shouldn't be a problem though for most usages. Keep in mind pins 34-39 are input only. The two of these that I was using for testing both have some sort of issues now (high pitch whine and no signal reaching the outputs, haven't been able to sort it out yet). If you haven't figured out the wiring you can follow the settings here. The only thing you will need for v1.2.3 is to include this fix. v1.5.0 should be ready to go in a few weeks, there are a few lingering issues to fix but for basic use cases is more or less stable. The biggest issue with v1.5.0 currently is documentation for how to build the code since it will not build with PIO since they do not yet support ESP-IDF v4 and I do not anticipate support anytime soon.
I did not know that. but I do not intend to pile up much more functionality on board. the documentation you created was very helpful. I did change the signal pin used however. as for whine and no signal interestingly enough I think that what I experienced when I used the 5A in the config "#define MOTORBOARD_TYPE_OPS BTS7960B_5A" changing the config to "10A" resolved that issue for me. not sure at all why , perhaps we are talking different issues. i'm not heavily entrenched with PIO and don't have strong feelings about one IDE vs another. will use whatever the requirements tell me to use again, thanks for your efforts!
I noticed an issue in my post, it showed 3-39 are INPUT... that should have read 34-39 ... I think I tried that but wasn't successful in silencing it myself. I've heard others have the same issue with higher frequency signals (like DCC) so I opted to retest in the future after fixing other issues that were more pressing. I haven't gone back to re-test at this point yet but it should work all the same. With ESP-IDF there will be two ways to build: 1. Commandline utilities 2. Espressif IDF plugin for VSCode or similar plugin for Eclipse IDE. I'm currently testing with both of these and finding that they work but the builds are considerably slower with ESP-IDF vs PIO. A "clean" build takes roughly 23 minutes vs around 5mins, I haven't fully isolated why it is so much slower but from the files that are showing as taking longer it looks like it may be related to a missing compiler flag but I haven't confirmed that yet.
