I ran a battery test and measured the microseconds to connect to wifi. During the test the imp.setpowersave was changed from false to true. See attached picture. Why is the time to connect to wifi longer when imp.setpowersave is set to true? It ussually connects in 1.1s and 2.8s. Why is it either 1.2s or 2.8s and not somewhere in between? And why doesn’t it connect always in 1.1s?
Here’s how power-save mode works. Normally, when a wifi device wants to send a packet to the imp, it just sends the packet, and the imp receives it. But in power-save mode, the imp is mostly not listening for wifi packets: that’s how it saves power, as the wifi receiver is switched off. So how does any data get received? The answer is that the access-point periodically broadcasts “beacon” packets. Because these are sent at regular intervals, the imp’s wifi chip can switch on the receiver at just the right time, receive the beacon packet, and switch it off again. And – if the imp has negotiated power-save mode with the access-point – the beacon includes an indication of whether there are any packets waiting for the imp. If so, the imp can keep the receiver on and receive them (the access-point retransmits them after the beacon).
So using power-save mode will reduce the power consumption of a permanently-connected imp. But it does this at the expense of increasing latency. For an imp which isn’t permanently-connected, and for which the wifi latency (wifi power-on duration) is itself the largest power cost, power-save mode will actually use more power.
Peter
Thanks for the explanation. Can you explain why it connects either in 1.1s or 2.8s and not somewhere in between? And why is it not always connected in 1.1s.
In my battery test my code ran slower when imp.setpowersave(true), however I found that the number of sleep/wake cycles on the battery increased. So I accept a slower flow of the program.
DO you think I can increase battery life further by setting imp.setpowersave(false) before connecting and change it to true after connection is established?
The real world is full of variables; wifi interference or other clients can cause packets to not be received by the AP and hence retry strategies kick in all of which extend the connection time (generally by pre-set amounts). If you did the test conducted due remove all external sources of variability, you may find the connect time is a lot more stable.
That said we ran some cycle tests with over a million connects and they were a lot closer to 1s generally (ie spikes were less often than in your tests) - maybe that was our wireless environment being better.
On setpowersave() - YMMV, test and go with what works best for you. We can’t really advise for your specific application.