ESP32 ECO-Mode not working?

[chromo23]

Today i was measuring the power consumption of an ESP32 module (≈130mA) and in an attempt to save some i enabled "ECO-Mode".
But different from what i'm used to on the esp8266 there was no current drop at all at no time.
So i testet another kind of esp32 board and apart from a current build i also testet the latest release. No difference...

So either the "ECO-mode" is not working or it is not what i expect to see. Maybe there is no significant drop and only the duty cycle changes slightly so that my measuring device is unable to detect this kind of resolution.

[TD-er]

The ECO mode is working... but it does indeed act differently from how the ESP8266 is dealing with it.

The ESP8266 may change the WiFi parameters when calling delay() quite often.
ESPEasy has an internal scheduler which deals with everything that has to be done periodically.
For example the PLUGIN_FIFTY_PER_SECOND and PLUGIN_TEN_PER_SECOND, rules timers, etc.

This scheduler knows when the next thing has to be done.
With ECO mode enabled, I just call delay() upto the moment the next scheduled thing is due.
This does reduce the number of calls to loop() significantly and during these delay() calls the SDK does handle WiFi events, receives data, etc.
When doing this for long enough intervals, the SDK may decide to switch off the WiFi for longer intervals (the DTIM setting in WiFi specification)
This does reduce the power consumption significantly.
It also may reduce TX power.

But this is all done in code we cannot control.
N.B. it even ignores power settings we explicitly set.

The ESP32 does behave differently as it is running RTOS.
If we call delay(), the RTOS kernel may decide to run other tasks, like handling WiFi etc.
But this is done entirely different from how the ESP8266 does it as it matters when in the time slot we call this delay().

Also I have disabled switching TX power on the ESP32 as it does cause some very strange issues.
I got the 'feeling' the ESP32 may need a bit more time to ramp up the TX power again which makes it a bit late each time and thus will miss the beacon interval from the AP, causing it to become really sluggish.
Still the way how the SDK may increase the DTIM interval and/or lower TX power is different from the ESP8266.
It can still lower power consumption, but it may take longer compared to the ESP8266.

N.B. on the ESP8266 it may still take upto 10 minutes before it enters this lower power state and if you're sending a single ping to it, it may be at max. power for minutes.

[chromo23]

Thanks as always for your very detailed reply!

[chromo23]

Sorry but i have to bother you a bit more with that
I was curious and wanted to see how Tasmota is doing.
There i could see the typical fluctuations from 30mA to 110mA... in ESPeasy there is no fluctuation not even after an hour. it stays at 130mA
Also the devices with Tasmota don´t get warm. With an default install with ESPeasy the devices are quite warm constantly (no plugins, no p2p, no nothing activated..just "ECO-Mode")

[TD-er]

Maybe Tasmota does have reduced TX power?
130 mA is quite a lot. Typically I would expect 70 - 80 mA.

I do know Tasmota is running at a lower CPU frequency.
ESPEasy is running the ESP32 at 240 MHz and I think Tasmota has it set to 80 or 160 MHz.

However I am a bit reluctant to switch frequencies as it can be done in the board definition (which does affect the bootloader) and it can be set at runtime.
But when setting it at runtime, I have no idea what kind of Pandora's box we will open.

Where does the ESP get hot?
The ESP module itself, or the antenna or the voltage regulator?

[chromo23]

I think i found a bug... maybe
I used an older Release (20211224) and it works as expected...

Where does the ESP get hot?

Module itself (not antenna)

[TD-er]

Could be that the latest ESP32 IDF SDK changed the ESP's behavior.
We're already running almost a year on the IDF 4.4 code, so it is possible the build you tested was about the last one to run on the older IDF code.

[chromo23]

You are right, just tested the last release with the old sdk vs the first with IDF 4.4.
So i guess i stay away from builds with IDF 4.4 for my esp32 in terms of power saving

[TD-er]

Well, since I'm working on a node which needs to be powered by a 18650 battery, it might be a bit higher on my priority list than you would expect.

One problem we already encountered is that the actual capacity of such a battery at -22C isn't what you'd expect it to be
Apparently in Sweden it was this cold this morning. Here in the sub-sub-sub-tropical part of Groningen, we only had -10.5C this morning

[chromo23]

Well, since I'm working on a node which needs to be powered by a 18650 battery, it might be a bit higher on my priority list than you would expect.

Thats good to hear.

One problem we already encountered is that the actual capacity of such a battery at -22C isn't what you'd expect it to be

Maybe LiFePo4 is a better choice for these temperatures.

Here in the sub-sub-sub-tropical part of Groningen, we only had -10.5C this morning

In berlin it is -3°C and sunny. Almost t-shirt weather...

[chromo23]

I do know Tasmota is running at a lower CPU frequency.
ESPEasy is running the ESP32 at 240 MHz and I think Tasmota has it set to 80 or 160 MHz.

This by the way would only make sense in terms of power consumption when builds of ESPeasy prior to IDF4.4 would run with a lower frequency too.
Because Tasomota and the older builds show the exact same behavior.

Edit:

One problem we already encountered is that the actual capacity of such a battery at -22C isn't what you'd expect it to be

There is a positive side to the ESP32 getting warm.. Place it as close as possible to the battery and it doesn’t get so cold anymore (But i am not quite sure if the energy wasted by the heat that will lead to a faster drainage of the battery is better than a lowered capacity caused by the temperature.)

[TD-er]

I just talked to Jason2866 about this and he showed me that Tasmota is using their own delay() function.
This does only call those tasks which need to respond quickly.
For example to fetch data from a buffer before it's gone.
Typically what we do in the PLUGIN_FIFTY_PER_SECOND calls.

They don't have such a call, so this allows Tasmota to make much longer calls to delay().

Also the Tasmota "scheduler" is doing things completely different from what ESPEasy scheduler does.
In ESPEasy, I maintain a list of things to do, with their set timestamp.
Thus looking at the first item in this list. Should it be done? If so, do it and remove it from the list.
If not, then (in ECO mode) call delay() for the time until that one should be done.

The Tasmota scheduler appears to be much and much simpler.
Just a simple function which checks for all things that need to be done periodically whether or not it should have been done already.

To be honest, this does seem as simple (and quite elegant) as it can be.
However, this may cause some timers to be not as accurate as you may want them to be.
On the other hand, the Tasmota scheduler does allow for (much) longer delays between execution.

Maybe I can tweak the ESPEasy scheduler a bit where the "load" can be increased a bit to make the "idle" calls somewhat longer. This will however cause the timers to experience more jitter.
But if it will reduce power consumption, it can be a trade-off which may be worth it.

[chromo23]

But if it will reduce power consumption, it can be a trade-off which may be worth it.

It sure is but on the other hand with the actual power consumption the raspberry pi zero w almost steals the show here

But i still don’t quite understand why changing the actual behavior, as the very same thing (unless you changed the method along witch the change to idf4.4) worked before as intended. That raises the question for me if there is maybe another issue involved.

What ever is in my ability to help here to make this work i am all in...

Edit:

What ever is in my ability to help here to make this work i am all in...

Which basically means testing.. if that was not clear before

[TD-er]

A quick first test shows that reducing the frequency to 160 MHz does reduce the current from 125-130 mA to 110 mA in ECO mode, 116 mA without ECO mode.
This is just a simple NodeMCU-like ESP32.
All other things being equal.

It does however feel already a bit less snappy.

@80 MHz:
Non-ECO mode: 108 mA
ECO mode: 104.3 mA

Hardly feel any speed difference between 160 MHz and 80 MHz.
However the "load" roughly doubles and the loop counter is roughly 60% of that on 160 MHz.

But on the other hand, the load only doubles from 240 MHz to 80 MHz when running in "ECO" mode.

Let's see if changing the TX power may help here.

Options:
- Reduce TX power
- Increase DTIM
- Increase 'minimal' "eco mode" delay.


Edit:
ECO mode @80 MHz and max. 20 msec for "idle" loops: 103.8 mA, thus roughly 0.5 mA less.
ECO mode @80 MHz and max. 50 msec for "idle" loops and PLUGIN_FIFTY_PER_SECOND set to 50 ms (thus 20/sec): 103.1 mA, thus again roughly 0.5 mA less -> Not an option IMHO, really sluggish

[chromo23]

The maximum current is in my opinion not the issue. The issue is that it is drawn constantly.
This seems to be a similar issue: https://github.com/espressif/esp-idf/issues/8324

This is the device with a recent build:

recent.gif (1.15 MiB) Viewed 2952 times

And with a prior idf 4.4 build (there are Spikes of 120-130mA too but only when i access the device via wifi)

old.gif (1.11 MiB) Viewed 2952 times

[TD-er]

Those numbers I mentioned were the "average" current draw.
So it is the continuous power draw and I do agree this is just too much.

[chromo23]

So my conclusion is, that it doesn’t help to reduce the clock speed. Wifi constantly on full power is the issue...

[TD-er]

It is too early to draw conclusions

[chromo23]

I knooooow.... i thought i didn’t hit send because while i was writing it i was already not convinced anymore.

[TD-er]

I knooooow.... i thought i didn’t hit send because while i was writing it i was already not convinced anymore.

Just as a teaser.. I am now looking at 50 mA in "Eco" mode...

[chromo23]

Just as a teaser.. I am now looking at 50 mA in "Eco" mode...

Thats sounds great! What did you need sacrifice for that?

[TD-er]

Just as a teaser.. I am now looking at 50 mA in "Eco" mode...

Thats sounds great! What did you need sacrifice for that?

My ego....

[chromo23]

Edit: I admire your honesty !

[TD-er]

OK, I also tried using FREERTOS_USE_TICKLESS_IDLE and dynamic frequency scaling.
However, I think it only does something funky with the WiFi responsiveness.
The power consumption per clock freq (ECO mode on and WiFi no sleep off)
- 80 MHz: 51 mA
- 160 MHz: 60-ish mA
- 240 MHz: 79-ish mA

Switching frequency during runtime is a very good receipe for "funky WiFi connectivity", so I will not commit that code.
This means it will be fixed at either 160 or 240 MHz.

The only things you can then set are:
- WiFi no sleep
- ECO mode.

[TD-er]

OK, now for something really unexpected...
Lowering WiFi TX power results in a higher power draw compared to setting the WiFi to light sleep.

[TD-er]

See: https://github.com/letscontrolit/ESPEasy/pull/4419
The test builds, as soon as they are ready: https://github.com/letscontrolit/ESPEas ... 3703331138

I didn't aim for the lowest power consumption, but more like the least problematic combination of "force WiFi no sleep" and eco mode.

When turning on ECO mode on ESP32, it will now also lower the CPU frequency to 80 MHz and activate dynamic frequency scaling + WiFi light sleep.
On an ESP32 without anything else running, this will consume roughly 60 mA and still remain responsive.
But it will be less responsive than running on non-ECO mode (240 MHz)

You may need to reboot to get the actual power consumption based on the settings.
And I have seen my unit sometimes not being able to reconnect to WiFi when I switched the WiFi no sleep option.
Or maybe I didn't wait long enough....

[chromo23]

I started testing a bit and it looks very good!

OK, now for something really unexpected...
Lowering WiFi TX power results in a higher power draw compared to setting the WiFi to light sleep.

Tell me about it..
This rule (every ms) lowers the consumption from 50mA to 30mA. So make sure your Esp32 has something to do all the time

Code: Select all

On Rules#Timer=1 Do
  //2^((x/2+50000)/7500)-101
  If [int#2] < 65530
    PWM,27,[int#2]
    Let,2,0.5*[var#1]+50000
    Let,2,[var#2]/7500
    Let,2,2^[var#2#D.4]-101
    Let,1,[var#1]+5
    Let,4,%syssec_d%-[var#3]
    TimerSet_ms,1,1
 Else
    PWM,27,65534
 Endif
Endon

[chromo23]

loopTimerSet_ms (tried 100ms an less) leads eventually to a reboot no matter if ECO-Mode is enabled or not.
I also seems that the code i posted before leads to a reboot...(not in the beginning. maybe after i power cycled the Esp)

Edit: I did a factory reset (should have done it in the first place) now it seems to behave fine again...
It smells funny... I`ll keep an eye on that

[TD-er]

If that leads to a reboot, then you either have serial log enabled (or log to syslog server) or not enabled the rules cache.
Those will cause the memory to be filled untill memory allocations fail.

Oh and PWM might be blocking...