English is currently available.
Bluetooth & BLE DISCUSSION
I am designing a temperature sensor with an nRF52-class module running from a CR2032. It advertises the reading, and a phone occasionally connects to change settings. The first prototype with a 100 ms advertising interval drained the cell in about two months.
How do I estimate battery life from the advertising and connection intervals, and which parameters give the biggest saving without making the device feel slow to connect?
Average current is what matters. Each advertising event costs a roughly fixed charge and the chip sleeps in between, so I_avg = Q_event / T_interval + I_sleep. Take Q_event from the vendor's power profiler or measure it; it depends on TX power, payload length and the chip. As a worked example assume 12 µC per event and 2 µA sleep current.
At 100 ms: 12 µC / 0.1 s = 120 µA, plus sleep, about 122 µA. A CR2032 holds roughly 220 mAh, so 220 / 0.122 is about 1800 hours, or 75 days. At 1 s: 12 µA + 2 µA = 14 µA, which gives about 15,700 hours, around 1.8 years. The interval is by far the biggest lever.
The allowed advertising interval runs from 20 ms to 10.24 s in steps of 0.625 ms, and the stack adds a random 0 to 10 ms to each one to avoid repeated collisions. The cost of a long interval is discovery time: a phone scans for only part of the time, so it catches a fraction of your packets, and with a 2 s interval it can take many seconds to appear in the app.
A common compromise is two-stage advertising: fast (100 to 200 ms) for 30 seconds after a button press or power-up, then slow (1 to 2 s) for the rest of the time. Phone makers publish recommended intervals for accessories in their design guidelines, and following them improves discovery when the phone scans in the background.
Once connected, the same logic applies to the connection interval, which can be 7.5 ms to 4 s in 1.25 ms steps. The peripheral can only request values; the central decides, and phones enforce their own limits. Use peripheral latency so the sensor may skip events when it has nothing to send: an interval of 50 ms with latency 9 lets it wake only every 500 ms while still responding within 50 ms when it has data.
The supervision timeout must be longer than (1 + latency) × interval × 2, so that example needs more than 1 s; 4 s is a comfortable value. If the phone only connects to change settings, disconnect after an idle period and return to slow advertising.
Two hardware points decide whether the calculation holds in practice. A CR2032 has a high internal resistance, often tens of ohms once it is partly used, so a radio peak of 8 mA across 30 Ω pulls the terminal voltage down by about 0.24 V. A low-leakage capacitor of the order of 100 µF across the cell carries the peaks and lets you use more of the cell's capacity before the supply dips below the chip's minimum.
The other point is sleep current: make sure the firmware really reaches its low-power mode. A UART left enabled, a floating input or a sensor that is never put into standby can add tens of microamps, which dwarfs the radio. Measure over a full interval with a power profiler rather than trusting the estimate.
