BLE Advertising Interval vs Battery Life: How to Model the Tradeoff Before You Build

Most BLE beacon projects pick an advertising interval the same way: copy what a reference design used, ship it, and find out 14 months later that batteries are dying at month 8. The root cause is almost never a hardware defect. It’s that nobody modeled the power budget before committing to a design. The math takes six cells in a spreadsheet. Yet the number of products that ship without this analysis is staggering, and the cost of guessing wrong is a field recall or an over-specced battery that bloats your BOM.

The relationship between advertising interval and battery life is straightforward enough to calculate on a napkin. You don’t need simulation tools. You need the right datasheet numbers, a duty-cycle equation, and about 30 minutes. By the end of this article, you’ll have a repeatable model you can plug your own numbers into, whether you’re designing an asset tag on an nRF52832 with a CR2032 or evaluating a completely different BLE SoC.

Scope: non-connectable advertising (beacons, asset tags, proximity devices), nRF52 series parts, CR2032 coin cells, spreadsheet-grade math.

What Actually Happens During a Single Advertising Event

Before you can model power, you need to understand what the radio does every time it advertises. For non-connectable undirected advertising (ADV_NONCONN_IND), here’s the sequence:

        ┌──┐     ┌──┐     ┌──┐
        │TX│     │TX│     │TX│
  ──────┘  └─────┘  └─────┘  └──────────────── sleep ───────────
   ramp  ch37  gap  ch38  gap  ch39
   
  |<──────── T_event ─────────>|<──── T_sleep ────>|
  |<──────────── T_interval (configured) ─────────>|

The radio ramps up, transmits the advertising packet on channel 37, waits a brief inter-frame gap (150 µs), transmits on channel 38, another gap, then channel 39. After that, the radio powers down and the SoC returns to sleep.

A critical simplification: because this is non-connectable advertising, there is no RX window after each TX. Connectable advertising types (ADV_IND) require the radio to listen for connection requests after each packet, which adds significant current draw. Non-connectable skips this entirely. The radio transmits and immediately moves on.

For an nRF52832 transmitting a typical 20-byte advertising payload at 1 Mbps PHY, the total event duration (T_event) lands around 1.5 ms. This includes ramp-up (~140 µs), three TX bursts (~200 µs each for a short payload), and two inter-frame gaps. The rest of the interval, from the end of T_event until the next advertising event, is pure sleep.

That ratio of awake-to-asleep is the entire game.

The Core Equation: Average Current as a Duty-Cycle Problem

The model comes down to one equation for average current draw:

I_avg = (T_event × I_tx_avg  +  T_sleep × I_sleep) / T_interval

Where T_sleep = T_interval - T_event.

Here are the inputs, anchored to nRF52832 Product Specification values:

Once you have I_avg, battery life falls out directly:

Battery Life (hours) = C_battery / I_avg

That’s the entire model at its core. Everything else (temperature, self-discharge, voltage droop) refines these inputs. The I_tx_avg value of 5.3 mA comes from the nRF52832 Product Specification’s radio current consumption table (look for the 1 Mbps TX row at 0 dBm in DC-DC mode). The sleep current of 1.5 µA is the System ON, no RAM retention partial, with RTC running figure. You can find both in Chapter 5 of the product spec.

I_tx_avg represents the average current during the event, not the peak. It accounts for ramp-up and gaps. If you want higher precision, measure a real advertising event with a power profiler. But for first-order estimates, the datasheet TX current is a solid proxy.

Worked Example: What Three Different Intervals Actually Mean for Battery Life

Let’s sweep three advertising intervals that represent the practical range: 100 ms (fast, indoor wayfinding), 1 s (typical asset tracking), and 10 s (slow, presence detection).

For each, we calculate I_avg, then divide into 200 mAh:

100 ms interval:

• T_sleep = 100 ms - 1.5 ms = 98.5 ms
• I_avg = (0.0015 × 5300 + 0.0985 × 1.5) / 0.1 = (7.95 + 0.148) / 0.1 = 81.0 µA

1 s interval:

• T_sleep = 1000 ms - 1.5 ms = 998.5 ms
• I_avg = (0.0015 × 5300 + 0.9985 × 1.5) / 1.0 = (7.95 + 1.498) / 1.0 = 9.4 µA

10 s interval:

• T_sleep = 10000 ms - 1.5 ms = 9998.5 ms
• I_avg = (0.0015 × 5300 + 9.9985 × 1.5) / 10.0 = (7.95 + 15.0) / 10.0 = 2.3 µA

Two things jump out. First, the relationship is roughly linear across this range: a 10× increase in interval yields roughly a 10× increase in battery life. Second, the 10 s result (9.9 years) exceeds the CR2032’s self-discharge shelf life of roughly 8–10 years. That’s a natural ceiling. No matter how infrequently you advertise, the battery will drain itself.

Also notice where sleep current starts to matter. At 100 ms, sleep current contributes only about 0.2% of the average. At 10 s, it contributes roughly 65%. This means that at long intervals, optimizing TX current has diminishing returns. Your sleep current floor becomes the dominant factor.

Derating Factors: What the Napkin Math Misses

The model above is ideal. Real-world performance is worse. Here’s what bends the curve:

CR2032 peak current limitations. A CR2032 has internal resistance of 10–40 Ω depending on temperature and state of charge. A 5.3 mA TX pulse causes 50–200 mV of voltage droop. At cold temperatures (-20°C), internal resistance can triple, and the voltage may dip below the SoC’s minimum operating voltage. This effectively reduces usable capacity by 15–30% in harsh environments.

Temperature effects on capacity. A CR2032 rated at 235 mAh at 20°C may deliver only 150–170 mAh at -10°C. If your asset tag ships into cold-chain logistics, this matters enormously.

Self-discharge. Roughly 1% per year at room temperature, accelerating at elevated temperatures. This sets the hard ceiling on battery life regardless of how low your average current is.

DC-DC vs. LDO regulator mode. The 5.3 mA figure above assumes DC-DC mode on the nRF52832, which requires an external inductor on the PCB. If you’re using LDO mode (no inductor), TX current jumps to roughly 8.5 mA, a 60% increase. Make sure you know which mode your design uses.

Payload size. Longer advertising payloads mean longer T_event. At 1 Mbps PHY, each additional byte adds about 8 µs of air time. A maximum-length advertising payload (~31 bytes of ad data) extends T_event compared to a minimal one. For most beacons this is a second-order effect, but it’s worth including in your spreadsheet.

For conservative estimates, apply a derating multiplier of 0.6–0.7× to the ideal model. That 2.4-year estimate at 1 s interval becomes 1.4–1.7 years in practice, which aligns well with field data from deployed beacon products.

Translating Your Interval Choice to Firmware Configuration

Once you’ve picked an interval from your spreadsheet, configuring it in firmware is a one-liner. In the nRF5 SDK:

// Non-connectable advertising config (nRF5 SDK)
ble_gap_adv_params_t adv_params;
adv_params.type     = BLE_GAP_ADV_TYPE_NONCONNECTABLE_NONSCANNABLE_UNDIRECTED;
adv_params.interval = MSEC_TO_UNITS(1000, UNIT_0_625_MS); // 1 second

The BLE specification defines advertising interval in units of 0.625 ms. The allowed range for non-connectable advertising is 100 ms to 10.24 s (160 to 16,384 units). Zephyr RTOS uses a similar parameterization through its Bluetooth advertising API.

This single parameter, adv_params.interval, is the highest-leverage firmware decision you’ll make for battery life. Everything else (TX power level, payload length, sleep mode configuration) is fine-tuning around it.

A Decision Framework You Can Use Tomorrow

Build a spreadsheet with these six input cells: I_tx_avg, I_sleep, T_event, T_interval, C_battery, and a derating factor. Sweep T_interval from 100 ms to 10 s and plot the resulting battery life. You’ll have a complete trade-space curve in minutes.

Here’s a starting-point heuristic for common use cases:

Use Nordic’s Online Power Profiler as a sanity check against your spreadsheet. The OPP is excellent for validation, but the spreadsheet is your primary tool for sweeping the trade-space quickly and understanding why the numbers are what they are.

Build This Model Before You Spin a PCB

The advertising interval vs. battery life tradeoff doesn’t require expensive tools or prototype hardware to resolve. It’s a duty-cycle problem with five inputs you can pull from a datasheet in ten minutes. The advertising interval is your primary lever. Sleep current sets your floor. CR2032 physics set your ceiling.

Anchor on datasheet values, derate by 0.6–0.7× for real-world conditions, and you’ll have a defensible estimate that lets you commit to a battery, an enclosure size, and a product claim before you’ve ordered a single component. That’s the difference between a beacon product that meets its spec and one that triggers a field replacement program 14 months after launch.

Hubble Network enables BLE devices to transmit data directly to satellites—eliminating terrestrial infrastructure constraints from your deployment model entirely. See how it works →