TS-M1050

Bluetooth Module Sleep Modes and Power Optimization: Engineering for Long Battery Life

Power consumption is the defining constraint for battery-operated IoT devices. A Bluetooth module that draws 20 mA average current on a 1000 mAh battery lasts 50 hours — inadequate for any practical deployment. The same module, properly configured with sleep modes and event-driven wake patterns, can run for 2–5 years on the same battery. This article details the sleep mode architecture of BLE modules and the engineering decisions that determine real-world current consumption.

BLE Module Power States

State Current (typical) Wake Latency RAM Retention CPU State
Active TX (0 dBm) 5–7 mA — Yes Running
Active RX 4–6 mA — Yes Running
Idle (CPU active) 1–3 mA — Yes Waiting
Sleep (System ON) 1.5–10 µA <1 ms Yes Stopped
Deep Sleep (System OFF) 0.1–1 µA 250–500 ms Partial/No Off
Hibernate / Shutdown 0.02–0.1 µA >500 ms No Off

The “System ON” sleep state — where the BLE radio stack timer is running and wakes the CPU for scheduled BLE events — is the workhorse state for most BLE applications. It combines sub-10 µA sleep current with sub-millisecond wake latency, enabling high-frequency BLE advertising with very low average current.

Average Current Calculation for BLE Advertising

The average current for a BLE peripheral advertising at interval T is:

I_avg = (I_TX × t_TX + I_sleep × (T - t_TX)) / T

Example calculation for advertising at 1000 ms intervals:

  • TX current: 5.5 mA (0 dBm); TX duration per event: ~1.5 ms (3 channels × 0.5 ms/channel)
  • Sleep current: 2.5 µA (System ON sleep)
  • I_avg = (5.5 mA × 1.5 ms + 0.0025 mA × 998.5 ms) / 1000 ms = ~10.75 µA

At 10.75 µA average, a 1000 mAh coin cell would theoretically last ~10.7 years. In practice, battery self-discharge reduces this to 3–5 years for a CR2477.

System ON Sleep: Implementation Details

Critical implementation rules:

  • Never busy-wait. Polling loops destroy power efficiency. Every wait must terminate in WFE (Wait For Event) or equivalent.
  • Disable unused peripherals. An active UART consumes ~1 mA even with no data. TWIM (I2C master) in idle: ~200 µA. All peripherals not actively used must be in power-down state.
  • Configure GPIO properly. Floating inputs consume significant leakage current (~100 µA per pin in some SoCs). All unused GPIO must be configured as output-low or input with pull-up/pull-down.
  • DC-DC vs. LDO regulator. At 3V supply and 5 mA TX load, the DC-DC converter saves ~1.5 mA vs. LDO. Enable DC-DC in the SoftDevice init configuration.

Deep Sleep and Hibernate Tradeoffs

System OFF (deep sleep) reduces current below 1 µA but loses all RAM content and requires a full reset cycle (~300–500 ms including SoftDevice initialization) to resume. Acceptable for sensors measuring every 30+ seconds; not viable for connected peripherals that must maintain a BLE connection.

Sensor Integration and Power Gating

Sensor Active Current Sleep Current Recommended Duty Cycle
Temperature/Humidity (SHT3x) 900 µA during measurement 0.2 µA Single-shot, then sleep
Accelerometer (LIS2DW12) 200 µA @ 100 Hz ODR 0.5 µA Event-triggered or low-ODR
Pressure (BMP390) 750 µA during conversion 0.1 µA On-demand measurement
Optical (APDS-9960) 12–100 mA during gesture/prox 1 µA On-demand only

Power gating — using a GPIO-controlled PMOS or load switch to completely remove power from sensors between measurements — is essential. A sensor drawing 10 µA in sleep adds ~1 year of drain to a coin cell over a 5-year deployment.

TX Power Optimization

TX Power TX Current (approx.) Range (open space)
−20 dBm ~2 mA ~5 m
0 dBm ~5.5 mA ~30 m
+4 dBm ~7 mA ~50 m
+8 dBm ~10 mA ~80 m

Connection Parameter Optimization

For connected BLE peripherals, connection parameters determine sleep efficiency:

  • Connection interval — for low-throughput sensor applications, 500 ms–2 second intervals reduce average current to single-digit µA.
  • Slave latency — allows the peripheral to skip up to N consecutive connection events. Setting slave latency = 9 with 100 ms connection interval effectively creates a 1-second polling rate.
  • Supervision timeout — must exceed connection_interval × (1 + slave_latency) × 1.25 ms with adequate margin.

Designing power-efficient firmware for a Bluetooth module is not a single optimization — it is a discipline spanning hardware selection, SoC configuration, peripheral management, and communication parameter tuning.