Regarding SDA/SCL... yeah we discussed that further up, maybe on page 3? I specified pins 5/4 in their place, specified OLED_CHIPSET SH1306, and for my purposes set the screen flip to true. With those settings the display came right up. For the inverter logic I'm using a 3904 transistor which is practically identical to the 2222 for our purposes. I haven't looked at the specs, but one of them may be faster than the other. I think for the speeds we're working with it doesn't really matter. I'll try connecting my BTS7960 Vcc to the 5v line tonight and see if there is any difference, however that supply is only driving the logic portion of the H-bridge so we should only see a draw in the very low mA region. Also note that on the trainelectronics site he was also using the enable line to connect to Vcc on the BTS board (although that was probably a 5v signal from the arduino) and didn't see any problems with it, so we do have some examples showing that Vcc has a very low current draw. One thing I *can* confirm... when I first hooked up the BTS and was testing the auto-shutoff by shorting out the rails, despite not actually turning off power the ESP did *not* reboot, so it appears to be fairly well isolated from anything happening on the BTS.
I have a bunch of those as well. I didn't have much luck with them for the circuit I was using them in (unrelated to BTS7960) but plan on retesting with them for LED lighting (switch indicator, signals, etc) It would be good to know how much if possible. According to the datasheet it should be in very low mA (10-20mA). But even with that said, we don't want to run too high of a current through the ESP32. I couldn't find an exact number for the max current draw on a pin but there was reference to 40mA for VDD_SDIO so that could be in the general range.
For the Lolin (and probably for any others with a built-in USB port), the 5V supply pin likely comes directly off of the USB and is only limited by what your USB source can supply -- even in the worst case connecting through a computer you should have at least 500mA available. Of course I don't have a schematic of the Lolin board to verify that, but if I get a chance I'll hook my meter between the Lolin and BTS and see what the draw is. 40mA sounds about right, I seem to recall reading that in other threads when people were asking about driving 20-30mA LEDs.
Quick update -- switching to the 5v source made no difference on getting power to the track. Also keeping in mind that I *did* have power to the track using the enable line as a power source with the previous code. Power draw raises some questions, as it seems to hit around 50mA (highest was 55mA) when you first turn everything on, but then drops and holds at 13mA. I'll have to recheck with the previous code just to see what kind of draw we get when power is actually being fed to the tracks. Since I'm pretty sure the I/O pins can't actually supply 50mA (or at least they shouldn't be able to?) I'm not sure if my meter is reading accurately or just reacting to the sudden power as I plug everything in. It's a cheap meter, but I do see the same results when I leave the 16V supply plugged in and only switch the ESP power. At least it gives you something to compare with when you get your setup running.
I believe this is to be expected, when you first power a device it will have a significantly higher draw than the sustained draw. With the drop and hold around 13mA that seems pretty close to what the spec suggests so that is likely accurate enough. I agree that the pins shouldn't sustain a 50mA draw for very long, but a short spike during startup may not be a huge problem. This may also go away by using the ENABLE pin to power the BTS chip since the default state for ENABLE is LOW (I am considering making this behavior configurable via Config.h in the future) I have a couple rather inexpensive meters myself, they are usually close enough for most purposes. there are times that accuracy is certainly needed though, this I don't believe is one yet. We are mostly after a rough estimate at this point.
That made me think -- I went back a measured again coming off the enable pin and see much different results. No spike at all during power-up, as you suggested, and when I enable track power the draw only goes to 2mA. I rechecked it a couple times, and still only see 2mA. Not sure why there's such a difference between the 5v and 3.3v source for powering the H-bridge logic?
Interesting. I wouldn't expect a wide difference between the two. Another option is to wire vcc to 5v and gnd to an npn via enable. We can check the specs to confirm the BTS can be safely run at 3.3v as well. Sent from my ONEPLUS A5010 using Tapatalk
I received a second Lolin32 last week and have been working on another project for a greenhouse monitor. Yesterday I dove in to learning how to work with the ADC ports on the ESP32 and finally got a simple photoresistor set up to show ambient light. Completely unrelated to this DCC project except for one thing -- since I seem to be having troubles with the track current input I wanted to verify whether or not I was even using the right pin definition. I'm happy to say that the pin marked as SVP on this board does in fact correspond to ADC1_CHANNEL_0, as I had previously defined in Config.h. At least that eliminates one possibility for why it might not be working.
@Atani -- I was going to ask if anyone had seen you lately, but I see you liked my previous post. Have you have any chance to test the latest code and see if it also signals faults for you? I was thinking maybe I should try reloading the previous code version and see if I can get track power back again with the new H-bridge board.
Sorry have been quite busy lately with work and not spending as much time on the trains. I have not had a chance to test with the BTS7960, it is still sitting on my desk ready to hook up though. If you can grab the code from this branch: https://github.com/atanisoft/DCCppESP32/tree/s88 it is the very latest and will be the next release. A huge thanks to @NormHal for helping test the new features and provide a bunch of valuable feedback. By using this branch of the code you will be able to verify if the issue has been fixed already or if there is still an issue still to be resolved. If possible please provide the serial console output from testing as there is a lot of diagnostic data being written there at runtime.
No problems, I figured something was up. I'm waiting on parts again for the greenhouse project, but I have received the opto-isolator chips and the servo controller board so I'm ready to jump back into train projects again. I also have some NFC stickers and an antenna board I want to play with to see if it can actually read the stickers from moving cars. I'll grab your code tonight and get it loaded up, should be quick enough to see if I'm getting power to the tracks again, and once past that I can set up another board to read track signals and try to control the servos.
Well it's not looking good so far... Arduino: 1.8.5 (Linux), Board: "WEMOS LOLIN32, 80MHz, 921600" Archiving built core (caching) in: /tmp/arduino_cache_450201/core/core_espressif_esp32_lolin32_FlashFreq_80,UploadSpeed_921600_35ab4bb27712f864f720844190c5c90e.a sketch/DCCppESP32.cpp.o.bss.configStore+0x0): multiple definition of `configStore' sketch/DCCppESP32-s88.ino.cpp.o.bss.configStore+0x0): first defined here sketch/DCCppESP32.cpp.o.bss.wifiInterface+0x0): multiple definition of `wifiInterface' sketch/DCCppESP32-s88.ino.cpp.o.bss.wifiInterface+0x0): first defined here sketch/DCCppESP32.cpp.o: In function `setup()': DCCppESP32.cpp.text._Z5setupv+0x0): multiple definition of `setup()' sketch/DCCppESP32-s88.ino.cpp.oCCppESP32-s88.ino.cpp.text._Z5setupv+0x0): first defined here sketch/DCCppESP32.cpp.o: In function `loop()': DCCppESP32.cpp.text._Z4loopv+0x0): multiple definition of `loop()' sketch/DCCppESP32-s88.ino.cpp.oCCppESP32-s88.ino.cpp.text._Z4loopv+0x0): first defined here sketch/DCCppESP32.cpp.o.data.buildTime+0x0): multiple definition of `buildTime' sketch/DCCppESP32-s88.ino.cpp.o.data.buildTime+0x0): first defined here collect2: error: ld returned 1 exit status exit status 1 Error compiling for board WEMOS LOLIN32.
Looks like your build env is not clean and there are some artifacts that don't belong. Sent from my ONEPLUS A5010 using Tapatalk
Not sure what the problem was, but I finally just unpacked the zip file again and this time it built just fine. However the ESP is stuck saying "IP Pending" when I have a static IP address defined for it. Any thoughts there? #define WIFI_STATIC_IP_ADDRESS "10.40.0.2" #define WIFI_STATIC_IP_GATEWAY "10.40.0.1" #define WIFI_STATIC_IP_SUBNET "255.255.255.0" #define WIFI_STATIC_IP_DNS "10.40.0.1"
Not off hand, check the serial console for some clues. Also make sure the ap and password fields are correct. Sent from my ONEPLUS A5010 using Tapatalk
Grrrr... I've been trying to work on the networking on my raspberry pi, I thought I had both wifi interfaces working now, but no, having the dhcp connection running seems to kill the access point on the other wifi. I'll have to come back to that later, but I got it working well enough to reconnect to the throttle web page, turn on power, and have it show power ON on the ESP's screen, however I am still seeing a fault warning on main and prog. I checked the current sense reading from the h-bridge and only read 0.0001 volt. Unfortunately I'm out of time tonight, will have to pick it up again tomorrow.
it sounds like there may be a short from the analog pins to VCC which is causing the ESP to read as fault condition. These pins are normally low/floating and would read at near zero until there is some sort of power draw. The serial console output will yield some clues as it should show the current draw when the fault occurs (or persists) and the trigger value during the startup. If you are seeing that low of a voltage on the h-bridge, i would expect the current sense pin to be similar.
I'm not following? The 0.001V I measured is between the current sense pin (which is hooked to SVP) and ground. On the screen it shows main/prog fault (0.00). Wouldn't that mean there is zero voltage being read by the analog pin? If there were a short to VCC I would expect to be reading either 3.3v or 5v there. I'll have to see if I can set up a laptop tonight on the test track to read the serial output and see what it shows.
Ahh you are right. I did not realize where you were testing. If you test SVP and GND you should see near zero voltage since SVP is connected to the h-bridge current sense pin. If you can capture the serial output we can work towards figuring out what went wrong. Sent from my ONEPLUS A5010 using Tapatalk
Well hopefully I'll get back to this soon. I'm really fighting with the network setup on this raspberry pi. Apparently due to systemd breaking stuff, and then a fix for that broke more stuff... now we're at a point where network settings are managed by DHCP? Ugh. I've been going round and round for three days now, loaded a fresh OS image last night and reloading from scratch again tonight, and I can't even assign a static IP to the wifi. What a ridiculous mess. So yeah, if I can ever get this thing running again then I think I can use the Pi to capture the serial output from the ESP32.
