How to Build a Battery Power Budget for STM32WBA BLE Devices

STM32WBA microcontroller with battery and power measurement tools on an engineering workbench

You can estimate your STM32WBA battery life to within 20% accuracy using nothing but a spreadsheet, a datasheet, and about an hour of work, yet most teams skip this step entirely. They prototype first, measure later, and discover their “two-year battery life” product actually dies in four months. The fix at that point is expensive: different battery, different connection parameters, maybe a board respin.

An STM32WBA power budget built before your hardware arrives gives you the ability to make those decisions when they’re cheap, during design, not after production. Here’s how to build one from scratch.

We’ll construct a spreadsheet-based model, row by row, using real numbers from ST’s documentation. This isn’t a replacement for bench measurement. It’s a planning tool that gets you to the right ballpark and gives you a framework to refine as your firmware matures. By the end, you’ll have a working method you can apply to any STM32WBA BLE product.

The One Power Mode Decision That Dominates Everything Else

A BLE device spends 99%+ of its time not transmitting. That means your choice of idle power mode isn’t just important; it’s the single biggest lever in your entire STM32WBA power budget. Get this wrong and no amount of radio optimization will save you.

The STM32WBA offers five relevant power modes, each trading current draw against wake-up speed and context retention:

| Mode        | Typical Current | Wake-Up Time | RAM Retained |
|-------------|-----------------|--------------|--------------|
| Run @32MHz  | ~8 mA           | N/A          | Yes          |
| Sleep       | ~3 mA           | ~1 µs        | Yes          |
| Stop 1      | ~5 µA           | ~10 µs       | Yes          |
| Standby     | ~0.3 µA         | ~ms range    | Partial      |
| Shutdown    | ~0.08 µA        | ~ms range    | No           |

Here’s what those numbers mean in practice. Stop 1 mode is the workhorse for BLE applications. It draws roughly 5 µA, retains full SRAM contents, and wakes fast enough (~10 µs) for the BLE stack to resume without missing connection events. The BLE link layer timer can run during Stop 1, which means the radio wakes on schedule to handle advertising or connection events, then the MCU drops right back to sleep.

Standby and Shutdown draw less, but they cost you. Standby retains only backup registers and select SRAM, so your BLE stack context is gone. You’re essentially rebooting the stack on each wake. Shutdown is even more aggressive: full cold start, no retention. These modes make sense for devices that advertise once every 10+ seconds with no persistent connections, but they’re impractical for connected BLE applications.

Sleep mode at ~3 mA is almost never the right idle state for battery-powered products. It’s 600× higher than Stop 1. If you see your device idling in Sleep instead of Stop, that’s your biggest optimization opportunity.

For the rest of this guide, we’ll assume Stop 1 as your baseline idle mode. Pull the exact figures for your specific STM32WBA variant from the datasheet (DS14198, latest revision). These typicals vary slightly across the WBA52/WBA55 family.

Breaking BLE Activity Into Measurable Current States

The core idea behind a power budget is simple: decompose your device’s entire operation into discrete states, each with a known current draw and time duration. Then compute the time-weighted average.

For a typical STM32WBA BLE device, your states look like this:

  • Sleeping (Stop 1): The baseline state between all events. This is where your device spends the vast majority of its time.
  • Advertising TX: The radio transmits advertisement packets on up to three channels. Brief bursts, typically ~1.5 ms per event.
  • Advertising RX (scan window): Immediately after each TX, the radio listens briefly for scan requests or connection requests. About ~1 ms.
  • Connection event TX/RX: Once connected, the device exchanges data with the central during scheduled connection events. Duration depends on payload size, typically ~2.5 ms.
  • Sensor read: Your application reads a sensor over I2C/SPI, taking the MCU into Run mode with peripherals active.
  • Application processing: GATT attribute updates, data formatting, any computation your firmware performs.

Here are starting-point estimates based on ST’s application notes and datasheet figures:

| State               | Current  | Duration per Event |
|---------------------|----------|--------------------|
| Stop 1 (sleeping)   | 5 µA     | (remainder)        |
| Advertising TX      | ~10 mA   | ~1.5 ms            |
| Advertising RX      | ~9 mA    | ~1 ms              |
| Connection Event    | ~10 mA   | ~2.5 ms            |
| Sensor Read (I2C)   | ~6 mA    | ~5 ms              |
| App Processing      | ~8 mA    | ~2 ms              |

A simple timing diagram helps visualize this. Most of the time, nothing is happening:

Time -->
|<---------------- 1 second ----------------->|
|ADV|         SLEEP          |ADV|   SLEEP    |
|2.5|         497.5          |2.5|   497.5    |  (ms, advertising every 500ms)

Every 30 seconds, a connection event and sensor read appear:
|ADV|SLEEP|CONN|SENS|PROC|..........SLEEP..........|ADV|...

These values are starting estimates. Your advertising TX current depends on output power level (+0 dBm vs +10 dBm). Your sensor read duration depends on the specific sensor. Replace these with real numbers as you learn them. The spreadsheet structure stays the same.

Building Your STM32WBA Power Budget Spreadsheet, Column by Column

This is where everything comes together. Open a spreadsheet and create six columns:

  • A — State Name: What the device is doing
  • B — Current Draw (mA): From the datasheet or measurement
  • C — Duration per Occurrence (ms): How long each event lasts
  • D — Occurrences per Second: How often this event happens (use fractions for slow events)
  • E — Time in State per Second (ms): Calculated as C × D
  • F — Charge per Second (µC): Calculated as B × E (since mA × ms = µA·s = µC)

The sleep row is special: its time-per-second is whatever’s left over after all active states are accounted for. Set column E for sleep to 1000 - SUM(all other E values).

Here’s a complete worked example. Our device is a BLE sensor that advertises every 1 second, connects and reads a sensor every 30 seconds:

| State            | Current | Dur   | Occ/sec | Time/sec | Charge/sec |
|                  | (mA)    | (ms)  |         | (ms)     | (µC)       |
|------------------|---------|-------|---------|----------|------------|
| Stop 1 (sleep)   | 0.005   | --    | --      | 985.5    | 4.93       |
| Adv TX           | 10      | 1.5   | 1       | 1.5      | 15.00      |
| Adv RX           | 9       | 1.0   | 1       | 1.0      | 9.00       |
| Conn Event       | 10      | 2.5   | 0.033   | 0.083    | 0.83       |
| Sensor Read      | 6       | 5.0   | 0.033   | 0.167    | 1.00       |
| App Processing   | 8       | 2.0   | 0.033   | 0.067    | 0.53       |
|------------------|---------|-------|---------|----------|------------|
| TOTAL            |         |       |         | 1000.0   | 31.29      |

The total charge per second, 31.29 µC, is numerically equal to your average current: 31.29 µA.

Compute battery life with this formula:

Battery Life (days) = Battery Capacity (mAh) × 1000 ÷ Average Current (µA) ÷ 24

For a CR2032 coin cell with 225 mAh usable capacity:

225,000 ÷ 31.29 ÷ 24 ≈ 300 days

Notice where the power actually goes. Sleep accounts for only 4.93 µC despite occupying 98.5% of the time. Advertising, just 2.5 ms per second, consumes 24 µC, nearly 77% of your total budget. This is why advertising interval is the most sensitive parameter in most BLE power budgets.

Here’s what happens when you adjust it:

| Adv Interval | Avg Current | CR2032 Life (days) |
|--------------|-------------|--------------------|
| 500 ms       | ~55 µA      | ~170               |
| 1000 ms      | ~31 µA      | ~300               |
| 2000 ms      | ~19 µA      | ~490               |

Doubling the advertising interval from 1 to 2 seconds doesn’t halve your current (because sleep and connection overhead remain), but it does add roughly 6 months of battery life. That’s the kind of trade-off this spreadsheet makes visible before you’ve soldered a single component.

You can apply the same sensitivity analysis to connection interval. If your sensor data is latency-tolerant, connecting every 60 seconds instead of 30 cuts the connection-related overhead in half, saving roughly 1.2 µC/sec. A smaller gain than advertising tuning, but it adds up.

Accounting for the Stuff Datasheets Don’t Emphasize

Your spreadsheet now gives you a theoretical number. Real-world STM32WBA battery life will be worse. Here’s why, and how to compensate.

DC-DC vs. LDO: The STM32WBA includes an optional SMPS (switched-mode power supply) that’s significantly more efficient than the default LDO regulator during active modes. If you’re using the LDO, your run-mode current could be 20-30% higher than the figures above. Check your hardware design; SMPS requires specific external components.

Temperature: CR2032 capacity drops dramatically below 0°C. A cell rated at 225 mAh at 20°C might deliver only 100–120 mAh at -10°C. If your product operates outdoors, derate capacity accordingly using the battery manufacturer’s curves.

Battery self-discharge: CR2032 cells lose roughly 1% capacity per year. Negligible for a 1-year product, meaningful for a 5-year target.

Firmware overhead: ISR entry/exit latency, BLE stack housekeeping, RTC calibration. These add small but nonzero current that your state-based model may miss.

The practical answer: Apply a 20–30% safety margin to your calculated average current.

Adjusted: 31.29 µA × 1.25 = ~39 µA → 225,000 ÷ 39 ÷ 24 ≈ 240 days on a CR2032.

That margin gives you room for real-world factors without requiring you to model each one individually at the planning stage.

Validating the Spreadsheet Against Actual Hardware

A spreadsheet is a model. Models are wrong; the question is whether they’re useful. Yours becomes useful when you validate it.

Once you have prototype hardware, measure each state individually using a current profiler: the STM32 Power Shield (X-NUCLEO-LPM01A), Nordic PPK2, or Qoitech Otii Arc all work well. These tools capture the fast current transients that a multimeter will miss.

Measure each row of your spreadsheet separately: advertising current, connection event current, sensor read current, and especially your sleep baseline. Then run a long-duration average (hours, not minutes) and compare to your spreadsheet’s prediction.

If the measured average is within 20% of your prediction, your model is sound. If the delta is larger, the spreadsheet tells you exactly where to look. Compare each row’s assumed current and duration against the measured profile and update the one that’s off.

ST’s CubeMX Power Consumption Calculator can serve as a useful cross-check for the MCU-level modes. Nordic’s Online Power Profiler is helpful for building intuition about BLE radio duty cycles, though it’s nRF-specific. The advantage of your spreadsheet is that it’s fully transparent, customizable, and tracks with your project in version control.

Turning This Into Your Team’s Source of Truth

Your STM32WBA power budget spreadsheet isn’t a one-time exercise. It’s a living document that should evolve across your project:

  1. Start with datasheet estimates (what we just built).
  2. Replace with measurements as prototype hardware arrives.
  3. Add states as firmware features mature. What about OTA updates? LED indicators? Periodic deep-sleep calibration?
  4. Version it alongside your firmware so you can trace how design decisions affect battery life.

The math is simple: time-weighted average current. The value is in the discipline of decomposing your system into states and tracking each one. The biggest wins will always come from maximizing time in Stop mode and minimizing radio-on time. Every millisecond of radio activity costs roughly 2,000× more than a millisecond of sleep.

Build the spreadsheet now, while changes are cheap. Your future self, and your project lead asking “how long will the battery last?”, will thank you.

Hubble Network connects your BLE devices directly to satellites, eliminating the ground infrastructure that dominates most IoT power budgets. See how it works →