A connected BLE link wakes up once per connection interval. Radio-on time dominates the energy budget of most BLE sensors, so these three parameters matter more than almost any code optimization.
| Parameter | Range | Effect |
|---|---|---|
| Connection interval | 7.5 ms – 4 s, in 1.25 ms steps | shorter = lower latency, higher throughput, more energy |
| Peripheral latency | number of connection events the peripheral may skip | peripheral sleeps through events when it has nothing to send, but stays reachable at the base interval |
| Supervision timeout | 100 ms – 32 s | how long without a packet before the link is considered lost |
Constraint from the Core Specification:
supervision_timeout > (1 + peripheral_latency) × connection_interval × 2
If you violate it, the central rejects the request.
Practical starting points
| Device type | Interval | Latency | Timeout |
|---|---|---|---|
| Sensor reporting every few seconds | 500 ms – 1 s | 0–4 | 4–6 s |
| Interactive device (button, lock) | 30–50 ms while active, raise when idle | 0 | 2–4 s |
| Bulk transfer (logs, firmware) | as short as the central allows | 0 | 4 s |
Change parameters at runtime: request a short interval for a firmware upload or log dump, then go back to a long interval.
The central decides
The peripheral only requests parameters (connection parameter update, or L2CAP signaling). The central may refuse or pick other values.
- Phones commonly apply their own minimums and ranges. iOS in particular is known to reject requests outside its accepted ranges. Always test on the phones you support and read back the actual interval from your stack.
- Log the negotiated values in firmware; do not assume your request was applied.
Common mistakes
- A long interval and a short supervision timeout → spurious disconnects.
- Peripheral latency set, but the firmware sends data every event anyway, so no energy is saved.
- Tuning the interval while advertising is still the bigger consumer: check advertising interval and duration too.