Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
wifi_set_listen_interval is counter-productive #192
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:
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?
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 git master;