Hi, what a delight to see that DCC is still very much alive thanks to devoted people like you Atani. I have been following this project for a while and now I want to join in with my esp32 (dev kit v1 ESP wroom 32) finaly arriving in the mail. After toying with PlatformIO for about an hour and setting up motor shield pins (Deek-robot arduino shield), wifi address, etc. I uploaded the code and started testing. Here is my observations: - When using the browser based interface the DCC track signal is only activated when I press the "All Districts" button, otherwise only the enable pin will activate (pull high) I tried looking in the serial output for clues: pressing the per track power button: [MotorBoard.cpp:46] powerOn(): [OPS] Enabling DCC Signal pressing the "All Districts" button: [MotorBoard.cpp:172] powerOnAll(): Enabling DCC Signal for all boards [MotorBoard.cpp:46] powerOn(): [OPS] Enabling DCC Signal [DCCSignalGenerator.cpp:151] startSignal(): [OPS] Adding reset packet (25 repeats) to packet queue [DCCSignalGenerator.cpp:154] startSignal(): [OPS] Adding idle packet to packet queue -In jmri: pressing the power button turns on track power but it will intermidiantly cut out by itself (track current meter reads about 20%) -In both the web interface and jmri the I can control locomotives with the throttle, but the function buttons doesn't work. In the web interface there's no reaction at all and in jmri some functions seem to work but not on the function butten assigned for them. I have tried both the MASTER build and the newest DEVELOPMENT build. Here is how I configured the motor shield: Code: // MAIN TRACK MOTORBOARD NAME #define MOTORBOARD_NAME_OPS "OPS" // MAIN TRACK NOTORBOARD ENABLED PIN #define MOTORBOARD_ENABLE_PIN_OPS 27 // MAIN TRACK MOTORBOARD CURRENT SENSE ADC PIN #define MOTORBOARD_CURRENT_SENSE_OPS ADC1_CHANNEL_5 // MAIN TRACK MOTORBOARD MOTOR_BOARD_TYPE #define MOTORBOARD_TYPE_OPS ARDUINO_SHIELD // PROG TRACK MOTORBOARD NAME #define MOTORBOARD_NAME_PROG "PROG" // PROG TRACK NOTORBOARD ENABLED PIN #define MOTORBOARD_ENABLE_PIN_PROG 25 // PROG TRACK MOTORBOARD CURRENT SENSE ADC PIN #define MOTORBOARD_CURRENT_SENSE_PROG ADC1_CHANNEL_4 // PROG TRACK MOTORBOARD MOTOR_BOARD_TYPE #define MOTORBOARD_TYPE_PROG ARDUINO_SHIELD ///////////////////////////////////////////////////////////////////////////////////// // // DEFINE WHICH PINS ARE USED FOR DCC SIGNAL GENERATION // // OPERATIONS TRACK DCC SIGNAL PIN #define DCC_SIGNAL_PIN_OPERATIONS 14 // PROGRAMMING TRACK DCC SIGNAL PIN #define DCC_SIGNAL_PIN_PROGRAMMING 26 ///////////////////////////////////////////////////////////////////////////////////// // // DEFINE THE CURRENT SENSE ATTENUATION. THIS IS USED BY THE ADC SYSTEM TO SCALE // THE CURRENT SENSE VALUES BASED ON THE MOTOR SHIELD. // // SUPPORTED VALUES: ADC_ATTEN_DB_11, ADC_ATTEN_DB_6, ADC_ATTEN_DB_2_5, ADC_ATTEN_DB_0 // // IF LEFT UNDEFINED ADC_ATTEN_DB_11 WILL BE USED. #define ADC_CURRENT_ATTENUATION ADC_ATTEN_DB_6 ///////////////////////////////////////////////////////////////////////////////////// Am I the only one having these issues? Hope we can shed some light this. Best regards Kim
Welcome to the fun! There are a number of projects I'm working on with the ESP32 CS code to extend it's functionality and correct a few inconsistencies with the standards. This is expected behavior. The programming track will only be active when it is in use. This very likely is due to overriding the value for ADC_CURRENT_ATTENUATION. The serial output from the ESP32 should yield a few more clues. The track current meter in JMRI may not entirely accurate when it comes to DCC+ESP32 as the current value range in JMRI is based on 0-1023 (AVR range) and the ESP32 supports 0-4095. I'll make a note of this and see if I can find a solution for this. I'd recommend not overriding the ADC_CURRENT_ATTENUATION as it could lead to false positive "short" detections. When the loco is "active" (on a throttle etc) if you set a function it should print something to the serial output of the ESP32, if you don't see anything when toggling a function that would indicate an issue in setting the function. There have been a few reports of delays in activating a function via the web interface and I'm looking at how to improve that still. From JMRI though it should be almost immediately reflected in the console. You might also check the JMRI DCC++ traffic monitor for clues.
Thanks for the fast reply! Hmm when I activate the track current meter in jmri this is shown in the DCC++ traffic monitor in jmri: Code: Status Cmd Base Station Status: Version: 1.3.0 Build: Mar 8 2019 16:37:21 Power Status: Name:OPS Status:ON Current: 108 / 1024 Power Status: Name:PROG Status:OFF Comm Type Reply Type: 1 Port: 192.168.8.65 Nothing is shown in the serial monitor in VSC PlatformIO, I verified that I still had a link by cycling power. Another thing I noticed, is that the power isn't actually cut. By looking at the shield diodes and I can see that track power is still active and I can still control the train, it is only the jmri power button that switches to red. It does this when this line is shown in the traffic monitor: Comm Type Reply Type: 1 Port: 192.168.8.65 Looking in the JMRI DCC++ traffic monitor everything seems to do what it's supposed to when I try to turn on F1 on address 3: Code: Function Cmd: Address: 3 Byte 1: 129 Byte 2: null (No Reply Expected) But again nothing is displayed in the serial monitor in PlatformIO. Is something going wrong when I compile the code? Modules missing or something?
That would be a bug likely, JMRI is toggling to RED as the PROG track is being reported as OFF. Please log an issue on https://github.com/atanisoft/DCCppESP32. I'll try and get it pulled in for v1.3.0 which I'm looking at pushing out later this month. I'll do some testing to check what might be going on here. It should be printing something when the packet is sent from JMRI to the CS. It is possible there is a bug here still.
Here is an interesting post... Might be adaptable to ESP32 as a motherboard multi district motor driver. https://www.trainboard.com/highball/index.php?threads/lm311-h-bridge-driver.123857/
Certainly interesting but I'm not certain on its usability. I'll leave that decision to those who would want/need this sort of higher density of power districts to be managed by the ESP32. In most cases I don't see this being necessary, especially with the ability to add an LCC DCC booster via an RJ45 cable (more details coming soon!)
Mike, There are 3 things he posted on his web page (https://dcc.wraith.sf.ca.us//), two of which you may find applicable to your vision. 1) a 'buffer' shield - it supports connections to 4 power districts but I am wondering if the 'buffer' function adds some value 2) a roll your own motor driver which I think might be interesting (though I think you have your own coming) in that you can drop in the power transistor pairs you need. He noted several, one having an 8A rating. I continue to have issues with IBT-2 and it may just be an unreliable module. There are many cases of people having multiple modules where some work and some don't. It may be the module, the interface, or the chip sensitivity. Some report it as reliable. I will play around with it some more but may have to abandon it. Maybe I have a bad one. 3) a nano based pseudo locomotive for testing. Given my runaway locomotive and reaction delays, this is an attractive test bench load. I can see some value in being able to customize and monitor the receiving end. Just my thoughts.
I'm having the same problems with both the master and development branch. JMRI says power is off when it is not. Also, for me the function commands aren't working at all. This is true with the web interface or through JMRI. When toggling functions from JMRI I get the same output from the traffic monitor as above, but no action on the locomotive. When I try it through the web interface, I don't see anything in the JMRI traffic monitor. Also, looking at the HTML/CSS code for the web interface, there are a bunch of scripts, and the CSS stylesheet that are linked to external sources, rather than embedded. This inadvertently requires internet access for the DCC system. This is likely not an issue for home use, but might be a problem for people at shows or meets. Matt
This is the way it is for now and for the near future it won't be changing unfortunately. A bit of work will be done on the web interface to move the data to locally hosted but that is not ready yet. A fix will be coming soon on the development branch, this is not a real bug but more of JMRI reacting to the multiple track outputs (PROG and OPS) having different states (PROG is always OFF unless in active use, OPS will be on whenever JMRI requests track power ON). I'm going to exclude PROG from being reported in the next release to fix this. This sounds like the web interface is not sending the command to the CS correctly. I'll do some more digging into this and see if I can find the cause.
Hope it is an easy fix. I took a small break from DCC++ , and just recently updated from a year old Master version. I really like the changes made to the web interface. Especially its ability to store a locomotive table. It's very close to being a stand alone system. Really good work!
I'm hoping it is the same. I've seen a few cases where the web interface sends a request but it doesn't get processed right away or at all at times. It is on my tracking list to narrow down where it is happening. I'm hoping this is not the case here as that is going to be a lot harder to fix easily. I'm hoping it is something simple like an event not being raised etc. This can be confirmed in the JS console in the browser as it should print a message for functions or other throttle commands at the same time as sending it to the CS. Long term, My current thinking is switch to a hybrid model of http requests for bulk load and use a websocket for interactive commands (functions, throttle speeds, etc) so that it is reflected sooner. I'm still working on addressing a couple performance issues that snuck in. Also for the roster etc, be sure to save the config when you are done. You can find a button for that on the first status section. I'm looking to remove the need to persist config in an upcoming release as it won't be necessary to delay this sort of persistence, currently this is necessary due to the DCC signal generation being done with a hardware timer. Sent from my ONEPLUS A5010 using Tapatalk
Update on last night's testing. I got JMRI working again reverting to saved profiles but in playing around with it I think it may be more of a connection issue with the ESP32. I get it to connect after a connection failure simply by rebooting the ESP32. I have also noted the power on / off button issue. I had just been clicking on it in JMRI until I got the state I needed on the base station. I also have noted that the F buttons on the JMRI throttle do not generate any output on the ESP32 monitor. On the runaway loco, I think the decoder is either fried or corrupted. All it will do now is flash the headlight on and off. I tried to reprogram it but did not have any success, though it was my first attempt with the programming track, so I have to do more work here and try it with a known good decoder. The BTS7960B drives a fresh loco just fine. I continued to have the 10 second lag and then it magically went away... I don't think I did anything but haven't seen the lag come back. I am going to shelve the BTS7960B for now as my other parts arrived and I don't want to spend a lot of time on possibly bad hardware. I have hooked up the LMD18200 / MAX471 on ops and it works just fine. I had it set as the BTS7960 so it took a good short to shut down but it did. I'll next get into defining it properly so that current sense has the right calibration and try out the programming track.
Yikes, sorry to hear about the possible fried decoder. When you say that the F buttons do not generate any output on the ESP32 monitor, does this mean that the functions work on the loco, just not the monitor? If so what brand of decoders are you using? I'm using ESU decorders. Best regards Kim
Kim, no, the functions don't work on the loco either. I should have specified that but I believed that if the JMRI command was not showing on the base station monitor then it would not be getting onto the track. All my locos have 15+ year old Digitrax decoders. I am just getting back into it after other priorities and haven't upgraded anything yet. I want to get the infrastructure where I want it before I worry about rolling stock, though if I keep frying things I may be forced to buy a few decoders. I think I am going to build a bench test decoder from a nano so that I can monitor the incoming commands. This should alleviate some of my frustrations.
I'll be digging into the functions issue shortly, just have a couple higher priority tasks that I need to take care of first (non trains related). I'm hoping to have this issue fixed up in the next couple days though.
Hello Mike, I've installed your version 1.2.0 (on a new ESP32 EzSBC board) and must admit you have added a tremendous amount of flexibility to DCC++esp32, I appreciate your hard work on this. I have the OLED in operation but the Nextion 3.2" enhanced display is giving me a bit of grief. I've loaded the s/w to the display but am unable to connect it to the esp32 (using serial comm IO14 and IO27), the serial monitor indicates ([E][NextionInterface.cpp:114] nextionInterfaceInit(): Nextion init failed). I've tried looking at the serial output of the esp32 via PuTTY and I can see (bkcmd=1 page_0) after an esp32 reset. The display only shows the base page (DCC++ ESP32 0.0.0). Is there something I'm missing on setting up the Nextion display...? Any help or guidance on this would be helpful. Best Regards, Paul
It sounds like the esp32 is failing to talk to the Nextion screen, you might need to swap the RX/TX pins. You might also try the development branch which has a few modifications to the Nextion interface to improve the init process a bit. As for the reset, that sounds like it either failed to connect to WiFi or it had another type of failure, do you have more info on that?
As Mike indicated .... I found that swapping 14/27 either in the code or physically will rectify connection to Nextion.
Thanks for the prompt response Mike and esfeld. I've tried swapping the Rx and Tx, also swapped the pins def's 14 and 27 in Config_Nextion.h file, even changed to UART 1 (rather than 2), all with no luck (ie I believe I'be tried all combinations...). I've checked the GitHub dev branch but could not find anything regarding connecting to the Nextion. Note: the PuTTY serial monitor gives the following when connected to pins 14/27 (UART 2) and a reset is made: ▒▒▒bkcmd=1▒▒▒page 0▒▒▒ not sure what the gibberish is, but it appears it's trying to talk to the Nextion.... so I think the Rx and Tx connections are ok. Here's the start-up info from the PlatformIO serial monitor: rst:0x1 (POWERON_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 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 [E][NextionInterface.cpp:114] nextionInterfaceInit(): Nextion init failed [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:********** SSID: ********** [WiFiInterface.cpp:161] begin(): Waiting for WiFi to connect [WiFiInterface.cpp:123] operator()(): WiFi IP: 192.168.0.161 [WiFiInterface.cpp:128] operator()(): Adding dccpp.tcp service to mDNS advertiser [WiFiInterface.cpp:189] begin(): WiFi connected! [MotorBoard.cpp:42] GenericMotorBoard(): [OPS] Configuring motor board [ADC1 Channel: 0, currentLimit: 3584, enablePin: 25] [MotorBoard.cpp:42] GenericMotorBoard(): [PROG] Configuring motor board [ADC1 Channel: 3, currentLimit: 614, enablePin: 23] [ConfigurationManager.cpp:127] load(): Loading /DCCppESP32/outputs.json [ConfigurationManager.cpp:127] load(): Loading /DCCppESP32/turnouts.json [ConfigurationManager.cpp:127] load(): Loading /DCCppESP32/sensors.json [ConfigurationManager.cpp:127] load(): Loading /DCCppESP32/roster.json [ConfigurationManager.cpp:127] load(): Loading /DCCppESP32/consists.json [DCCppESP32.cpp:392] setup(): DCC++ESP32 READY! It appears all's ok except for the Nextion .... the OLED and WebBrowser interface appear to be working well. Best Regards, Paul
