Thanks, you are correct that it should be a break. The DCCppESP32 base station only has the text based protocol which JMRI uses to communicate with it. The web interface for the base station is not a replacement for that but can also be used from a mobile device. Currently this base station does not have built-in support for WiThrottle but it is on the todo list. I just haven't had a chance to implement it yet.
I will look at what it would take to implement it either stand alone or sending it off to the web interface in a few weeks when I have time
I'll send you some references for it, I was planning on having it be done via AsyncTCP somehow but hadn't figured it all out yet. There are some features that will need to be further developed before the full support can be realized, mainly a loco roster. Sent from my ONEPLUS A5010 using Tapatalk
Follow up on Wifi Range: I soldered a larger wifi antenna to the antenna leads (little gold circles on the built in antenna). I soldered the antenna shielding to the ESP-WROOM-32 cover which is ground. The external antenna seemed to have no impact on device range. Not sure if there is a better place/way to attach the antenna. In case someone else has the same idea, it doesn’t work. So it looks like my options are one of the white ESP32 boards with a screen and antenna connector, or just get a network range extender for my garage. On another note, the TTGO ESP32 uno board is kind of a pain to reprogram after the initial flash is sent up. I just wanted to change index.html to include my most common decoder addresses. It looks like the smaller ESP32 boards have a boot button that is pressed during boot which puts it into a programming mode. GPIO0 and ground need to be jumpered. Then press the reset button, and the card will go into programming mode. Not only that, but you have to remove the old flash first before uploading the new one. Expressif makes a flashing tool that allows you to delete the old flash image so that a new one can be uploaded. https://www.espressif.com/en/products/hardware/esp32/resources The app is Windows based, and comes as a .rar file so you'll need something like 7-Zip to uncompress it. There is supposedly a Linux version of the app, but I didn't search around too much to find a trustworthy source. Once the old flash is gone, you can upload a new one, then remove the jumpers and hit the reset button. None of this seems to be well documented for this card, and much of the information out there for the ESP32 boards expects there to be a boot button which these uno boards don’t have. Am I missing something; is there an easier way? Matt
I have never had to do anything special to reflash the esp32 uno board or any of them really. Platform io and esptool handle all of the work for me. With the boards that have a boot and enable button (however it is labeled), you do need to hold the enable button down and press boot to have it enter flash mode. What this does is holds gpio 0 to gnd and gpio 2 to vcc ( or gnd, forget which off hand). With the esp32 uno board there are no buttons or needing to clean the board up before flashing again normally. For a better antenna version, look for an ipex antenna connection on the board, I found a few using the w-rover32 chip but not many in an easy to use form factor. The problem I see with the heltec boards that have an external antenna is that most of those antennas are for LoRA and not WiFi. Sent from my ONEPLUS A5010 using Tapatalk
This is one area the web interface needs to be improved upon. I am planning on implementing a roster list system on the base station (for WiThrottle as well) that can feed some info to the web interface or other throttle interfaces. One thing that will be needed for that is a long term storage plan, as we add more features to the base station we will run out of NVS space. I am considering adding SD Card support as a solution and moving all configuration to a text based file of some sort (not likely XML, maybe json?). With this approach it should be possible to reconfigure the base station with just the removal of the SD Card and a reboot of the esp32. Thoughts?
Hi, I wonder if you can help to shed some light. Every time I try to run a train on the main track, it moves a little then faults, I believe this is because it's detecting an over current. Wiring is simple right now. GPIO 19 TO PIN 12 (DIRA) GPIO 36 TO PIN A0 (Sense) GPIO 25 TO PIN 3 (PWMA) Motor board is a Deek Robot uno type shield. If I disconnect GPIO 36. It runs, but I lose voltage sense. If I wire up the program side, it reads and writes. Any ideas would be great. Thanks. James Sent from my SM-G955F using Tapatalk
How are you powering the Deek Robot shield? You should also provide 4-5V to AREF and IOREF on the Deek Robot shield. You also should have a common GND between all boards.
You cannot read CV's on the Main, only on the Programing Track. You can write CV's on the Main only. This is the NMRA standard.
Ah, I forgot to mention my power. I'm using common ground and I have 5v to the vin on the Deek Robot board and 5v in the ESP32. I didn't know about AREF and IOREF. I'll try those.
Sadly, I am getting the same after wiring AREF and IOREF to 5v. I'm not using any resistors to A0. Is that correct? Is it worth me measuring the actual load/ current using a multimeter? Sent from my SM-G955F using Tapatalk
No resistors are needed normally. In Config.h do you have things set as: Code: // MAIN TRACK MOTORBOARD MOTOR_BOARD_TYPE #define MOTORBOARD_TYPE_MAIN MOTOR_BOARD_TYPE::ARDUINO_SHIELD // PROG TRACK MOTORBOARD MOTOR_BOARD_TYPE #define MOTORBOARD_TYPE_PROG MOTOR_BOARD_TYPE::ARDUINO_SHIELD We have seen a few cases where the ESP32 reads the analog incorrectly and causes a fault condition when none really exists. You might also try adjusting this line in MotorBoard.cpp: Code: adc1_config_channel_atten(_senseChannel, ADC_ATTEN_DB_0); to: Code: adc1_config_channel_atten(_senseChannel, ADC_ATTEN_DB_6); or even ADC_ATTEN_DB_11. Also what is the version of the base station you are using? There was an overflow bug prior to v1.1.0 that caused the trigger current to be zero!
Voila. Well, possibly. I'm using v1.1.1 with the Heltec updates in the pull request. I haven't cloned from your latest branch but expect it to be the same. The Amps reading appears to be inconsistent watching the oled display and the updates to the web portal. Didn't work using 6, but 11 gives me the control I need. When using 11, the short protection continues to work. Thanks.
Just a thought. If this is happening more than once, is it worth adding an option to the config with some wording? If so, I can look to do this for you. James
Are you using a Heltic ESP32 with the built in OLED? If so, you may also want to update platformio.ini to list the board type as heltec_wifi_kit_32 or heltec_wifi_lora_32 depending on which variant you have. I think that would be a great option as you are not the first to encounter this, it might make sense to move up to ADC_ATTEN_DB_11 by default as well.
Yep, I'm using the heltec_wifi_kit_32 in platformio.ini. I'll look at making it configurable and adding a pull request for you. James
Thanks for all the help you have given me on getting my ESP32 up and running. I tried the upload method you say should work half a dozen times before I found the GPIO0 jumper trick. Then it would upload, and PlatformIO would say that everything uploaded fine, but after a reboot, the update wouldn't take. I had to clear the flash first. I either damaged the board soldering on the Wifi antenna or have a dud board. At least it works fine. I may try to get a replacement from another source and see if I have any better luck. A slightly better web interface or WiThrottle server built in would be an interesting feature. With IOS/Safari I couldn’t get the input box to come up to set a different address which is why I was editing index.HTML. I like the web interface as it is great for testing and setting up the system. With JMRI involved there are many other things that can go wrong. With the web interface, you know you have direct connection to the system. If I could eliminate the need for JMRI so that I can just run trains from my smartphone/tablet, that would be ideal. The SD card solution would solve the space issue and make for easier system changes, however few of the hardware options out there right now have an SD card slot. There arn't that many people who are willing to breadboard or solder a system together. Could the feature be added as an option, and will fall back on defaults if the SD card is missing? I don’t think the ideal hardware for this system is currently being made so you have to design the software for the hardware that readily available (and cheap). There are a few options out there when it comes to wanting to run trains from a smart device. DCC++ to JMRI, NEC Cab with USB interface to JMRI, Roco Z21, and Rokuhan e-Controller. DCC++ESP32 with the web interface is a really good option as is compared to the others as is and it cost less to build than a decoder. Compatibility with JMRI is bonus. You are defiantly going in the right direction with this development.
