Calculating BLE Battery Life: A Practical Worked Example

“How long will the battery last?” is the most common question on a BLE product. It is also the question with the most hand-waved answers. Here is the actual model we use, with a worked example, that will get you within 10% of measured reality before you build the first board.

The variables that matter

Battery life on a BLE device is determined by a small number of parameters that combine in a deterministic way:

• Sleep current: what the chip and its peripherals draw when nothing is happening.
• Active current: what they draw during processing, sensor reads, or radio activity.
• Active duration: how long each “wake” lasts.
• Wake frequency: how often the device leaves sleep.
• Radio events: advertising intervals or connection intervals, plus the cost per event.
• Battery capacity: in milliamp-hours, derated for chemistry and temperature.

The formula is conceptually simple: average current equals time-weighted sum of all currents. Battery life equals capacity divided by average current. Where teams go wrong is forgetting one of the components or using a current value from a happy-path datasheet.

A worked example

Imagine a BLE-connected sensor that:

• Wakes once per second to read a sensor (3 ms active at 4 mA).
• Holds a BLE connection with 1-second connection interval (peak event lasts ~3 ms at 7 mA).
• Sleeps the rest of the time at 3 µA.
• Runs on a CR2032 coin cell with usable capacity of ~210 mAh (after derating from the spec sheet’s 240 for low-temperature behavior and end-of-life voltage).

Calculate the average current contributions:

Sleep: 3 µA, continuous → contributes 3 µA average.

Sensor wake: 4 mA × 3 ms / 1000 ms = 12 µA average.

BLE event: 7 mA × 3 ms / 1000 ms = 21 µA average.

Total average: 3 + 12 + 21 = 36 µA.

Battery life: 210 mAh / 0.036 mA = ~5,800 hours = ~243 days = ~8 months.

That is the model. If the device measures within 10% of this in real testing, the design is honest. If it measures very different, one of the assumptions was wrong, and you have a list of suspects.

What the model usually misses

Three classes of error account for most “we missed our battery target” outcomes:

1. Forgotten components.

The MCU and the radio are not the only things on the board. LDOs have quiescent current. External flash chips have idle current. LEDs that “are off” may be drawing pull-up current. RTC crystals draw nanoamps that add up over months. Sensors have their own sleep and active currents that may dominate the radio in certain duty cycles.

The fix: make a power inventory of every component on the board, with its current in each operating state. The total in deep sleep should match the sleep current you assumed.

2. Optimistic datasheet numbers.

The “typical” current in a datasheet is often the manufacturer’s best case. Production devices vary. Temperature shifts numbers up at extremes. Aging shifts them up over years.

The fix: design with worst-case (max-spec) currents, not typical. If your battery life target is met with worst-case, your typical reality will exceed it.

3. Overhead and protocol effects.

BLE in connected mode has supervision timeouts, slave latency, and connection parameter updates that all draw extra current. Advertising intervals interact with phone scanning behavior in ways that are hard to predict from theory. Pairing and bonding events are expensive but usually rare.

The fix: profile real radio behavior with a current probe (Otii, Power Profiler Kit, or equivalent) on a real connection in a real environment. Compare to your model. The gap is informative.

The 80/20 of battery optimization

In rough order of leverage, the levers that move battery life on a BLE device:

• Increase connection interval. Every doubling of the connection interval halves connection-event power, with a corresponding latency cost. Most products can tolerate a 1-second interval; aggressive products tolerate 4-7 seconds.
• Use slave latency. A connected device can skip connection events when it has nothing to send. Done correctly, this gives most of the power benefit of a longer interval without the latency cost.
• Reduce wake frequency. A sensor sampling 10 Hz uses 10x the wake power of one sampling 1 Hz. Sample only as fast as the application needs.
• Use sensor sleep modes. Modern AFEs have sub-microamp sleep modes. Use them.
• Disable the LED. A status LED at 5 mA continuously is bigger than your radio budget on a coin cell. Use it sparingly, briefly, or not at all.
• Use deep sleep aggressively. A few extra microamps in light sleep multiplied by months is days of lost runtime. The deepest sleep mode that preserves what you need is the right choice.

What to actually measure

A respectable design verification:

1. Current vs time trace over a full duty cycle, captured with a power profiler. This is your reality check.
2. Average current over 60+ seconds — long enough to capture multiple connection events and any periodic effects.
3. Current at temperature extremes, at least at the corners of your operating range.
4. Battery discharge curve with the actual battery, the actual chemistry. Coin cells in particular have a soft discharge curve that affects when the radio voltage drops out.
5. End-of-life behavior. Does the device gracefully degrade or hard-crash when the battery hits the cliff?

Each of these can be done with a few hundred dollars of equipment and a day of time. They will make your battery claims defensible.

What we hand over

For BLE products, our default deliverables include:

• A power model spreadsheet, with cells for each contribution and a reality-check column.
• A current-trace report showing measured behavior versus the model.
• A battery-life curve at three temperatures.
• Recommended BLE connection parameters with the trade-offs documented.

If your BLE product’s battery life is not where you need it to be and you are not sure why, the model usually tells us where to look.