ESP8266 Developer Zone

Re: are you improving forced light sleep?

2015-10-02T17:37:43+08:00

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.

Statistics: Posted by eriksl — Fri Oct 02, 2015 5:37 pm

Re: are you improving forced light sleep?

2015-10-02T00:14:48+08:00

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.

Statistics: Posted by tve — Fri Oct 02, 2015 12:14 am

Re: are you improving forced light sleep?

2015-10-01T16:06:09+08:00

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

Statistics: Posted by eriksl — Thu Oct 01, 2015 4:06 pm

Re: are you improving forced light sleep?

2015-10-01T15:20:31+08:00

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

Statistics: Posted by tve — Thu Oct 01, 2015 3:20 pm

Re: are you improving forced light sleep?

2015-09-30T21:16:45+08:00

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

Statistics: Posted by eriksl — Wed Sep 30, 2015 9:16 pm

Re: are you improving forced light sleep?

2015-09-30T15:54:41+08:00

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.

Statistics: Posted by joostn — Wed Sep 30, 2015 3:54 pm

are you improving forced light sleep?

2015-09-29T12:25:16+08:00

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:

Can you make this happen?
Thank you.

Statistics: Posted by tve — Tue Sep 29, 2015 12:25 pm