wifi_set_listen_interval is counter-productive

[tve]

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?

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;

[tve]

Just saw #170, which seems related.

[cnlohr]

I wish github had an option to "super watch this issue" because I care about this, a lot.

[tve]

has work on the esp8266 stopped at Espressif?

[FayeY]

Hi, so sorry for the inconvenience. Would you like to use our latest ESP8266 RTOS SDK? Due to the limited human resource, it will be the SDK we mainly focus on in the future. Again, so sorry for the inconvenience.

[tve]

I see, does it not have this problem? As far as I know, the issue is in the non-open source wifi binary blob, doesn't the rtos sdk use the same binaries?

[kriegste]

That would suck big time. And it would be the point where the NONOS source should be opened for the community.

[eriksl]

That would suck big time. And it would be the point where the NONOS source should be opened for the community.

Either that or refactor NON-OS SDK and RTOS SDK so that RTOS SDK is only a proper layer abvoe NON-OS SDK, so you you only need to maintain one version.