|
|
Post by Jason on Jul 14, 2021 5:18:05 GMT -8
Throwing a Hail Mary here in the hopes that maybe someone is experienced with deep sleep on an ESP32 board. I'm trying to build a battery-powered pool thermometer using an ESP32 WiFi board. The idea is to have the board go into deep sleep for 15 minutes and then wake up, connect to WiFi, read the thermocouple, send the data over MQTT, and then go back to sleep. I researched boards and decided to purchase the FireBeetle ESP32 board which allegedly drops to 10 microamps of current during deep sleep. In theory, a single 3000mAh LiPo batter should be more than sufficient to last a full summer assuming the board actually consumes 10 micro amps of power in deep sleep. Unfortunately, I've followed what I believe to be the correct approach for accomplishing deep sleep on the board and a single battery only last a day or so. As a result, I've attempted to measure current in the circuit with my multimeter in order to confirm that I'm accomplishing the low power consumption. I've wired up a breadboard to take measurements and am not able to get enough power to the board likely due to the multimeter. My setup is as follows: Computer USB cable -> USB multimeter -> 3.3V/5V breadboard power supply -> ESP32/Multimeter The power supply is configured to supply 3.3V and does so based on my multimeter readings. The power supply + goes directly to the 3.3V pin on the microcontroller. The power supply - goes to the + on the multimeter. and the - on the multimeter goes to the GND pin on the microcontroller. The setup does not supply 3.3V to the board and so the board doesn't run. I've included an image of my setup for reference. Anybody able to successfully test and measure deep sleep on an ESP32? If so, any wisdom you could share because I'm losing my mind lol! Thanks, Jason  |
|
|
|
Post by SDL on Jul 14, 2021 10:18:48 GMT -8
|
|
|
|
Post by Jason on Jul 14, 2021 11:11:58 GMT -8
Thanks for the feedback. I'm disappointed to hear the sleep mode bugs in the ESP32 chip continue to persist. I was under the impression that they had been fixed. :-(
Thanks,
Jason
|
|
|
|
Post by SDL on Jul 14, 2021 15:30:10 GMT -8
Jason,
Yes, so were we. It took about 24 hours of testing before they started to show up on a consistent basis. Random, but with a distribution out to about 20 or so hours.
Both in light sleep and deep sleep. Anytime the machine has to be woken up by a timer, there are issues.
We did find that you can switch the CPU frequency (from 240MHz to 10MHz) in a reliable and repeatable fashion. Saves quite a bit of power.
BP
|
|
|
|
Post by Jason on Jul 16, 2021 8:57:15 GMT -8
Did you mess around with using an external wakeup like a DS3231 alarm for the ESP32? If so, did it get wonky as well?
Thanks,
Jason
|
|
|
|
Post by SDL on Jul 17, 2021 7:26:45 GMT -8
No, we didn't use an external interrupt source to reset the ESP32. Based on some indirect evidence, we don't think it would have fixed the problem. The problem is in the startup sequence of the ESP32, which sometimes leaves some state machine inside (we think one of the I2C bus circuits - but that is just an educated guess) in a wonky state, which kills the camera detect and thus renders the reset invalid. Even further time delays or exception resets don't clear the problem until we have a power on reset.
Now, the ESP32-CAM board does not have a reset brought out to the pins (that is so not right), so we tried the way external ESP32-CAM boards reset the ESP32. They open one of the grounds to the ESP32 (no kidding) in an undocumented way (and apparently not in the schematic, although we would have to closely examine the board to be sure).
That improved the reliability, by more closely emulating a power on reset, but it still didn't make our requirements. We now have a program structure that reduces the power to a minimum and then uses a delay to wait out the space between pictures. Not quite as power efficient, but highly reliable. Next week we should have enough data to be able to declare this problem fixed and launch the SkyCAM solar powered wireless kickstarter.
BP
|
|
|
|
Post by Jason on Jul 17, 2021 9:14:17 GMT -8
That's interesting because it might explain what I'm seeing. The DS3231 alarm is triggering a wake up of the ESP32 every minute but after about 30 minutes the WiFi doesn't connect anymore in spite of the WiFi.disconnect() call right at the beginning of the setup() function.
Thanks,
Jason
|
|
|
|
Post by SDL on Jul 19, 2021 18:36:32 GMT -8
Jason,
Hmm. Yes, this may very well be caused by the same ESP32 problem. Nothing on the Web about this. I don't think very many people have tried to do anything complicated with sleep.
BP
|
|
|
|
Post by Jason on Jul 20, 2021 5:41:38 GMT -8
Made some software changes in my Arduino script and now the ESP32 is running much more reliably. My USB PowerControl board arrives Friday so I'm looking forward to tapping into the power consumption and seeing how well the chip performs. I realized recently that I should probably round the temperature reading to an integer and store it in the RTC memory between sleeps. Doing so will allow me to avoid sending the same temperature reading multiple times and incurring the additional battery drain of connecting to WiFi and sending an MQTT message.
I share your frustration with the lack of real-world applications leveraging the deep sleep. So much of what I've read indicates what I'm trying to do is very easy. Unfortunately, I'm just not seeing the results.
Thanks,
Jason
|
|
|
|
Post by Jason on Aug 6, 2021 5:30:00 GMT -8
Awaiting a TPL5110 power timer breakout to sit between the power supply and the ESP32 microcontroller. Plan is to set the timer to 15 minutes and open power to the microcontroller, take and send a reading, signal done to the timer, and kill power to the microcontroller entirely. Let's see how this goes :-)
Jason
|
|
|
|
Post by Jason on May 8, 2022 7:35:24 GMT -8
I continue to noodle with this project for some reason that I can't explain. Using FireBeetle2 ESP32-E microcontrollers and, not surprisingly, finding results consistent with other boards in spite of documentation and examples that contend I should be seeing microamp consumption.
Thanks,
Jason
|
|
