ESP32 Forum

Hi,

Is it possible to implement a battery-powered BLE device with low power consumption right now (a beacon, for example)? I have disabled the Wifi from menuconfig, but the device still heats up while running BLE examples (both esp-idf and Arduino).

HITMAnsOFT wrote:Hi,

Is it possible to implement a battery-powered BLE device with low power consumption right now (a beacon, for example)? I have disabled the Wifi from menuconfig, but the device still heats up while running BLE examples (both esp-idf and Arduino).

You need to implement sleep mode stuff and very probably move the clock speed down (At 240 MHz, the ESP32, while it's not power hungry, per se, is sort-of so in the continuous on and peak clock mode...)

Once there, you probably can manage battery operation pretty good. Consumption on the full power mode is still decent. It's not AA cell levels for months, but it's very doable for days of sporadic operation and hours of continuous off of AA cells. It'd last a LONG time off of Li-Ion cells.

Thanks for your answer! As far as I can see in the examples, the only sleep mode currently implemented is the deep sleep mode, which is too costly to wake up from 2-5 times a sec(it's almost a full reset). Also the CPU does not consume that much compared to the radio module (I did some experiments with Wi-Fi/BT on/off, also starting/stopping Wi-Fi at runtime), and if you use vTaskDelay, the FreeRTOS seems to manage the CPU power quite right. Please correct me if I'm wrong.

I think my question should be rephrased: Is the Bluetooth hardware able to operate in low-power mode? Currently only the BTDM mode is supported, which I suspect may be the reason for high power consumption.

I have some experience with nRF51, which is what I unconsciously compare everything against. (Disclaimer: I'm not working for or affiliated with Nordic ) There is much more hardware included in the ESP32, and I hope that it will become flexible enough to be competitive with dedicated solutions in terms of energy efficiency.

It's less that you've got Dual Mode that there's power consumption. Classic and LE simultaneous doesn't consume much more juice than LE by itself.

Real differences between LE and Classic:

- Channel Hopping Sequence is simplified. For Advertising it's not really hopping
- Modulation Index changed from Classic to LE to allow a bit better performance at range
- Channel spacing widened from 1->2MHz, reducing the number of channels from 79 to 40
- Connection latency shrunk to next to nothing.
- Packets are generally limited to ONE 625 us slot in size

LE is predicated on waking up, transacting or being transacted and getting the PA's off on the transmit side as fast as you can. But I suspect you knew this all- that was for the rest of the forum to learn a little bit where they might not understand the conversation.



Now...as I said, there's probably not a lot of power consumption from DM operation. The lowest levels of function on the BT stack in an ESP32 is handled mainly by VHDL specified logic rather than CPU code- which is where most the DM specific behaviors are defined and driven. Where much of the consumption (and the "warm" both of us have observed...) is because a lot of the power domains are fully powered- especially the CPUs. I agree, Deep Sleep is probably too disruptive to use for anything either of us are working on (Since we both appear to be doing LE related stuff... ). However, according to this conversation:

viewtopic.php?f=13&t=770

...if one can get the CPU to sit idle/blocked for I/O, the CPU domain for that given core will idle down until it's woke up by interrupt. Sounds like where most of the power gains are going to be obtained without doing Deep Sleep. Makes sense. Have one semi-idle, handling things like WiFi and BT, the events there are in tenths of a second to seconds apart for most anything battery powered. The CPUs would mostly sit quietly and wait to be woke up to full speed. Which can be as much as 240MHz for both cores. I can imagine that those cores are eating juice like candy comparatively.

FYI: The BT(LE) drivers in esp-idf as of now aren't optimized for power yet, so while the hardware should support low-power modes, there's no software to use them yet. We're working on getting the needed changes, however.

ESP_Sprite wrote:FYI: The BT(LE) drivers in esp-idf as of now aren't optimized for power yet, so while the hardware should support low-power modes, there's no software to use them yet. We're working on getting the needed changes, however.

Indeed, the esp-idf is evolving quite fast! Keep up the good work. Meanwhile I have a lot to learn. Hope that the Android 5+ GATT issues will be resolved soon. ESP32 has the potential to be THE killer chip!

Totally agree with you, @madscientist_42. What I'm saying is that while the power management is not ready, more hardware means more power consumption, and only the CPU without any radio enabled runs much cooler than when I enable the Bluetooth stack. Still, the duty cycle of CPU tasks should be kept pretty low. BTW I really need to put together a current measurement circuit with a voltage output to a scope when things get serious, my Biological Fingertip Thermometer is not a precise power analyzer tool

ESP_Sprite wrote:FYI: The BT(LE) drivers in esp-idf as of now aren't optimized for power yet, so while the hardware should support low-power modes, there's no software to use them yet. We're working on getting the needed changes, however.

Yeah, most of the hardcore types in the forums "get" it.

Thanks for the insights. It's appreciated.

HITMAnsOFT wrote:Totally agree with you, @madscientist_42. What I'm saying is that while the power management is not ready, more hardware means more power consumption, and only the CPU without any radio enabled runs much cooler than when I enable the Bluetooth stack. Still, the duty cycle of CPU tasks should be kept pretty low. BTW I really need to put together a current measurement circuit with a voltage output to a scope when things get serious, my Biological Fingertip Thermometer is not a precise power analyzer tool

We're basically saying the same things. I think, though, it can be helped at least some. We know one of the management tricks in hand. The other one would be to pin the CPU's ears back a bit, clock it down where we can get away with it. Each joule does count on battery...so if I can enforce idling where I can, run at lower speeds for at least one of my projects, I can start evaluating battery function better when I'm actually ready- which may well be before they're ready with the better management answers on things.

And, yeah, the both of us need to do the scope thing. Fingertips really aren't good temp-probes like you said... (Guilty as charged as well as you there... )

ESP_Sprite wrote:FYI: The BT(LE) drivers in esp-idf as of now aren't optimized for power yet, so while the hardware should support low-power modes, there's no software to use them yet. We're working on getting the needed changes, however.

When can we expect low-power features in esp-idf?