wifi_set_listen_interval is counter-productive
-
- Posts: 14
- Joined: Sat Dec 19, 2015 3:43 pm
wifi_set_listen_interval is counter-productive
Postby tvoneicken » Thu Nov 15, 2018 4:47 am
I am trying to use sleep-type LIGHT_SLEEP with a large listen interval (5..8) and while "it works" it actually seems to raise the power consumption. What I see from power measurements is that indeed the radio only wakes up every N beacons it often remains in modem_sleep for entire intervals. Apparently what happens is:
- the system wakes up to receive a beacon/TIM (traffic indication map)
- if the TIM indicates that there is no traffic the system goes to light sleep for the N beacon times (good)
- if there is traffic then the system probably receives it and then stays in modem sleep for N beacon times, it never drops down to light sleep level (bad!)
This means that if there is some regular traffic (e.g. broadcasts) on the network the effect is that with increasing the listen interval the probability that there is traffic goes up and then the proportion of periods spent at modem sleep level go up too.
Why does the system never drop down to light sleep level if it had to process some packets?
- the system wakes up to receive a beacon/TIM (traffic indication map)
- if the TIM indicates that there is no traffic the system goes to light sleep for the N beacon times (good)
- if there is traffic then the system probably receives it and then stays in modem sleep for N beacon times, it never drops down to light sleep level (bad!)
This means that if there is some regular traffic (e.g. broadcasts) on the network the effect is that with increasing the listen interval the probability that there is traffic goes up and then the proportion of periods spent at modem sleep level go up too.
Why does the system never drop down to light sleep level if it had to process some packets?
-
- Posts: 14
- Joined: Sat Dec 19, 2015 3:43 pm
Re: wifi_set_listen_interval is counter-productive
Postby tvoneicken » Thu Nov 15, 2018 5:23 am
Here are two scope screen shots that illustrate the problem.
First with sleep-level=1, I annotated the light-sleep, modem-sleep, radio-receive, and radio-transmit power levels. The horizontal divisions are 500ms long and you can clearly see how the radio RX turns on every 100ms, which is the beacon interval. You can also see how many of the intervals are at light-sleep level, some are at modem-sleep level, and some have the radio turned on, presumably waiting for a packet that was announced in the TIM. The application is asleep practically the entire time (it is very briefly active at the start and end of the yellow pulse).
Now with sleep-level = 5. It is very obvious that the radio RX is only turned on every 500ms, so far so good. But what is bad is how often it sits at modem-sleep level instead of going down to light-sleep level. One can see that when the receiver is turned on for an extended period of time to receive a packet it can switch to light-sleep afterwards. But somehow during many intervals after the TIM is received the system goes straight to modem-sleep level and stays there even though evidently there is no packet to be received (else the RX would be on).
I am using a 3.0 dev SDK, the latest one used by esp8266/Arduino.
First with sleep-level=1, I annotated the light-sleep, modem-sleep, radio-receive, and radio-transmit power levels. The horizontal divisions are 500ms long and you can clearly see how the radio RX turns on every 100ms, which is the beacon interval. You can also see how many of the intervals are at light-sleep level, some are at modem-sleep level, and some have the radio turned on, presumably waiting for a packet that was announced in the TIM. The application is asleep practically the entire time (it is very briefly active at the start and end of the yellow pulse).
Now with sleep-level = 5. It is very obvious that the radio RX is only turned on every 500ms, so far so good. But what is bad is how often it sits at modem-sleep level instead of going down to light-sleep level. One can see that when the receiver is turned on for an extended period of time to receive a packet it can switch to light-sleep afterwards. But somehow during many intervals after the TIM is received the system goes straight to modem-sleep level and stays there even though evidently there is no packet to be received (else the RX would be on).
I am using a 3.0 dev SDK, the latest one used by esp8266/Arduino.
Re: wifi_set_listen_interval is counter-productive
Postby blubb » Fri Nov 16, 2018 10:22 pm
I recommend posting this kind of problem as an issue in github:
https://github.com/espressif/ESP8266_NONOS_SDK
The forum is not as active as it used to be...
https://github.com/espressif/ESP8266_NONOS_SDK
The forum is not as active as it used to be...

-
- Posts: 14
- Joined: Sat Dec 19, 2015 3:43 pm
Re: wifi_set_listen_interval is counter-productive
Postby tvoneicken » Sat Nov 17, 2018 12:04 am
Who is online
Users browsing this forum: No registered users and 181 guests
Login
Newbies Start Here
Are you new to ESP8266?
Unsure what to do?
Dunno where to start?
Start right here!
Latest SDK
Documentation
Complete listing of the official ESP8266 related documentation release by ESPRESSIF!
Must read here!
- All times are UTC+08:00
- Top
- Delete all board cookies
About Us
Espressif Systems is a fabless semiconductor company providing cutting-edge low power WiFi SoCs and wireless solutions for wireless communications and Internet of Things applications. We are the manufacturer of ESP8266EX.