Power consumption problem when the AP is not avaliable

[tve]

I do believe this is a bug in the SDK. The bug being that the average power consumption goes up by a significant factor in STA mode if the AP is not reachable.
The work-around I've found is to write a callback for wifi status changes and when you get a disconnect event implement a back-off retry mechanism that disables wifi altogether and then turns it on again periodically (and then off again if no AP is reachable). In your use-case, you can probably get away with turning it on briefly every minute or even every 5 minutes.

[Harold L.]

1、As you see form table 4, the current rising is inevitable when 8266 send packet.If you want to reduce this part of the current, You could modify the parameters in the "esp_init_data_default.bin" via "flash download tool" to reduce the power of Tx.

2、8266 have some sleep mode, may be you adopt this mode in your occasion.

1. I'm sorry you may not catch my point... I've made some translation to help us understand each other

As I've said, "Could we come up with a compromise like introducing some 'gaps' between each Tx retrying? It seems that now the strategy is little bit like a 'flood'. Can we take a strategy like TCP's retransmission algorithm(Exponential Back off) ?"

It means: 我们能找到一种方式，当AP不存在的时候，不是像现在这样洪水一般的发包寻找AP，而是引入一些间隙，隔几秒钟试探一次？这并不会妨碍重新连接的过程，却能大大降低这种情况下的平均功耗。TCP的重传机制（重试时间按指数退避）是一个可以参考的例子。

2.I've tried all sleep modes, and found only after entering deep-sleep mode and rebooting with "system_phy_set_rfoption(4);" can reduce current. But unless another deep-sleep rebooting, it'll never connect even if the AP appears again! This is a bad experience for our customers.

[Harold L.]

I do believe this is a bug in the SDK. The bug being that the average power consumption goes up by a significant factor in STA mode if the AP is not reachable.
The work-around I've found is to write a callback for wifi status changes and when you get a disconnect event implement a back-off retry mechanism that disables wifi altogether and then turns it on again periodically (and then off again if no AP is reachable). In your use-case, you can probably get away with turning it on briefly every minute or even every 5 minutes.

I think you are right, but I didn't find a way to disable/enable wifi without rebooting. I found the only way to shut it down is entering deep-sleep mode and rebooting with "system_phy_set_rfoption(4);". If we want to enable it again, another reboot is inevitable.

A more weird thing is, calling 'wifi_station_disconnect()' may also cause the abnormal high current.

Do you have a workable way to enable/disable wifi?

[tve]

I'm trying to locate the code I mentioned, but am failing right now. Have you tried using wifi_station_set_reconnect_policy? Or setting wifi_station_set_auto_connect to false and managing reconnection attempts yourself?

[Npt]

I am struggling with the same unexpected behaviour of the chip. I set the auto connect to false so that I could do some computations before firing up the WiFi connection and transmitting the results. However, instead of saving power, this method seems to consume more.

I only have a very basic DMM, so take my measurements with a grain of salt. There's also a power LED on my board, but that will only affect the absolute values, not the relative ones.
After power on and calling wifi_station_set_auto_connect(false) and wifi_set_opmode(STATION_MODE) in user_init, I get ~75mA. When I call wifi_station_connect() the current drops(!) to ~20mA with short spikes every second or so. Calling wifi_station_disconnect() makes the power rise again to ~75mA. These measurements are all taken after a short wait, when they've stabilised. Each operation (boot, connect, disconnect) causes a short rise in power, which seems logical to me.

What doesn't seem logical is that idling without being connected to an AP takes almost four times as much power as idling with a connection. Just to be clear: I'm not talking about a connection that was lost involuntarily. I understand that in that case the module would try to regain the connection by upping the power. But it shouldn't happen if the connection was willingly shut down (wifi_station_disconnect) or never established in the first place (wifi_station_set_auto_connect(false)).

And yeah, the fact that we can't enable or disable RF without a reboot, really sucks.

[Harold L.]

Hi, we've tried all related APIs, but no lucky, ESP8266 consumed too much battery when AP is not exist, are you still working with this problem?
Glad to hear from you, thanks!

[ESP_Alfred]

Hi, we've tried all related APIs, but no lucky, ESP8266 consumed too much battery when AP is not exist, are you still working with this problem?
Glad to hear from you, thanks!

hi, Harold L
We have a lower power working mode ,base on deep sleep mode. please give your e-mail address to me, we will connect to you.

[Harold L.]

Hi, we've tried all related APIs, but no lucky, ESP8266 consumed too much battery when AP is not exist, are you still working with this problem?
Glad to hear from you, thanks!

hi, Harold L
We have a lower power working mode ,base on deep sleep mode. please give your e-mail address to me, we will connect to you.

My address is: haroldmars[A.T.]icloud.com
Thank you a lot!

[Npt]

(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.

[ESP_Alfred]

(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.