Best practices for deep sleeping an esp32

[dave0003]

Is there anything special recommended before doing a "deepsleep()" on an esp32?

Currently I'm just doing a short normal sleep, to allow the wifi to finish it's transmission (without it, it often doesn't complete).

sleep(0.5)
deepsleep()

I've also seen this recommended before deep sleeping:

wlan.disconnect()
wlan.active(False)
wlan.deinit()

Supposedly to get the wifi to completely shut down before the deep sleep, otherwise it continues to draw more power than necessary. Is that still the case with the latest MicroPython and the esp32?

Any advice is appreciated, thanks.

[davefes]

Where did you find wlan.deinit() mentioned?

MicroPython v1.22.2 on 2024-02-22; Generic ESP32 module with ESP32
Type "help()" for more information.
>>> 
>>> import network
>>> wlan = network.WLAN()
>>> wlan.deinit()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'WLAN' object has no attribute 'deinit'

I will try with 1.25

If you don't do any wifi calls in your code and go to deepsleep, what current do you measure?
Then connect() and disconnect() and go to deepsleep, what current do you measure?

[dave0003]

I don't have any good way of measuring the current used, except to wait and see how long the battery lasts.

I mostly see wlan.deinit() mentioned in relation to the Pico W.

https://github.com/orgs/micropython/discussions/9135
https://github.com/orgs/micropython/discussions/12573
https://github.com/orgs/micropython/discussions/13748
https://github.com/orgs/micropython/discussions/12882

In one of those cases above, the wlan.deinit() increased deep sleep current consumption, oddly. So I'm not sure I want to put it in unless it's really recommended.

I'm not sure if the esp32 is similar in that respect, or not. Or if there have been improvements in MicroPython since that time.

[davefes]

Unless you are using Li-ion and fairly accurately measuring voltages on the steep part of the curves, ie 4.0 and 3.0Volts and using the same cell I think you asking too much. A DVM with 1mA DC current resolution is reasonable indication. People use a current measuring module, INA219 https://awesome-micropython.com/#current to get reasonable results.

I have been working with the ESP32 WiFi for a few years now and I am not aware that there is anything else required to shut the WiFi down than:

wlan.disconnect()
wlan.active(False)

[dave0003]

Thanks. I'll try adding that before the deepsleep().

For what it's worth, I'm using a 2000 mAh LifePO4 battery with a small bms protection board added (charged on an external charger when needed).

[davefes]

LiFePO4 have well defined "knees" like Li-ion. However, if you have a deepsleep current, say around 1mA, you will be waiting a long time to determine if you have made any improvements.

[davefes]

There could be other things drawing unwanted current, especially on commonly available dev boards. I remove the 3V3 regulator if it is a AMS31117 and replace it will a better regulator chip, ie the HT7333 or HT7833. Remove the red LED. Then cut the supply to the UART bridge chip and use an external FTDI programmer

[dave0003]

That would be nice. I'm hoping those aren't drawing too much current, since I'm powering it directly from the 3V3 pin. I have to wonder what they were thinking with the red power LED on all the time, even when powered by 3V, something my ESP8266's don't suffer from. But I wanted the better wake-up functionality on the esp32 this time.

I'm more of a software person than electronics and hardware, and I don't feel comfortable undertaking anything so delicate, though.

[glenn20]

Is there anything special recommended before doing a "deepsleep()" on an esp32?

I've also seen this recommended before deep sleeping:

wlan.disconnect()
wlan.active(False)
wlan.deinit()

Supposedly to get the wifi to completely shut down before the deep sleep, otherwise it continues to draw more power than necessary. Is that still the case with the latest MicroPython and the esp32?

See https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/system/sleep_modes.html#wi-fi-bluetooth-and-sleep-modes.

According to that, the user must shutdown wifi and bluetooth before deepsleep. wlan.active(False) will shutdown the wifi peripheral (actually, both the sta and ap interfaces should be set inactive so that esp_wifi_stop() is called).

From my experience, if I go into deepsleep without shutting down the wifi, wifi will often work just fine after resume, but sometimes the wifi does not reinitialise correctly after resume from deepsleep.

[dave0003]

I wonder if it's router-dependent. With or without the wlan.disconnect() and wlan.active(False), I see two entries in my Mikrotik log when it wakes from deep sleep and reconnects, in rapid succession: dhcp deassigned ip and dhcp assigned ip.

I don't see any response from the router when doing the wlan.disconnect().

It is relatively fast, about 2 seconds to wake from deep sleep, connect to wifi, and transmit data.

[davefes]

Checked the datasheet, it says typical 5mA Quiescent Current, the HT7333 is 8uA. I never checked to see it there was a current draw with the 5V disconnected.

[davefes]

@glenn20, just checked https://github.com/glenn20/micropython-espnow-utils/blob/main/src/wifi.py

Are you suggesting that disconnect should make both interfaces inactive?

The reset() method seems to handle those cases. Unfortunately, when I used that wifi.py I wasn't going anything explicit with reset(). Should you call reset() after a disconnect()?

Ah, I see in README.md that you suggest a reset before a connect

[glenn20]

@glenn20, just checked https://github.com/glenn20/micropython-espnow-utils/blob/main/src/wifi.py

Are you suggesting that disconnect should make both interfaces inactive?

If you only ever set one of the "interfaces" active, you only need to set that one inactive. When wlan.active(False) is called, micropython will call esp_wifi_stop() only if both interfaces are inactive at that time.

The reset() method seems to handle those cases. Unfortunately, when I used that wifi.py I wasn't going anything explicit with reset(). Should you call reset() after a disconnect()?

Ah, I see in README.md that you suggest a reset before a connect

[davefes]

@glenn20 thanks. I am going through another session of trying to maintain a WiFi connection and I will grab any straws floating past.

[dave0003]

I've had my esp32's running for awhile now. So far, it seems the 2,000 mAh LifePO4 batteries are lasting about 24 days. Most of the time is spent in deep sleep, with it waking up a few, or several, times a day when a sensor is triggered to transmit a short tcp message over wifi.

So that's about 3.5 mA drain, on average.

I notice the red LED holds out about an extra day after it stops transmitting messages.

[robert-hh]

A board with a given configuration of the pins will consume more current than the naked MCU. The red LED you mention will take some current (like 1-2mA), and outputs which are configured with a load (output low/load to Vcc or output high/load to GND) will consume current as well.

[dave0003]

Yes, they're connected to a magnetic door sensor. When the door is closed, it deep sleeps until WAKEUP_ANY_HIGH, and when the door is open, it deep sleeps until WAKEUP_ALL_LOW.

I don't think the sensors consume too much, probably much less than 1mA. And the red LED is probably at least 1mA also. My best guess is the voltage regulator is consuming the rest, even though I'm powering it directly using the 3.3v pin, so there shouldn't be anything to regulate.

[robert-hh]

The door sensor is probably only a switch, and so the current depends on the value of the pull-up resistor. The current of the RED led also depends on the current limiting resistor R. At 3.3 V is should be about 1.8/R. The regulator may consume current, if fed at it's output. The datasheet shoudl give indications. The external flash will consume power as well. So 3.5 mA is not too bad for a board.