Designing BLE Products for Coin-Cell Operation: From Chip Selection to Power Budget

Designing BLE devices to run for years on a single CR2032 coin cell battery

Your power budget spreadsheet says 2.5 years of battery life. Your field test says 8 months. That gap has killed more BLE product launches than bad firmware ever will, and it almost always comes back to the same mistake: treating the CR2032 as a 230 mAh battery.

It isn’t. Not for your application, anyway.

Coin-cell BLE design is appealing for obvious reasons. A CR2032 is small, cheap, user-replaceable, and available everywhere. It’s the default choice for beacons, environmental sensors, and asset trackers that need to run for a year or more without attention. But the CR2032 has constraints that punish sloppy design. High internal resistance. Brutal capacity derating under pulsed loads. Voltage sag that triggers brown-out resets when your radio fires up.

This article walks through the full process: understanding your actual power source, picking the right BLE SoC, building a power budget you can trust, and handling the PCB-level details that silently drain coin cells in the field.

CR2032 Realities: The Battery You Think You Know

The CR2032 datasheet says 3V nominal, 230 mAh capacity. Those numbers come from constant-current discharge tests at low drain rates (typically 0.2 mA) at room temperature. Your BLE device doesn’t look anything like that test.

Design for 140 to 160 mAh of usable capacity. Here’s why:

Pulsed loads reduce effective capacity. BLE TX bursts pull 5 to 15 mA for a few milliseconds, then drop to microamps. This pulsed profile recovers less total energy from a lithium coin cell than a steady drain. Temperature compounds the problem. An asset tracker in a cold warehouse at 0°C might lose 20 to 30% of its rated capacity. And self-discharge matters over multi-year deployments: roughly 1 to 2% per year.

The internal resistance (15 to 30 ohms, rising as the cell ages) creates voltage sag under pulse loads:

  CR2032 Voltage vs. Pulse Current (approximate)
  
  Voltage (V)
  3.0 |━━━━━━━━━━━━━━━━━━━━━━━━━
  2.8 |        ·━━━━━━━━━━━━━━━━━
  2.6 |                ·━━━━━━━━━
  2.4 |                      ·━━━  ← BLE SoC brown-out zone
  2.2 |                          ·
      +----+----+----+----+----+--→
      0    5   10   15   20   25
              Pulse Current (mA)

At 15 mA pulse current, a fresh CR2032 sags to roughly 2.5V. A half-depleted one sags further. If your SoC’s brown-out threshold is 2.1V, you’ve got less headroom than you think.

Quick note on alternatives: the CR2477 gives you roughly 3x the capacity (1000 mAh nominal) in a larger package. The CR2025 and CR2016 are thinner but lower capacity. Pick based on your enclosure constraints, but the derating math applies to all of them.

BLE Chip Selection: The Highest-Impact Decision

Choosing the right SoC saves you months of firmware optimization later. The wrong chip can burn your entire power budget just sitting idle.

The parameters that matter, ranked by impact:

  1. Sleep/idle current with RTC running (target: under 2 µA)
  2. TX current at 0 dBm (4 to 8 mA across modern parts)
  3. RX current (often similar to TX, but worth checking)
  4. Wake-up time from deep sleep (affects duty cycle overhead)
  5. Minimum supply voltage (must run down to ~2.0V to use the full CR2032 capacity)
  6. Integrated peripherals (ADC, I²C, comparators: every external IC you avoid is leakage you eliminate)

Here’s a snapshot of where the major SoCs land:

  Chip Comparison (Approximate — Verify Against Current Datasheets)
  ┌──────────────────┬───────────┬──────────┬──────────┬─────────────┐
  │ SoC              │ Sleep (µA)│ TX 0dBm  │ Min Vdd  │ Notes       │
  │                  │           │ (mA)     │ (V)      │             │
  ├──────────────────┼───────────┼──────────┼──────────┼─────────────┤
  │ Nordic nRF52810  │ ~1.5      │ ~5.0     │ 1.7      │ Budget      │
  │ Nordic nRF52820  │ ~1.5      │ ~4.6     │ 1.7      │ Direction   │
  │ Nordic nRF54L10  │ ~0.8      │ ~3.4     │ 1.6      │ Next-gen    │
  │ Dialog DA14531   │ ~1.2      │ ~3.4     │ 1.1      │ Tiny + cheap│
  │ TI CC2340C1      │ ~0.8      │ ~5.6     │ 1.7      │ Low sleep   │
  │ Silicon Labs     │ ~1.3      │ ~4.1     │ 1.7      │ Ecosystem   │
  │   BG22           │           │          │          │             │
  │ Atmosic ATM33    │ ~0.5      │ ~4.0     │ 1.1      │ Harvesting  │
  └──────────────────┴───────────┴──────────┴──────────┴─────────────┘

How to match chip to application:

For advertising-only beacons, prioritize low TX current and low sleep. The DA14531 is a strong pick: 3.4 mA TX, tiny package, low minimum voltage.

Sensor nodes that wake up, read a sensor, and occasionally connect need integrated ADC/I²C and low sleep current. The nRF54L10 and CC2340C1 both shine with sub-1 µA sleep.

Asset trackers that need to run for years present a different constraint: minimum supply voltage becomes critical. A part that operates down to 1.1V squeezes more energy from the cell than one that browns out at 1.8V. Temperature resilience matters here too. If you’re building devices that feed into a cloud platform (Hubble’s device integration guide covers this for BLE-to-satellite trackers), chip selection constraints get even tighter because you need to budget for network stack overhead.

One trap to avoid: the chip with the lowest TX current isn’t always the system-level winner. A chip might require an external 32 kHz crystal with high load capacitance, or its internal regulator might have high quiescent current. Either of those can push total system draw past a “worse” chip that integrates everything more tightly.

Building a Power Budget You Can Actually Trust

A power budget isn’t a back-of-napkin estimate. It’s a spreadsheet. Every operating state gets a row, with current draw, duration, and charge consumed per cycle.

Step 1: List every state your device enters during one complete cycle (sleep, wake-up, sensor read, TX, RX listen, processing).

Step 2: Assign current and duration to each state. Use datasheet typicals as a starting point, but measure with a power profiler as soon as you have hardware.

Step 3: Calculate charge per cycle for each state (current × duration).

Step 4: Sum to get average current. Compare against your derated battery capacity.

Worked example: BLE beacon advertising every 1 second

  Power Budget: BLE Beacon (1s advertising interval)
  ┌─────────────────┬──────────┬───────────┬────────────────┐
  │ State           │ Current  │ Duration  │ Charge/cycle   │
  │                 │ (mA)     │ (ms)      │ (µAs)          │
  ├─────────────────┼──────────┼───────────┼────────────────┤
  │ Deep sleep      │ 0.002    │ 996.5     │ 1.993          │
  │ Wake + prepare  │ 3.0      │ 0.5       │ 1.500          │
  │ TX (3 channels) │ 5.5      │ 2.7       │ 14.850         │
  │ RX listen       │ 5.0      │ 0.3       │ 1.500          │
  ├─────────────────┼──────────┼───────────┼────────────────┤
  │ TOTAL per cycle │          │ 1000.0    │ 19.843         │
  └─────────────────┴──────────┴───────────┴────────────────┘
  
  Average current = 19.843 µAs / 1.0 s = 19.84 µA
  
  Battery life (derated 150 mAh): 
    150,000 µAh / 19.84 µA = 7,560 hours ≈ 315 days

Change the advertising interval to 2 seconds, and deep sleep dominates even more. The TX and RX charges stay fixed per event, but they occur half as often. Average current drops to roughly 11 µA, pushing battery life past 550 days.

Consider a sensor node that wakes every 60 seconds, reads a sensor for 5 ms at 2 mA, then bursts 10 seconds of advertising. The sensor read adds about 10 µAs per cycle, which seems significant on its own. But the 10-second advertising window (at ~20 µA average) dominates the energy budget. Your advertising strategy matters more than your sensor choice.

Always add 10 to 20% margin for PCB leakage, temperature effects, and firmware overhead you haven’t accounted for. If your budget is tight without margin, your design will fail in the field.

Critical Low Power BLE Hardware Design Choices

The SoC gets most of the attention, but the surrounding components can quietly eat your power budget.

Decoupling for pulse current. The CR2032 can’t deliver clean 15 mA pulses. You need at least 10 µF of capacitance close to the SoC’s VDD pin, with a low-ESR ceramic cap (22 µF 0402 X5R is a common choice). Without this, voltage sag during TX causes brown-out resets, especially as the cell ages and internal resistance climbs. This is the number one cause of “it worked in the lab but fails at month 6” failures.

Regulator strategy. Most modern BLE SoCs include both an internal DC-DC converter and an LDO. Use the DC-DC. The efficiency difference (85%+ vs 60-70% for LDO) translates directly to battery life. Avoid adding an external LDO if you can; even a “low quiescent” external regulator typically burns 0.5 to 1 µA that you don’t need to spend. If you must regulate externally, insist on Iq under 1 µA.

Crystal selection. Your 32.768 kHz crystal drives sleep timing and determines oscillator current. Pick one with low ESR and low load capacitance (6 pF or 7 pF rather than 12.5 pF). Some SoCs support crystal-less operation using an internal RC oscillator, which saves the crystal’s current draw entirely. The trade-off is frequency accuracy, which affects advertising interval precision. For most beacon and sensor applications, that trade-off is fine.

Sensor and peripheral discipline. Choose sensors with shutdown modes under 1 µA. Better yet, use a SoC GPIO to power-gate external sensors entirely when they’re not being read. Watch out for I²C pull-up resistors: they’re a hidden drain, leaking current through the bus whenever lines are pulled low. Use 10 kΩ or higher values, or switch pull-ups via GPIO so they’re only active during communication.

PCB leakage. Flux residue between coin-cell holder pads creates leakage paths, bleeding microamps you’ll never notice on a bench but that add up over months. Clean your boards. Use solder mask between high-impedance traces. For asset trackers heading into humid environments, conformal coating pays for itself in reliability. If you’re building devices that report data through Hubble’s network, the custom payload guide can help you minimize the data you transmit per cycle, which directly reduces radio-on time.

Firmware Sets the Ceiling

This is a hardware-focused article, so I’ll keep this brief. Your hardware decisions set the power floor. Firmware determines how close you get to the theoretical ceiling.

The single biggest firmware lever is advertising interval. Going from 100 ms to 1 s cuts advertising energy by roughly 10x. Proper deep sleep usage (wake-on-event, not periodic polling) is the second biggest lever. For connected devices, long connection intervals (hundreds of milliseconds rather than the 7.5 ms minimum) dramatically cut radio time. Batch your sensor reads instead of reading continuously. Skip scan responses unless a central is actively requesting them.

Measure real power consumption early and often. A Nordic PPK2 or Qoitech Otii Arc will show you exactly where your energy goes, and they’ll reveal problems that spreadsheets can’t predict.

Pre-Layout Power Checklist

Before you commit to a PCB revision, verify each of these:

  • Derated battery capacity calculated (140 to 160 mAh for CR2032)
  • SoC selected with sleep current under 2 µA and minimum Vdd at or below 2.0V
  • Power budget spreadsheet completed with every operating state
  • Decoupling capacitor (≥10 µF low-ESR ceramic) placed close to SoC VDD
  • All external components audited for sleep/shutdown current
  • PCB cleaned and leakage paths addressed (solder mask, conformal coat)
  • 10 to 20% margin remaining in your power budget

Get a power profiler on your prototype board as early as possible. The spreadsheet is your map; the profiler is your ground truth. The gaps between those two tell you where to focus next.


Hubble Network connects BLE devices directly to satellites, so your carefully optimized coin-cell product can report data from anywhere—no gateways, no infrastructure buildout. See how it works →