IoT Power Budget Modelling: A Spreadsheet That Predicts Battery Life

A power-budget spreadsheet is the cheapest way to know if an IoT product will hit its battery life target before you spin the first PCB. The spreadsheet is small, the math is high-school, and the discipline pays back tenfold. Here is the version we use on every project.

The columns

Each row of the spreadsheet is an operational mode. Each column is a contributor to current draw or duration.

Mode	Duration per cycle	Frequency per day	I_sleep	I_active	Charge per day
Sleep (idle)	continuous	1	3 µA	—	I_sleep × 86400s
Sensor wake	3 ms	1440	—	4 mA	I × t × N
BLE event	3 ms	86400	—	7 mA	I × t × N
…	…	…	…	…	…

Sum the “Charge per day” column. That is the daily charge consumption in coulombs (or mAh × 3.6).

Battery capacity divided by daily charge gives you days of life. Multiply by a derating factor (~0.85 for cold-temperature performance and end-of-life voltage cliff) and you have a defensible estimate.

A worked example

Imagine a connected sensor:

• Wakes once per second to read a sensor (3 ms active at 4 mA)
• Holds a BLE connection with 1-second connection interval (3 ms event at 7 mA)
• Sleeps the rest of the time at 3 µA
• Runs on a CR2032 coin cell, derated to 210 mAh

The spreadsheet:

• Sleep contribution: 3 µA continuous → 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: 36 µA

Battery life = 210 mAh / 0.036 mA = 5,833 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 doesn’t, one of the inputs was wrong, and the spreadsheet tells you where to look.

This same calculation is in our BLE battery post. The point of repeating it: every IoT engineer should be able to do this on the back of an envelope before they write firmware.

The mistakes that bite

Three classes of error account for almost every “we missed our battery target”:

1. Components forgotten

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. Sensors have their own sleep states.

The fix: make a power inventory of every component on the board. List its current in each operating state. Sum the deep-sleep currents — that is your floor.

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. If the spreadsheet meets the target with worst-case, your typical reality will exceed it.

3. Protocol overhead and tail 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 behaviour in ways that are hard to predict from theory. Pairing and bonding events are expensive but usually rare.

The fix: profile real radio behaviour with a current probe (Otii, Power Profiler Kit, Nordic PPK2) and compare to your model. The gap teaches you what you missed.

The 80/20 of optimisation

Once the spreadsheet is honest, the levers in rough order of leverage:

1. Increase BLE connection interval. Doubling the interval halves the connection-event current with a corresponding latency cost. Most products tolerate 1-second intervals; aggressive ones tolerate 4–7 seconds.

2. Use slave latency. A connected device skips connection events when it has nothing to send. Done correctly, you get most of the longer-interval benefit without the latency cost.

3. Reduce wake frequency. A sensor sampled at 10 Hz uses 10x the wake current of one sampled at 1 Hz. Sample only as fast as the application needs.

4. Use deep sleep aggressively. A few extra microamps in light sleep multiplied by months is days of lost runtime. Pick the deepest sleep mode that preserves what you actually need.

5. Disable status LEDs. A 5 mA LED running continuously is often bigger than your radio budget on a coin cell. Use it briefly or not at all.

6. Reduce sensor active time. Many sensors have low-power oversampling modes that sit between “off” and “max”. The ones with adjustable IDD are usually right.

What a good design verification looks like

For a battery-powered IoT product:

• Power-vs-time trace over a full duty cycle, captured with a power profiler. This is the reality check.
• Average current measured over 60+ seconds — long enough to capture multiple connection events.
• Current at temperature extremes — at least at the corners of the operating range.
• Battery discharge curve with the actual battery, the actual chemistry. CR2032 in particular has a soft discharge curve that affects when the radio voltage drops out.
• End-of-life behaviour. 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 make your battery claims defensible — to your customer, to your investors, to your support team.

What we hand over

For every battery-powered IoT engagement we ship:

• A power-budget spreadsheet, with cells for each contributor and a reality-check column comparing model to measurement
• A current-trace report showing measured behaviour versus the model
• A battery-life curve at three temperatures (cold, room, hot)
• Recommended BLE connection parameters with the trade-offs documented
• A power-aware firmware architecture document showing how the application avoids waking unnecessarily

If your battery life is not where it needs to be — or if you are about to spin a board and want a model that predicts it before commit — we have built and verified these models on dozens of products.