Understanding Battery Life for Bluetooth BLE Devices

Recently, the industry association named EEMBC produced a new standard for IoT edge node benchmarking. IoTMark™-BLE, as it is called, allows microcontroller and module vendors to demonstrate the real energy usage of their BLE-enabled devices (Bluetooth Low Energy) in IoT edge nodes.

The emphasis is on the phrase "real energy usage." While all vendors spec out their device's transmit and receive power in datasheets, these numbers cannot be translated into energy values. BLE is a complex protocol with a variety of operational modes where the power changes over time (e.g. connection interval, advertising interval). Additionally, if the exact runtime details for transmitting and receiving are not specified in a datasheet (which they are not), it makes it nearly impossible to compare the power or the energy of one microcontroller and/or module to another.

Making the device comparison even more difficult is the fact that vendors can use any settings for transmitting power, which will also have a significant effect on a device’s energy usage. For example, LSR’s SaBLE-x Bluetooth BLE module is spec’d at 8.4mA transmit mode (+5 dBm), whereas the Silicon Labs EFR32 Blue Gecko BLE SoCs are spec’d at 8.5mA transmit mode (0 dBm). The methodology for the EEMBC IoTMark-BLE will help clarify these spec games.

Fundamentally, this benchmark suite, which includes a combined hardware + software framework, measures the energy used by the system while it performs relevant real-world tasks (as defined by the benchmark methodology). The framework is comprised of several hardware components: an energy monitor to measure energy, a radio manager to coordinate the communication with the device under test (DUT), and an IO manager to synchronize activities. The IO manager is also used to simulate a sensor input (e.g. accelerator, temperature, pressure) on the DUT’s I2C and/or SPI ports.

In the paragraph above, the operative phrase is "used by the system." We’re talking here about a system benchmark. As opposed to CPU benchmarks such as CoreMark, the IoTMark-BLE works on the system which is represented by the MCU, the BLE radio (often integrated into the MCU), the protocol stack, and relevant peripherals. This system benchmark requires hardware interaction to physically perform the radio transmit and receive functions, as well as the IO functions.

In EEMBC’s case, a Raspberry Pi board with a BLE shield was used as the radio manager and an Arduino was used for the IO manager (both inexpensive platforms). The challenge is coordinating the separate pieces of hardware used for the radio function, IO functions, and for synching the timing window for the energy measurement — this is handled by the host’s scripting program).

To establish a real-world environment for BLE usage, you must examine a cross-section of applications, such as health monitors, thermostats, toasters, and wearable devices, and see how they operate. Parameters such as payload size and payload transmission frequency, for example, can vary considerably. So since it’s impossible to represent every type of IoT edge node, the benchmark standard focuses on the lowest common denominator, sending and receiving a small packet once per second. The most important thing with IoTMark-BLE and any other benchmark for that matter is consistency to ensure repeatability and accuracy.

There has been an extremely high level of interest in this new benchmark, partly because there’s no other similar testing methodology and partly because of the popularity of IoT and BLE. At this point, we are waiting to see which vendor will be first to publish results and start including them in their datasheets as some have already done with benchmarks such as CoreMark and ULPMark. Whenever EEMBC releases a new benchmark, there’s always a period of time where members are determining how to optimize or ensure they are getting the best results possible. This is especially important for an ultra-low energy test where you’re checking for any unnecessary power draws from unused pins and proper sleep mode transitions.

Without going into explicit detail, the benchmark repeats a specific amount of work once per second (in addition to the BLE transmit and receive). During each second, the DUT must wake up and go back to sleep during periods of inactivity. Therefore, there might be tradeoffs to make based on how long it takes to come out of sleep as well as the ramp-up energy.

There is no question that BLE is one of the most popular communication protocols for low power IoT devices. Beyond BLE energy measuring, EEMBC is evaluating how to next pursue a similar testing strategy for 802.11ah or Wi-Fi HaLow, Thread, or LoRA. The current hardware/software framework is flexible enough to support most of these other protocols with limited effort. Having support for these additional protocols will also help to answer the top-level question — what is the most efficient IoT communication protocol?

This article originally appeared in the Bodo’s Power Systems magazine.