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.