ESP8266 Community Forum

- Fri Apr 22, 2016 4:04 pm #46019 Hello,

is there a sleep mode, which keeps the wifi running, but the ESP8266 should still be able to receive a packet (maybe an interrupt?

I found the folling on the Espressif Website:

Currently ESP8266 can support three low power modes: Light Sleep, Modem Sleep and Deep Sleep.

①：Modem-Sleep requires the CPU to be working, as in PWM or I2S applications. According to 802.11 standards (like U-APSD), it saves power to shut down the Wi-Fi Modem circuit while maintaining a Wi-Fi connection with no data transmission.
E.g. in DTIM3, to maintain a sleep 300ms-wake 3ms cycle to receive AP’s Beacon packages, the current is about 15mA.

②：During Light-Sleep, the CPU may be suspended in applications like Wi-Fi switch. Without data transmission, the Wi-Fi Modem circuit can be turned off and CPU suspended to save power according to the 802.11 standard (U-APSD).
E.g. in DTIM3, to maintain a sleep 300ms-wake 3ms cycle to receive AP’s Beacon packages, the current is about 0.9mA.

③：Deep-Sleep does not require Wi-Fi connection to be maintained. For application with long time lags between data transmission, e.g. a temperature sensor that checks the temperature every 100s.
E.g. sleep 300s and waking up to connect to the AP (taking about 0.3~1s), the overall average current is less than 1mA.

If I understand it correctly, the connection to the AP will be maintained, but I can't wake it by sending a packet, am I correct?

Kind regards,
Jannik

- Fri Apr 22, 2016 4:30 pm #46023 Unfortunately, No !
In all 3 modes, the ESP WiFi Radio is shutdown, so, no connection remain !
When waking up, since the WiFi configs are persisted, it does a reconnect to previous AP.

- Sat Apr 23, 2016 4:39 am #46030 In 802.11 standard traditional poll-based power saving mode,
the radio is activated every DTIM(typically 100ms). In the sleep period, any packet destined to STA is queued at AP and packet destined to AP is queued at STA client host.

If the ESP8266 follows the standard, the Modem-Sleep looks like the one fit.

In summary, the WiFi module is wakeup as schedule, not by "receiving a packet".

- Sun Apr 24, 2016 4:05 pm #46103 in general, to make sense, the SDK should either provide the possibility to register a routine that will be called when DTIM indicates a datapacket to be waiting for delivery
or
the suspended cpu should disable light sleep, commence to just after where "light sleep" was enabled to do a (cyclic) check to receive such waiting data; after the data is received light sleep could be enabled again.