ble taking too much power (IDFGH-769)

[joicetm]

Hi,
I wish to know when can i expect the low power modes in ble? would this feature be added in the next release v3.0?
currently i observe that with single core and 80 Mhz, the device consumes around 80-90 mA.[minimum i was able to achieve]
is it the best we can achieve ? or is there any way to improve the power consumption with current idf version?

[MS-elug]

I have the same issue. Even running the demo heats the chips a lot.
Would be good to have a fix or a demo showing how to create a very low powered BT server.

[igrr]

@joicetm BLE power consumption improvements (i.e. modem sleep mode) are not planned for 3.0. 80-90mA is the best that can be achieved in the current version.

[MS-elug]

Do you know what is the release target for the modem sleep mode ? Where can we find the project roadmap and estimate dates?

[mobilinkd]

This is an important issue for me. I would be using the ESP32 in my project right now if I could run the ble_spp_server demo using less than 10mA.

[Yulong-espressif]

@MS-elug @mobilinkd The BLE modem sleep will be release at the next version(v3.1), thank you for your concern about ESP32.

[mobilinkd]

That's great news, @Yulong-espressif ! Are you able to characterize the current consumption with this enhancement?

[PromTZ]

Hi, I am using ESP-WROOM-32 with Arduino IDE. I want to know is there any way to reduce power consumption of BLE peripheral? I made a test on power consumption during BLE advertising which was consuming 112mA current when CPU set at 80Mhz. I want to reduce the current consumption to at least 1mA but BLE should keep on advertise. Please help me in this regards.

[devKlausS]

@Yulong-espressif can you tell us a release date for BLE modem sleep (version 3.1)? Moreover I would be interested in the current consumption in BLE modem sleep mode. We are planning to develop a low power product, therefore the current consumption is the most critical part of the project.

[sargun]

@Yulong-espressif Is BLE wakeup going to be in the next version?

[Yulong-espressif]

@sargun Yes, will be release in the version 3.1

[TianHao-Yoursmake]

Actually, both BR/EDR and BLE power save will be released in release/v3.1.

[joicetm]

Thanks for the update, TianHao-Espressif .

[frax84]

Features has been implemented few days ago. I tried it and it works. With the exactly same features (time interval=50ms, 15B per packet, notify enabled) power consumption passed from 102mA to 35-40mA. Data exchange is not fluid ad before, but don't know the cause.

[TianHao-Yoursmake]

@frax84 , the BLE/BR/EDR sleep current and related performance is in test.
But, due to the Bluetooth RF is shared with WIFI, so the average current will not be very low as single BLE IC.

And what "not fluid" present. Could you provide your test case?

[frax84]

@TianHao-Espressif Hi Tiao! Actually was not a complain but was just informing the others in this post. By the way, your explanation is very interesting. This is my use case:

• GATT server (no security)
• connection interval = 50ms (min 40 - max 60ms)
• no latency
• Payload = 15Bytes
• Data are all notified
• Antenna power set default
• The consumption i wrote about is not only esp32. I'm using esp32thing from Sparkfun with no mod (i.e. leds still on the board)
• in SDK i configured optimization for BLE (default was "balanced")

With the term "no fluid" i mean that while before (was using BLE with BTDM mode) data were coming evenly time-spaced ("1-2-3-4-5-6-7-8-9-10") now they tend to come less evenly spaced (i.e. "1-2---34--5-6-7--8---9-10"). I have not test data to show but what i'm saying is clearly visible with eye (while with previous settings it was ok)

I have two questions.

1. Is it possibile to completely disable WiFi in SDKconfig.h?
2. If yes, would this " disabling" would give any consumption improvements?

Thank you

EDIT: edited some typos and added more infos about my use case

[lucashutchinson]

Hi All,

I have been optimising our ESP32 application for low power at the moment.
I have eliminated a few power hogs in our code and incorrect configurations however i am running into a wall with bluetooth enabled.

The lowest consumption with BLE enabled (BT-classic disabled) is around 28-32mA when advertising with a 200ms interval
In the same application if BLE is not initialised, the power consumption drops to around 3.2mA.

Im just wondering if i am at the limit of what the ESP32 can currently do.
And if this is the case, is there any planned work to improve this during BLE-only modes?

I understand that as this chip supports BLE and WiFi the power consumption during transmit and Reception will be higher than a BLE only chip. However since BLE operates on the connection interval paradigm, if there is a 40ms connection interval or a 200ms advertising interval, surely the radio could be disabled between connection intervals saving power during these periods? This would likely result in a much lower average current.

Thanks in advance for your response.
@TianHao-Espressif @projectgus

[chegewara]

@lucashutchinson Did you try to change TX power? By default it is setup pretty high (+3dBm).

Remember that you can decrease TX power for advertising only if you want.

[Weijian-Espressif]

hi all:
Please confirm if bluetooth mode sleep is enabled in menuconfig.
Location: Component config -> Bluetooth -> Bluetooth controller -> MODEM SLEEP Options

[lucashutchinson]

Hi @chegewara @Weijian-Espressif

Yes I have tried changing the TX power between N12 and P9, no real difference was noticed. however i am going to do a few more tests.

I have enable bluetooth modem sleep options, and have tried both ORIG and EVED modes.
I have also enabled power saving in Component config -> Power Management
and also enable tickless idle in Component config -> FreeRTOS -> Tickless Idle

I have also called the functions:
esp_pm_configure and esp_bt_sleep_enable.
I have also tried a few different configurations for the esp_pm_configure, i do see a difference when changing the max processor speed from 240mhz to 80mhz.
the current values i mentioned above were @ 80mhz. when running at 240mhz I see around 50mA of current draw.

Do you have any internal test results of low power bluetooth that can be shared?

Thanks for your responses!

[mywang-espressif]

@lucashutchinson . 30mA is in accord with our internal test result for BLE advertising in current stage. In order to further optimize the bluetooth power consumption, we are trying to resolve the issue in the combination use of bluetooth modem sleep and Dynamic Frequency Scaling(DFS) as well as Automatic light sleep. which can hopefully be completed in a month.
The reason that you get a 3.2mA current compared to 30mA when BLE is inititalized is, currently bluetooth module will acquire a pm_lock during initialization and won't release it until deinit, and therefore the CPU frequency cannot be decreased to lower than 80MHz. After the we have resolve the issue for BT modem sleep with DFS and light sleep, you can expect an even lower power consumption.

[Alvin1Zhang]

@lucashutchinson Could you help share if any updates for this issue? Thanks.

[Alvin1Zhang]

@lucashutchinson Could you help share if any updates for this issue? Thanks.

[lucazader]

There are no updates that I have had from espressif.

[mywang-espressif]

Hi, a commit on optimization of Bluetooth power consumption was merged into ESP-IDF recently. The merge commit is(git describe --tag): v4.0-dev-684-gb859584. An external 32.768kHz crystal is required to take advantage of this feature.

Here is the description for this commit and a brief manual.

Feature: Bluetooth modem sleep with external 32.768kHz xtal under light sleep

Overview

Bluetooth modem sleep could work under DFS but could not work under light sleep in previous implementation, which is largely due to the sleep clock source. Sleep clock must provide enough accuracy for BLE to maintain time during sleep.

Main crystal is supposed to be powered down during light sleep. It can support DFS but not light sleep for Bluetooth modem sleep.
External 32kHz crystal as RTC clock, has good accuracy and can support both DFS and light sleep for Bluetooth modem sleep. Currently there is another hardware issue of External 32kHz crystal but it is supposed to be resolved in later chip version.
Other RTC clock sources, such as internal 150kHz oscillator or internal 8.5MHz oscillator, divided by 256 (8MD256 for short), do not provide enough accuracy as required by Bluetooth specification(worst-case BLE SCA is +/-500ppm, worst-case accuracy for Classic Bluetooth Low Power Oscillator(LPO) is +/-250ppm).

This patch resolves the issue that Bluetooth modem sleep is not allowed to work with light sleep with external 32kHz crystal. In this case a menuconfig option is provided to set the BLE SCA used to estimate RX window widening during connection events.

User guide

To use bluetooth modem sleep with light sleep, please follow the below instructions.

ESP-IDF menuconfig options:

1. Enable Power Management:
   menuconfig ---> Component config ---> Power management --->
   [*] Support for power management

2. Enable Tickless Idle:
   menuconfig ---> Component config ---> FreeRTOS --->
   [*] Tickless idle support
   (3) Minimum number of ticks to enter sleep mode for (NEW)

Note: Tickless idle needs to be enabled to allow automatic light sleep. FreeRTOS will enter light sleep if no tasks need to run
for 3(by default) ticks, that is 30ms if tick rate is 100Hz. Configure the FreeRTOS tick rate to be higher if you want to allow
shorter duration light sleep, for example:
menuconfig ---> Component config ---> FreeRTOS ->
(1000) Tick rate (Hz)

3. Configure external 32.768Hz crystal as RTC clock source:
   menuconfig ---> Component config ---> ESP32-specific --->
   RTC clock source (External 32kHz crystal)
   [*] Additional current for external 32kHz crystal

Note that the "additional current" option is a workaround for a hardware issue on ESP32 that the crystal can fail in oscillating.
Please enable this option when you use external 32kHz crystal. This hardware issue will be resolved in the next ECO chip.

4. Enable Bluetooth modem sleep with external 32.768kHz crystal as low power clock:
   menuconfig ---> Component config ---> Bluetooth ---> Bluetooth controller ---> MODEM SLEEP Options --->
   [*] Bluetooth modem sleep
   Bluetooth Modem sleep mode (ORIG mode(sleep with low power clock))
   Bluetooth low power clock (External 32kHz crystal)

Enable light sleep by calling power management API in application:

1. In your application source code, to enable automatic light sleep, use power management API esp_pm_configure like this:

#include "esp_err.h"
#include "esp_pm.h"

    esp_pm_config_esp32_t pm_config = {
        .max_freq_mhz = EXAMPLE_MAX_CPU_FREQ_MHZ, // e.g. 80, 160, 240
        .min_freq_mhz = EXAMPLE_MIN_CPU_FREQ_MHZ, // e.g. 40
        .light_sleep_enable = true, // enable light sleep
    };
    ESP_ERROR_CHECK( esp_pm_configure(&pm_config) );

Test result

Below are some power consumption statistics on typical BLE use scenario:

• MAX cpu frequency = 240MHz
  ADV(adv_interval = 1000.0ms) average current 3.05mA, max 149.34mA, min 0.71mA
  SCAN(scan_wiONndow = 500.0ms, scan_interval = 1000.0ms) average current 59.57mA, max 170.26mA, min 0.93mA
  CONNECTION(connection_interval = 960.0ms, slave_latency = 0) average current 2.07mA, max 152.28mA, min 0.81mA

• MAX cpu frequency = 160MHz
  ADV(adv_interval = 1000.0ms) average current 2.51mA, max 139.34mA, min 0.78mA
  SCAN(scan_window = 500.0ms, scan_interval = 1000.0ms) average current 50.37mA, max 134.85mA, min 1.08mA
  CONNECTION(connection_interval = 960.0ms, slave_latency = 0) average current 2.05mA, max 121.69mA, min 1.11mA

• MAX cpu frequency = 80MHz
  ADV(adv_interval = 1000.0ms) average current 2.55mA, max 114.81mA, min 0.79mA
  SCAN(scan_window = 500.0ms, scan_interval = 1000.0ms) average current 49.05mA, max 123.80mA, min 0.85mA
  CONNECTION(connection_interval = 960.0ms, slave_latency = 0) average current 2.11mA, max 106.01mA, min 0.94mA

[chegewara]

Hi @mywang-espressif
thanks for sharing this test results, good to know ble can finally works with light sleep.

Could you confirm some values? From what i see in some cases with MAX cpu frequency = 80MHz there is higher current draw than with MAX cpu frequency = 160MHz.
Also strange to me is this:

CONNECTION(connection_interval = 960.0ms, slave_latency = 0) average current 2.05mA, max 121.69mA, min 1.11mA

VS

CONNECTION(connection_interval = 960.0ms, slave_latency = 0) average current 2.11mA, max 106.01mA, min 0.94mA

Min and max values are lower, but average current draw is higher with 80MHz.

Anyway thanks for new feature and comprehensive update about it.

PS only what is missing is comparison with current draw without light sleep enabled.

[mywang-espressif]

Hi @chegewara , thank you for your question. I have confirmed the values and they are my test results. The inconsistency may be resulted from
the inaccuracy of testing instruments or some oscillating of RF power, or the maximum CPU frequency in the test cases do not have so much influence.

Below are the previous test results in which automatic light sleep is not enabled.

Power consumption using BLE when light sleep is not enabled and Dynamic Frequency Scaling is enabled, min frequency is 40MHz

MAX cpu frequency = 240MHz

* ADV(adv_interval = 800.0) average current 16.36mA, max 148.75mA, min 14.51mA
* SCAN(scan_window = 1280.0, scan_interval = 2560.0) average current 30.20mA, max 147.00mA, min 14.51mA
* CONNECTION(connection_interval = 1600.0, slave_latency = 0) average current 15.37mA, max 93.63mA, min 14.41mA

MAX cpu frequency = 160MHz

* ADV(adv_interval = 800.0) average current 15.99mA, max 98.98mA, min 14.82mA
* SCAN(scan_window = 1280.0, scan_interval = 2560.0) average current 26.85mA, max 127.29mA, min 14.62mA
* CONNECTION(connection_interval = 1600.0, slave_latency = 0) average current 30.71mA, max 143.40mA, min 14.62mA

MAX cpu frequency = 80MHz

* ADV(adv_interval = 800.0ms) average current 15.77mA, max 126.62mA, min 14.62mA
* SCAN(scan_window = 1280.0, scan_interval = 2560.0) average current 26.72mA, max 120.34mA, min 14.62mA
* CONNECTION(connection_interval = 1600.0, slave_latency = 0) average current 15.42mA, max 99.39mA, min 14.62mA

As we can see, the floor current(minimum current) when light sleep is enabled is about 1mA, and for DFS with minimum frequency = 40MHz is about 15mA.

[copercini]

@mywang-espressif Thanks for this update, does this only works with External 32kHz crystal or could work with External 32kHz oscillator at 32K_XP pin too?

[mywang-espressif]

@copercini , External 32kHz oscillator at 32K_XP pin is a option that generates the clock waveform by an external circuit, and in this case the external clock signal must be connected to 32K_XP pin. This option is not verified to be used as Bluetooth sleep clock, and menuconfig does not support this option to be used as bluetooth low power clock. To enable this option to be used as Bluetooth sleep clock, you must ensure that the clock accuracy/frequency stability is sufficient to be used as Bluetooth sleep clock(Classic BT worst case 250ppm, BLE worst case 500ppm) at first.

[Kemsa]

Hello, could you provide an example code to make it work? I have tried to make it work with bluetooth classic (and not BLE). To do so, I have:

• recovered the 4.0 beta idf version
• set an external 32kHz crystal, and I think it works (because the piece of code won't work if it is disconnected)
• I have followed all the steps given earlier
• I have used example_spp_acceptor_demo.c example file, adding the right pm_config.

The piece of code works OK, but the power consumption never goes lower than 30mA.
I am using the development board from adafruit, I am not sure if it has an impact or not...

[mywang-espressif]

Hi @Kemsa, to test whether bluetooth enters sleep, there are two functions that you can modify. In source file bt.c of ESP-IDF: btdm_sleep_enter_phase2_wrapper and btdm_sleep_exit_phase3_wrapper. The two functions are two hooks for bluetooth enters and exits from modem sleep. You can add some logic to toggle GPIO output in the two functions and use logic analyzer to see whether the signal toggles, or you add a global variable as a counter of bluetooth sleep.

For classic bluetooth example, the condition for connected device to enter modem sleep on ESP32 is to enter sniff mode. In bluedroid, sniff mode is entered after several seconds(for SPP, the value is 5s) of idle higher layer TX/RX, i.e. if the L2CAP packet transmission is paused for more than 5 seconds, the link can enter sniff mode and the device can enter modem sleep.
If the bluetooth link stays in active mode instead of sniff mode, then it is not allowed to enter modem sleep according to current sheme implemented.

[Kemsa]

Thanks @mywang-espressif for your answer. I have been able to detect the sniff mode: after a connection is established, I get 5 seconds with a 100mA power consumption, and then I go back to 30mA. So I at least have access to a simplified version of modem sleep. But the esp32 doesn't seem to go to light sleep.
I have tried entering light sleep manualy (without BT enabled), and I was able to obtain the promised 5mA in light sleep, but not in BT modem sleep. Is it possible that another process is taking CPU time in the example, so that FreeRTOS would never be idle? Like the serial connexion for instance?
Meanwhile I will try to make some modifications to bt.c to see if I indeed enter the right functions.

[chegewara]

Hi @mywang-espressif
i know its few months since you posted tests results and i somehow missed it, but i think its important.
How it is possible that SCAN without light sleep enabled is more efficient than in case bluetooth light sleep is enabled (about twice as much more efficient)?

[akumpf]

After a lot of testing, I can confirm that low power / modem sleep with BLE works on a TinyPICO (with the addition of a 32kHz crystal+caps and the suggested config options).

One major hurdle I ran into is making sure to set the min_freq_mhz to 80MHz in the pm_config struct; setting it down to 40 caused sporadic BT connection issues that were a major pain to track down.

I've also gone as high as 1000 ticks/sec with only 2 ticks to enter sleep mode and it seems to work fine. I'm running as a BLE server (based on the NimBLE heart rate example) so the biggest constraint in getting the device to sleep is limiting the connection interval of the client.

The TinyPICO plus a couple low power sensors gives a light sleep current around 2.0mA and around 75mA of current when BLE is advertising or communicating. With sleep happening between everything (and an advertising interval around 500ms and a connection interval around 85ms), I get around 4.2mA average when advertising and 10.6mA average when connected and relaying data to a client.

Those numbers aren't great for true low power BLE applications, but good enough that a typical business-card-sized LiPo battery (1200-2500mAh) should be able to keep things running for a week or so on a charge. 🤞

[m-owais]

Just for confirmation:
If I were to try the feature "Bluetooth modem sleep with external 32.768kHz xtal under light sleep" on the DevKitC or the Wrover 4.1 board, it will not work as they don't have the required external 32kHz crystal or oscillator on the board or inside the module.

[chegewara]

Just for confirmation:
If I were to try the feature "Bluetooth modem sleep with external 32.768kHz xtal under light sleep" on the DevKitC or the Wrover 4.1 board, it will not work as they don't have the required external 32kHz crystal or oscillator on the board or inside the module.

Thats correct.

[mywang-espressif]

@akumpf :
One major hurdle I ran into is making sure to set the min_freq_mhz to 80MHz in the pm_config struct; setting it down to 40 caused sporadic BT connection issues that were a major pain to track down.
Recently we are fixing a bug that can BLE connection cannot be maintained when using DFS/light sleep, the issue occurs in Bluetooth-WiFi coexistence scenario. Did you use BLE and WiFi together in your test?

[akumpf]

@mywang-espressif I used BLE only (no wifi). If I recall correctly, it would often connect and work for a while, but then be unreliable and drop the connection (after a few seconds to a few minutes). Not sure what was really going on, but once I set the min_freq_mhz to 80MHz the issued resolved completely.

[Montvydas]

So we do not need to add that resistor R4 in parallel as shown in Hardware Design Guidelines section 2.1.4.2 RTC (Optional)? Also what size caps would be recommended for 12.5pF CL crystal, because I read that people couldn't make it work with 2x12pF? Cheers!

[Ben79543]

I am using a ESP-WROOM-32 module (so no crystal), and trying to get decent consumption even without lightsleep. Even getting the value that @mywang-espressif obtained without lightsleep would be good enough for me (avg ADV = 15.7mA, avg SCAN 26mA).

Currently my program is under arduino, where I rebuilt all the librairies (arduino as a component) to manage menuconfig. I just need to beacon and scan at the same time, no connexion.

• I have enabled PM, tickless mode (not needed without sleep but ok), tried with ORIG or EVED modes, set power to N12 automatic DFS, and compile my prog at 80 MHz.

I get 41mA advertising only and 95 mA scanning. :-(

The one thing I could not do is to use the esp_pm_configure commands because it is rejected with arduino (sorry, unimplemented: non-trivial designated initializers not supported), but with Automatic DFS, that should not be needed, right?

Any idea What I am doing wrong? I need to go below 30mA to have a viable product...

[fredriklundstromublox]

One major hurdle I ran into is making sure to set the min_freq_mhz to 80MHz in the pm_config struct; setting it down to 40 caused sporadic BT connection issues that were a major pain to track down.
Recently we are fixing a bug that can BLE connection cannot be maintained when using DFS/light sleep, the issue occurs in Bluetooth-WiFi coexistence scenario. Did you use BLE and WiFi together in your test?

When was this fix added? Which branch(es) is it on?

[antoniuschan99]

Does anyone know if Espressif is actively working to lower ble power consumption? I would like to implement an Apple Tags/Tile like feature in the future.

[sch0bert]

@antoniuschan99 don't know but it will be nice if they could update their documentation based on their latest improvements in the IDF. Any news @mywang-espressif ?

[Fusseldieb]

The TinyPICO plus a couple low power sensors gives a light sleep current around 2.0mA and around 75mA of current when BLE is advertising or communicating.

Those numbers aren't great for true low power BLE applications, but good enough that a typical business-card-sized LiPo battery (1200-2500mAh) should be able to keep things running for a week or so on a charge. 🤞

Do you think that we can use the ULP to listen to the BLE connection and wake the main chip up when it wants to receive data? This would decrease power draw by a lot!

If not, would it be a technical limit or is it just not implemented (yet)?

Thanks.