ESP32 Forum

In my application, I am using light sleep and periodically waking up and using esp now. I want the time awake to be an absolute minimum. I use the following code:
For the first cycle, the esp_wifi_stop() call takes 1ms and the esp_wifi_start() takes 7-8ms. For subsequent cycles though this code, the esp_wifi_stop() takes 9ms. There is an important distinction between the first and subsequent loops. The first call to esp_wifi_stop() is before any esp_now_send calls, whereas others are not. I can see if I remove the esp_now_send call between sleeps, the esp_wifi_stop() call remains at 1ms duration.

9ms seems like a long time to turn off the WiFi. Is there any way this, and for that matter esp_wifi_start() can be sped up as a 19ms overhead is massive for my application?

PS: I have played with reducing the cpu mhz during the esp_wifi_stop() and esp_wifi_stop() calls and it slows them down a lot.

Hi Chris,

Calling esp_wifi_stop() will try to do a "graceful" stop of the internal Wi-Fi state, which may include things like flushing buffers if there is an esp_now() packet queued for retry. I'm afraid it's not really designed for rapid pause/resume use case.

For minimum average power consumption, if possible then the best thing to do is to switch to ESP-IDF and enable the automatic light sleep options which will put the chip into light sleep automatically whenever the radio is not busy and there is no task waiting to run. This happens at a much finer grained resolution than what can be achieved with esp_wifi_stop()/esp_wifi_start(). Unfortunately as far as I know there's no way to use this feature from Arduino.

Thanks Angus. Automatic light sleep does look like a good solution. I'll have to look at how much pain is involved in transitioning across to ESP-IDF. It would be good to take advantage of the work I have done within Arduino though.

I will look at the ESP-IDF to see if it improves things, but automatic light sleep won't work here as I am using ESP NOW and the timings of communications aren't as pre determined as with the DTIM WiFi situation involving an access point. I do need to be controlling the sleep directly and therefore I do need to work out how to minimise the overhead of entering and exiting sleep which is mainly esp_wifi_stop() and esp_wifi_start().

I can adjust my strategy to maintain the 1ms esp_wifi_stop(), but still have the 8ms overhead of esp_wifi_start(). I don't like the strategy either as it involves the other end sending out messages until one is acknowledged.

If I make the esp_now_send to the broadcast address (FF FF FF FF FF FF) then the esp_wifi.close() is only 1ms still. I think the delay is if there is an incomplete esp_now send.

Would be nice to make an improvement on the esp_wifi_start() side of it because 8ms is painful there.