On timer this was missing from the DEBUG output on the development branch. [DCCSignalGenerator_Timer.cpp:55] enable(): [OPS] Configuring Timer(1) for generating DCC Signal [DCCSignalGenerator_Timer.cpp:57] enable(): [OPS] Attaching interrupt handler to Timer(1) [DCCSignalGenerator_Timer.cpp:63] enable(): [OPS] Configuring alarm on Timer(1) to 58us [DCCSignalGenerator_Timer.cpp:65] enable(): [OPS] Setting load on Timer(1) to zero [DCCSignalGenerator_Timer.cpp:68] enable(): [OPS] Enabling alarm on Timer(1) When running the master branch, the OPS is working again (YES!) on the ESP32 Ardunio. Interestingly there is no current feedback given in the webdisplay. Is it suppose to? Still an issue with some core dumps appearing in the logfiles though. Seems to occur when switching the power on and off. [V][DCCSignalGenerator.cpp:70] loadPacket(): [OPS] queue: 14 / 498 [V][DCCSignGuru Meditation Error: Core 0 panic'ed (Interrupt wdt timeout on CPU0) Core 0 register dump: The prog however is still is not working, giving me current overloading warnings and core dumps. (FYI the motor connect is a small low voltage cd motor).
Mike: Is this part equivalent to what your TTGO is? This has a battery input and something to an external battery charger. https://www.ebay.com/itm/TTGO-T1-ES...e=STRK:MEBIDX:IT&_trksid=p2060353.m1438.l2649
Yes, that looks like the right one. You can get it cheaper here: https://www.aliexpress.com/item/TTG...h-SD-Card-Bord-4-woo woo woo/32846099054.html (this is the original manufacturer for this board).
The master code doesn't automatically refresh the status tab fields. You can collapse / expand them and it will refresh them. Do you have the rest of the stack from the WDT failure? specifically which task is not reporting to the WDT. I haven't seen any issues in this area in the past but it could be related to the verbose logging, I'd recommend using INFO level only for normal operations. On the development branch I've switched away from using the logging API provided by arduino-esp32 since it is not very fine grained and can lead to issues like you are showing here. When the power gets turned off, do you have any log entry which indicates the power usage? It should log the current draw just before it turns off track output. It is entirely possible the motor is drawing more current than expected if there is no load, but I'm not certain on this either.
I was only using the verose logging to see if I can track down why the prog side was not working. Though this might not be much use if it overloads the ESP32 when doing the actual logging. What logging are you using then in the development branch? I deleted this logfile so will run it again and see what I get logged and post back here.
I've shifted to using a compile time log macro instead which removes the need for the verbose output from the arduino-esp32 core code. As an example here is the output from my startup: Code: rst:0xc (SW_CPU_RESET),boot:0x13 (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 mode:DIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:928 ho 0 tail 12 room 4 load:0x40078000,len:8424 ho 0 tail 12 room 4 load:0x40080400,len:5880 entry 0x4008069c DCC++ESP32 v1.2.5 starting up [OPS] Configuring signal pin 19 [OPS] Configuring RMT-0 using pin 19 and bit timing: zero: 98uS, one: 58uS [PROG] Configuring signal pin 18 [PROG] Configuring RMT-1 using pin 18 and bit timing: zero: 98uS, one: 58uS [WiFi] WiFi details: Hostname:DCCpp32 MAC:30:AE:A4:C1:54:A8 SSID: TheHomeNet [WiFi] Waiting for WiFi to connect [WiFi] IP: 10.0.0.189 [WiFi] Adding dccpp.tcp service to mDNS advertiser Listening on port 2560, fd 54 [WiFi] Connected to TheHomeNet! [OPS] Configuring motor board [ADC1 Channel: 0, currentLimit: 3584, enablePin: 25] [PROG] Configuring motor board [ADC1 Channel: 3, currentLimit: 614, enablePin: 23] [Output] Initializing outputs [Config] Loading /DCCppESP32/outputs.json [Output] Found 0 outputs [Turnout] Initializing turnout list [Config] Loading /DCCppESP32/turnouts.json [Turnout] Found 0 turnouts [Sensors] Initializing sensors list [Config] Loading /DCCppESP32/sensors.json [Sensors] Found 0 sensors [Config] Loading /DCCppESP32/locoroster.json [Roster] Found 0 RosterEntries [Config] Loading /DCCppESP32/lococonsists.json [Consist] Found 0 Consists [E][vfs_api.cpp:135] remove(): /DCCppESP32/consists.json does not exists or is directory [Config] Storing /DCCppESP32/locoroster.json [Config] Storing /DCCppESP32/lococonsists.json DCC++ESP32 READY! I'm working on a few changes to the code on the development branch to fix a few issues in prep for the next release. Current known issues: 1) The RMT feeder task is causing bit mangling in the DCC signal due to processing being done inside this task rather than being done up-front. 2) LocomotiveManager::updateTask does not appear to be injecting the periodic packets as it is supposed to. This is manifested as only IDLE packets being sent out to the track. 3) Config is being reworked to make it more modular in nature. Right now locomotive state is stored in memory only and will need to be persisted and restored through restarts (requirement of LCC traction protocol), similarly roster entries and consists are stored in large files which need to be split to smaller files. It doesn't make sense to rewrite the entire file when only one entry in the roster/consist list is updated, it will also cause undue wear on the storage device. I'm also going to be adding a few config flags allow disabling of certain functionality (sensors and outputs mainly) since these may not be needed by everyone and with the new PCB with LCC support these will not need to be maintained by the CS.
I ran the system for a bit. From the logfile: [MotorBoard.cpp:58] powerOff(): [OPS] Disabling DCC Signal [MotorBoard.cpp:58] powerOff(): [PROG] Disabling DCC Signal [DCCSignalGenerator_Timer.cpp:73] disable(): [OPS] Shutting down Timer(1) [V][DCCSignalGenerator.cpp:70] loadPacket(): [OPS] queue: 14 / 498 [V][DCCSignalGenerator.cpp:70] loadPacket(): Guru Meditation Error: Core 0 panic'ed (Interrupt wdt timeout on CPU0) This occurs when the power is switch off and repeats every time. Though I cannot say if is down to having the verbose logging causing it to panic. Additionally the PROG is now working, which seems odd considering nothing has changed from earlier and it was definitely not working.
That is very odd. I doubt it is related to the track power being turned off but I'll do some digging. Even more puzzling that PROG wasn't working previously but now does.. --- And an update on the development branch, the following items are currently blocking for the next release: LocomotiveManager failing to send DCC update packets every ~50ms. RMT based DCC signal mangling. This appears to be due to two areas of code: preamble being skipped in the generated packet (default is 22 bits which is needed for PROG but not OPS) time taken to fetch and convert a packet from raw bytes to RMT data roster.json and consist.json need to be split into individual files rather than one monolithic file. I've got a fix already for #1 and I'm working on fine tuning it further. #2 I have a partial fix for but I don't like it so it is being reworked further to minimize the translation layer from bytes to RMT data. --- And an update on the PCB status, I'm reworking the schematic to replace the L298 h-bridge with a pair of LMD18200 h-bridge chips as well as working out the necessary parts for RailCom detection. The primary shift from the L298 to LMD18200 is to switch from low-side current sense to high-side current sense, the secondary reason is to use a hardware solution to lock the PROG track output to a max of 250mA current without impacting the OPS track output (the L298 only has one Vs pin used for all four output pins so it is not possible to limit this to 250mA). I'm hoping to have the circuit and PCB ready for review by a few people in the next week or so and ordering PCBs/parts next month. Current price point is still around $20 with all components being through-hole design, I'm considering an SMD component PCB which will allow a bit more flexibility in design (more options on components!) but haven't settled on this yet.
Yes this not working then working without changing anything is really frustrating me. Will be interesting to see what luck I have with the next version. The PCB price point with all componets looks really good, though the way the British Pound is dropping it is going up each day.
Very true, this is something even I'm facing in the cost side. The price for the TTGO-T1 board has gone from $5 USD to $6.19 with shipping cost nearly doubled. Due to this I'm very much considering the ESP32 WROOM32-U or WROVER32-U (UFL/IPEX connector) as these are around $3.50 USD and would require only small adjustments to the PCB (add a 3v3 linear regulator off the 5V supply as there are a few 5V components) and add an SD card adapter (approx $0.45 USD) which will also require 3v3. I'm leaning towards the WROVER32-U which also gives 4MB or 8MB PSRAM, I don't have a specific need for this at this time though.
Yes, it is proving to be a bit of an easier chip to work with since I don't need to split the signal. As an added bonus, it is 3A vs 2A!
With using a WROVER32-U you can have an external aerial if you put the PCB in a case. Would look nice and tidy. I may have missed this but why do you need a SD adaptor for, is this instead of the usb for uploading the software?
Yeah, that is one of the nice things with the TTGO-T1 board, it has the IPEX connector on the PCB and does work nicely for this purpose. I do plan on putting the CS in a case of some sort but need to sort out the PCB side of it and exposing the connections so they can be done with a case. The SD usage will be optional but highly recommended for long term stability, especially with the upcoming LCC Traction Spec integration. The primary reasons for this are around how SPIFFS is designed/implemented, it uses one large blob for all file data and the file entry table. If you modify one file entry, it potentially will rewrite the entire SPIFFS blob leading to longer delays. On the ESP32 when accessing the built-in flash via the spi_flash module (the only access model) there are restrictions on operations that are possible during flash access (read or write). As an example, the hardware timer based DCC signal generation *WILL* cause the ESP32 to crash if you attempt to clear/persist configuration data while track is energized (there are code guards in place to prevent this specific crash), this same crash can be observed by enabling LCC and reading the CDI while track is energized (there is no way to guard for this one). This is partially why I'm shifting to the RMT instead of the hardware timer for the DCC signal generation, the other reason being accuracy. Another recent problem reported for the hardware timer callbacks was a crash by calling millis() within an IRAM_ATTR tagged callback, adding to the frustration was that micros() worked. Have fun finding the problem, it likely isn't what you might think it is A fix for this is in arduino-esp32 1.0.3-rc1. This also doesn't impact DCC++ESP32 that I'm aware of.
I need to have a look at the LCC Specs. It has been twenty odd years since I was doing this and there is a lot of new and interesting new technology (and its seems competing specs) out there now. It is now a matter of trying to work out what all of it does and if I need it any of it. Having to work around all these ESP32 "features", reminds me in the late nineties I spent quite a bit of time compiling linux kernels and other associated software and that was really frustrating at times. Especially when it turns out to be something which appears to be completely unrelated and undocumented causing the issue! Many hours wasted on mailing lists. At the moment I cannot offer you much help with the debugging other than reporting stuff I see. I am still in the early days of learning this platform. I was using building the wireless handheld idea as a way of getting some hands on using EPS32 platform. Though I do wonder if I am going to have the same issues with the hardware working only when it wants to.
The specs can be a challenge to digest, I'd suggest taking a look at https://openlcb.org/ (specifically some of the tutorial pieces under Knowledge Base). LCC is similar to LocoNet or XpressNet in that it controls everything *EXCEPT* the DCC decoders (but that will be supported via the Traction Protocol, at least from a throttles perspective). Yes, there have been an unfortunately high number of these "features" built into the ESP32 hardware and software. I'm still learning a lot of aspects of it after about two years! The biggest challenge for handheld throttles and the like will be connectivity to the rest of the network. We do have a Nextion WiFi throttle which I will be releasing alongside the next CS release. It wouldn't be too hard to update https://github.com/atanisoft/DCCThrottle to be usable again, I mostly discontinued it due to shifting to a new architecture. I still have one of these sitting in a parts drawer as well as a couple new enclosures that I decided not to use.
Thought I'd share a small update as I've been quiet for a little while and quite busy... v1.3.0-rc2 is available now! This is a major update from the 1.2.3 release and brings in a lot of fixes and very likely a number of bugs. I haven't marked this as a "final" release as I want to get a bit more testing in by users with different configurations etc. I've tested what I can and it all seems to work as expected but there are likely a few bugs lingering still. I've also started working on v1.4.0 which will be another MAJOR update, with v1.4.0 LCC will be enabled by default for WiFi and become a mandatory component, this is necessary to support the LCC Traction Protocol used by the TCS Throttle (coming soon!) and to streamline a lot of the CS code. Current timeline for v1.4.0 is looking to be around late September or October as there are a number of changes coming with the shift to using LCC components for many aspects. Also coupled with v1.4.0 will be this PCB kit: This is the v1.0 board and almost all components (missing a few caps and resistors). With this kit, the ESP32 Command Station will have built-in LCC-CAN (top right of board), RailCom (center area of board), built in power supply (lower left), status LEDs (lower right), 3Amp OPS track output (near top left), 250mA PROG output (near top center). All on one board that is mostly plug-and-play! Partially assembled board: This will give a better idea of where some of the components can be found... The PCB will support a few extensions: Nextion interface OLED/LCD display LocoNet via daughter board JTAG debugging Note that the Nextion and LocoNet interfaces can not be used simultaneously since they will share the same UART. More to come on the PCB kit as I complete testing..
Since I don't have a TTG0 version of the ESP32, I was surprised to see the pigtail and antenna for the wireless stuff. Seems to me that you really don't need to include the ESP32 module OR antenna stuff in your kits, especially since you have the option of using the DEV board or the TTG0 based part. That should keep the kit price down where you wanted it to be. I'm ready for one of the kits as soon as you are ready to let them ship. Obviously, I don't need the TTG0 or antenna. Also, I'll be testing functionality with the DEV ESP32 part. I don't expect to use much of the extra stuff you've allowed for on the CS(having them included is great), at least not initially. I'll be concentrating on engineering my expansion to your CS. I'm impressed with your HW/design abilities, especially since you're primarily a SW person. That's one hell of a compliment from a retired EE.
The price on the TTGO-T1 with antenna & pigtail is ~$7 USD, so it's not a huge savings but I can certainly accommodate that as part of the kit Since you plan on using the DevKit-C board it'll need to be the next revision of the PCB as the footprint for the DevKit-C is just barely too wide for the module to fit easily. I'll be fixing this along with a few other clearance issues on v1.1 which I'll be submitting for manufacturing in about a week. That is one benefit of having it all available out-of-box, you can start simple and expand from there. One area I'd highly recommend using is the SD support (for DevKit-C 6 pin header to the left of the LEDs) as the SPIFF FS is pretty slow and will over time cause undue wear on the flash (even with wear leveling). Thanks! I can't take all of the credit on the schematic as some of it was inspired/borrowed from commercial designs but the PCB layout is 100% original and ever evolving.
