BLE power consumption optimization: The comprehensive guide

BLE power consumption optimization: a comprehensive guide on how to achieve maximum battery life for your BLE device

In my search to find a comprehensive guide for maximizing power efficiency for Bluetooth low energy devices, I found multiple guides from different vendors. These guides were great, but were more focused on specific chips and modules from the vendors. My goal here is to summarize the findings and make this a comprehensive guide for anyone looking to optimize power consumption for a BLE device – no matter which vendor you end up choosing.

Introduction

Many new electronic products – whether consumer, medical, industrial…etc – are moving towards being powered by batteries. Some of the reasons behind this:

  • Modules and chips are becoming more power efficient, so more applications and use-cases can be run on battery-powered devices without requiring the end user to change the battery too often (think 6+ months).
  • The explosion of the Internet of Things applications and devices, where data is being captured for all types of environments and scenarios, requiring more flexibility and use of completely wireless solutions.
  • Chips and modules are becoming much smaller physically allowing you to embed them within small devices.

With all battery powered devices, power consumption and battery usage optimization is a main concern. At a high level, power consumption is mainly decreased in microcontroller applications, and embedded systems in general, by reducing radio communication and increasing sleep/idle cycles as much as possible. In theory, this sounds simple and straight-forward. However, when trying to accomplish this in practice, it is much more complicated. For example, variables such as the changes in environment (temperature, humidity, obstacles and radio interference causing transfer retries) make the task exponentially more difficult.

There are three main areas that can be optimized to achieve optimum power consumption:

  • Choosing the right hardware components – including the battery.
  • Optimizing the firmware via static configurations (such as peripheral bus speeds and pin configurations) and dynamic/run-time parameters (such as Bluetooth low energy parameters).
  • Optimize firmware source code in terms of both: writing efficient code and using the right compiler optimizations (for speed and size) can help you achieve your low power goals. This also includes your system design for protocol efficiency and packet sizes being transferred over the air or to/from external peripherals.

In this post, I’ll be focusing on Bluetooth low energy applications and devices and how to optimize the different BLE parameters.

Again, it all basically comes down to how long your MCU spends in idle/sleep mode vs. active mode. User experience is the most important in determining the changes and parameters that could potentially affect power consumption. Make sure it’s always the top priority for your product.

Tuning BLE parameters

Optimization is achieved by tuning the parameters for the two states of a BLE device:

  • Connected state
    • Connection interval (connInterval):
      • Ranges from 7.5 milliseconds to 4 seconds (in multiples of 1.25 milliseconds).
    • Slave latency (connSlaveLatency):
      • Allows a slave to skip connection events without the central device dropping the connection. Thus, a slave device can skip several connection events if it does not have additional data resulting in power savings.
      • The Slave latency ranges from 0 to ((connSupervisionTimeout/ connInterval) – 1).
      • A slave latency of 0 means the slave is not allowed to skip any connection events.
    • Connection supervision timeout (connSupervisionTimeout):
      • Defines the maximum time between two received Data Packet PDUs before the connection is considered lost. The connSupervisionTimeout shall be a multiple of 10 ms in the range of 100 milliseconds to 32.0 seconds and it shall be larger than (1 + connSlaveLatency) * connInterval.
  • Advertising state
    • Advertising interval:
      • Ranges from 20 milliseconds to 10.24 seconds. The longer the interval, the less current the device will consume during the advertising state. This is a more important parameter when working with broadcast-only devices such as beacons.
      • For connected-devices, increasing the advertising interval will have a limited impact on battery life savings after a certain point: the current consumption will be lower during the advertising state, however, the central will take longer to find the advertising device causing the advertising period to be higher (which may lead to higher power consumption than in the case where the advertising interval is shorter).
      • For some scenarios, it may be beneficial to advertise periodically instead of advertising all the time. The advertising period can then be tuned to achieve the optimal user experience.
    • Advertising data length:
      • Another parameter that affects the current consumption during advertising is how many payload bytes are sent in each advertising packet. Therefore, it may be beneficial in terms of current consumption to only place primary advertising data in the advertising packet and place all secondary data in the scan response packet, as advertising packets are sent much more frequently than scan response packets.

If you plan to transfer data in large bursts you may exceed the recommended peak, which may negatively impact both the capacity and lifetime of the battery. For sending large quantities of data, look for ways to optimize the transfer:

  • Adjust connection intervals, advertising intervals and slave latency parameters accordingly.
  • Combine small packets into fewer large ones.
  • Compress data before transmission.
  • Send lower priority data at slower rates.
  • For sensor-based devices, only measure and prepare data if the client has subscribed to the associated characteristic. The same is true on the other side (on the client/mobile side), only subscribe to characteristic that you’re interested in.
  • Consider how much of the time the device will be used. If the device will mostly stay in the idle state, then focus on optimizing the sleep-state power consumption as much as possible. Conversely, if the device will be active most of the time, then focus on reducing the active-state current draw.

One last thing to keep in mind is to test with debug mode turned off since power consumption will usually be higher than with debug turned off.

What to measure?

It is not possible to compare the power consumption of a BLE device to another using a single metric. Sometimes a device gets rated by its “peak current”. While the peak current plays a part in the total power consumption, a device running the BLE stack will only be consuming current at the peak level while it is transmitting.

Even in very high throughput systems, a BLE device is transmitting only for a small percentage of the total time that the device is connected. In a typical application, a device running the BLE stack will spend most of the time in a sleep state between connection events. The primary metric that takes these other time and current measurements into account is the “average current”. It is this value that can be used to determine the battery life of a BLE device.

Note that a single “average current” value cannot be given for a device in its datasheet or in the device’s specifications, as the average current is highly dependent on the connection parameters used. Any time an “average current” specification is given, it is very important to understand the exact use-case in which the measurement was made.

With that said, here are some other useful metrics that should be kept in mind:

  • Peak current: useful when comparing to what the battery vendor indicates as the recommended maximum peak – going above the value may negatively impact the capacity and lifetime of the battery.
  • How much power is used to transfer a certain amount of data
  • Sleep-state current consumption

How to measure?

Now, let’s talk about testing the power consumption of your device. The most important thing is to make sure you test in an environment as close as possible to what a user’s environment would be like (real-life testing and not just in a lab setting). This will make your estimations much closer to real-life usage and ultimately make your users much happier.

  • The simplest way to measure current with an oscilloscope is to use a current probe and directly monitor the current going into the system.
  • If you do not have a current probe available, an easy alternative is to use a small resistor in line with the power supply input to the system. You can then use a standard oscilloscope voltage probe to measure the voltage across the resistor, and effectively measure the current by dividing the voltage by the resistance. A good resistor value to use is 10 Ω, as this value is small enough that it shouldn’t affect the existing circuitry, and large enough to provide a voltage that can be measured with decent precision (in addition, using a value of 10 Ω makes the calculations very simple).
  • When performing measurements, it is best to use a regulated DC power supply as opposed to an actual battery. This eliminates variables that might be caused by a defective or low battery.
  • Other methods of measurement include specialized hardware and software solutions provided by the vendor of the chip/module you’re using. For example, Silicon Labs provides the Energy Profiler tool as part of Simplicity Studio. Nordic Semiconductor provides the Nordic Power Profiler Kit (PPK). 

Summary and Closing

In the end, each application will dictate how low your device’s power consumption can get. If the parameters are modified to a point where they negatively affect the user experience then this will not help your product or users. Always keep the user experience (UX) as the top priority and design the system (including power optimization) in a way to enhance the UX.

Finally, I will leave you with a summarized list of points/questions to keep in mind when optimizing your BLE device’s power consumption:

  • How long will it run on a coin cell battery?
  • What’s the current draw at peak usage?
  • How much power is used to transfer a certain amount of data?
  • How much data does the app need to transfer?
  • How often does it need to transfer data?
  • The battery capacity declared by the manufacturer is in ideal conditions.
  • Keep in mind that longer periods of peak current draw can affect/damage the battery.
  • If the power source is current-limited, then peak current is just as important as average current.
  • If you plan to transfer data in large bursts you may exceed the recommended peak current, which negatively impacts both capacity and lifetime of the battery.

By | 2017-10-01T07:40:53+00:00 April 24th, 2017|Categories: BLE technology|Tags: , , |0 Comments

About the Author:

Mohammad Afaneh
Mohammad has a strong passion for developing Bluetooth Low Energy and IoT applications. He helps developers develop for BLE faster through detailed technical tutorials, articles, and videos. He enjoys playing sports, spending time with his wife and kids, and reading non-fiction books. Connect with him on LinkedIn at https://www.linkedin.com/in/mafaneh.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.