Power consumption problem when the AP is not avaliable

[Harold L.]

(I tried to post in this thread a couple of days ago, apparently my comment was not approved by the moderators. I'll try one more time...)

I have encountered the same unexpected behaviour of the chip. I think we need to distinguish between two scenarios here:
(A) The ESP involuntarily loses connection to an AP (for example the AP is shut down or goes out of range).
(B) The ESP voluntarily ends the connection (wifi_station_disconnect) or never establishes a connection in the first place (wifi_station_set_auto_connect(false)).

In case of (A) I'd say it's ok if the ESP use more power in order to try to re-establish the connection. If this is not desired, it is your responsibility as the API user to stop it, maybe after a certain timeout. So in my opinion everything's fine here.

However, in situation (B) I think there's a bug in the API. You would expect that the power consumption eventually goes down after disconnecting. The opposite is the case: I measured a stable ~70mA after disconnect as opposed to ~20mA (with short spikes every 1s or so) when connected and idle.
In my application I need to do some computations on the CPU before sending the data. One would assume that it's better to do the computations offline and only connect after they're done. Turns out, the opposite is true: you have to connect to an AP to save power. That is weird and definitely a bug that Espressif should look into.

for situation (B), It's normal.
As you say : a stable ~70mA after disconnect as opposed to ~20mA (with short spikes every 1s or so) when connected and idle.
please reference to the attachment of current map.

Thanks for your reply. I agree with Npt, and consider the behavior (B) as a bug, because after the wifi_station_disconnect() call, I also called wifi_get_sleep_type() and ensure it returns "2" which refers to 'MODEM_SLEEP_T' as you suggested. My current chart still is exactly the same as your's.

[Npt]

@ESP_Alfred: I see. Without knowing the internals of the chip, this behaviour seemed a bit counter-intuitive. Thank you for clarifying!

Can I ask one more favour? Like Harold, I don't know how to "close the RF" without a complete reset of the device. Could you perhaps post a small code snippet?

[tve]

@ESP_Alfred: can you please explain how I can use the esp8266 with a power budget that does not allow for continuous 70mA? I have a battery operated system that functions well as long as the wifi DTIM allows it to remain at <20mA most of the time. What should my software do when it detects that the system has lost connection with the access point in order to prevent continuous 70mA power draw?

[blubb]

I guess the problem is that ESP is constantly trying to reconnect and what we need would be an API to set a time interval between these attempts.

[tve]

Yes, or the ability to actually turn the RF off (and back on) so we can control when it tries to reconnect. The API calls are there, but they don't behave correctly.

[Npt]

I would agree with tve rather than blubb. The way I understand ESP_Alfred's post earlier, the problem isn't that the chip is trying to connect in too short intervals, but rather that it doesn't power down the RF despite not doing anything.
If there was a possibility to tell the RF to go to sleep (or, if there is, if we knew how to use it), it would be easy to implement any kind of reconnect algorithm, including intervals of any length or exponential back-off.

[ESP_Alfred]

The API that can close RF will be released at new document in next version.
Thinks for everybody.

[wowlol]

While a replay Cheap Fifa Coins or pre-match area is going on, the gamer designs along with the experience seem fantastic.

However, when they begin to FIFA 16 Coins make the things become vibrant, they are to end up to become a little unorganized.

[Npt]

Thank you very much! It's nice to see a company respond to users' needs.

[blubb]

Should this not be done automatically? Closing RF in between reconnection attempts (if there are pauses inbetween)?