are you improving forced light sleep?

tve
Posts: 123
Joined: Sun Feb 15, 2015 4:33 pm

are you improving forced light sleep?

Postby tve » Tue Sep 29, 2015 12:25 pm

I find that the current forced light sleep (wifi_fpm_*) is disappointing because awakening is too expensive in terms of power usage. Specifically, the fact that the wifi MAC layer starts a fresh association at start-up is totally killing the power budget and is unnecessary. Please consider that there are important use-cases where an esp8266 does not need to stay reachable (which is what automatic light sleep ensures) but does need to wake up at regular relatively short intervals to communicate.

Here is how you could improve forced light sleep (and deep sleep) significantly:
    - when a station associates with an AP the AP communicates an idle-timeout period, this is the time after which the station is disassociated if it has not communicated with the AP (in the IEEE 802.11-2012 standard this is called the "BSS Max Idle Period" and is shown in section 8.3.3.6)
    - the SDK should make this value available to the application so the application can decide to sleep for a shorter interval than this period so the association is not lost by the time the system wakes up
    - if the system is asleep for less than this interval, on wake-up, the SDK should attempt to reconnect to the AP using the old association, which should only take 1 or 2 round-trip packets (as opposed to the current 6-12 seconds at high power to obtain a fresh association)

Can you make this happen?
Thank you.

joostn
Posts: 19
Joined: Thu Jan 22, 2015 5:00 pm

Re: are you improving forced light sleep?

Postby joostn » Wed Sep 30, 2015 3:54 pm

Yes! This would truly enable battery operated sensors, e.g. where a packet has to be sent every 5 minutes or so.
Or when latency must be lower than the current 5 seconds time to wake.

eriksl
Posts: 157
Joined: Fri May 22, 2015 6:22 pm

Re: are you improving forced light sleep?

Postby eriksl » Wed Sep 30, 2015 9:16 pm

AFAIK the idle time may only be a very small amount of time, something like 1 second max.

tve
Posts: 123
Joined: Sun Feb 15, 2015 4:33 pm

Re: are you improving forced light sleep?

Postby tve » Thu Oct 01, 2015 3:20 pm

@eriksl: do you have any reference for this? I have seen mentions more around 60 seconds and longer.

eriksl
Posts: 157
Joined: Fri May 22, 2015 6:22 pm

Re: are you improving forced light sleep?

Postby eriksl » Thu Oct 01, 2015 4:06 pm

A course I once followed, so no books unfortunately.

But even if it's 60 second. You don't want to power it down (because then it will need to do rfcal again), I am not completely convinced it will save that much power. Mobile devices use a comparable mechanism where the DTIM then gets stretched from 1 (= normally 100 ms) to a few (maybe 500 ms) and they can be economic with power as well. Maybe it would be sufficient to have the DTIM configurable and set it likewise.

LOL I am contradicting myself here. Guess I don't know really ;)

tve
Posts: 123
Joined: Sun Feb 15, 2015 4:33 pm

Re: are you improving forced light sleep?

Postby tve » Fri Oct 02, 2015 12:14 am

LIGHT_SLEEP mode already uses DTIM. There are two problems with light_sleep: one is that the DTIM interval is too short. Typical values are 1 (=100ms) and 3 (300ms). The bigger issue is that the client is told about traffic which in many uses-cases is not desired. All broadcasts plus other requests, such as ARP refreshes, cause the esp8266 to be told "hey I have a packet for you" and that causes it to be in receive mode for at least 100ms. That kills battery really fast. We need a sleep mode that maintains an association but gives the application control over when to wake up and not the AP.

BTW: I don't see why RF cal would be needed on every wake-up. I've asked Espressif in the past when it is needed and they didn't answer in a reasonable manner, but I think it would only be needed if vcc changes (and perhaps temperature, but there's no built-in sensor for that). One option might be not to recal until rssi goes down a lot or the chip can't keep its association anymore. After all, we're not trying to optimize RF for good throughput here, it's just about being able to exchange a few packets every now and then.

eriksl
Posts: 157
Joined: Fri May 22, 2015 6:22 pm

Re: are you improving forced light sleep?

Postby eriksl » Fri Oct 02, 2015 5:37 pm

You must keep the option open that espressif didn't develop the RF-module itself, but bought IP. In that case they're restricted to the interface the IP block exposes.

What you're seeking for would best implemented in the access point I guess, "hold"-ing all traffic for some time. OTOH that's exactly what DTIM is for afaik. Yeah, if the DTIM would be configurable, we could experiment with that. I don't see any real RF-wise impact the FCC could be worrying about.

Who is online

Users browsing this forum: No registered users and 9 guests