A Bluetooth module can sip microamps in sleep or burn tens of milliamps while transmitting, and the gap between those two numbers is what decides battery life. Most teams tune the radio and forget the power state machine, yet the state machine is where months of runtime are won or lost. This article lays out a practical low-power scheduling model: which states exist, what wakes the part, and how to compute the average current a design will actually draw.
The power state machine
Think of the Bluetooth module as moving through four states, not two:
| State | Typical current | What is alive |
|---|---|---|
| Active / TX-RX | 5-20 mA | Radio, CPU, flash |
| Sleep (CPU idle) | 1-3 mA | CPU clock gated, RAM retained |
| Deep sleep | 10-200 µA | RTC, retained RAM only |
| Hibernate | 1-5 µA | GPIO wake, RTC, nothing else |
The art is spending as much time as possible in deep sleep or hibernate while still meeting the latency your application needs. A door sensor that reports once a day can live in hibernate; a wearable that streams HR needs to stay in sleep.
Wake sources
A Bluetooth module does not wake itself — something must pull it out of sleep:
- GPIO interrupt: a button, PIR, or reed switch edge. Fastest (µs) and cheapest.
- RTC / timer: for periodic beacons or polling. Predictable, but fixes your duty cycle.
- UART RX: host bytes arrive and the falling edge wakes the part. Needs the RX pin to stay biased.
- BLE event: a connection event or advertisement window scheduled by the stack.
- Wake timer in the radio: the link layer self-wakes for the next connection interval.
For a battery sensor, GPIO + RTC is the combination that lets the part sleep 99% of the time.
Duty-cycling math
Average current is the time-weighted sum of each state:
I_avg = I_active * (t_active / T) + I_sleep * (1 – t_active / T)
If a Bluetooth module transmits for 5 ms every 1 s at 15 mA and sleeps at 50 µA the rest of the time:
I_avg = 0.015 * 0.005 + 0.00005 * 0.995 ≈ 0.000125 A = 125 µA
A CR2032 (220 mAh) then lasts roughly 220 / 0.125 ≈ 1760 hours, or about 73 days. Move the interval to 10 s and it stretches past two years. The interval, not the radio power, dominates.
PMIC and regulator choice
The regulator feeding the Bluetooth module matters as much as the module itself. A linear LDO is simple and quiet but wastes the drop from battery to 1.8 V as heat. A buck (switching) converter reaches 85-95% efficiency and can double runtime on a 3.6 V Li cell. Rule of thumb: above a 200 mV drop at more than a few mA, use a buck.
Also watch the quiescent current of the PMIC itself — a buck that draws 25 µA in sleep can swamp a Bluetooth module sitting at 5 µA in hibernate. Pick a PMIC whose Iq is well below your target sleep current.
Sleep entry handshake
Never yank power from a Bluetooth module mid-flash. Use an explicit handshake:
1. Host sends a sleep command (e.g. AT+SLEEP) and waits for an OK.
2. Module finishes the current operation, flushes the UART, and asserts a HOST_WAKE/CTS line to say “I am asleep”.
3. Host may now cut the radio supply or just let the PMIC idle it.
On wake, the host de-asserts the line; the module boots its stack in tens of milliseconds and raises HOST_WAKE high again to signal readiness.
Wake latency trade-off
Faster wake costs power. A module that keeps a low-frequency oscillator running wakes in 2 ms but burns more in sleep; one that gates everything needs 20-50 ms and a full re-init. Choose based on the application: a keyboard wants sub-10 ms, a temperature beacon can tolerate seconds.
Measuring it for real
The model is only as good as your numbers. Use a DC power analyzer (not a multimeter) to capture the current trace, then sum the area under the curve:
Charge_per_cycle = ∫ I(t) dt (in µA·s)
Average_current = Charge_per_cycle / T
This captures the real cost of flash writes, crystal startup, and regulator ringing that the simplified formula hides.
A well-architected Bluetooth module design spends most of its life in deep sleep, wakes on a clean source, and uses a buck regulator whose quiescent current is a fraction of the sleep floor — that is how you turn weeks of runtime into years.