How Do BLE Connection Parameters Affect Power Consumption?

Detailed Explanation

Connected BLE peripherals spend most of their operating life in a simple cycle: sleep, wake briefly to exchange packets with the central device, sleep again. The three connection parameters — connection interval, slave latency, and supervision timeout — control every aspect of this cycle. Getting them right can mean the difference between a coin cell lasting six months and lasting three years in a deployed product.

Connection Interval

The connection interval defines how often the radio wakes for a connection event — the scheduled opportunity for the central and peripheral to exchange packets. It is expressed in multiples of 1.25 ms, from a minimum of 6 units (7.5 ms) to a maximum of 3200 units (4 s), per the Bluetooth Core Specification Vol 6, Part B.

During a connection event:

1. The peripheral wakes slightly before the anchor point to synchronise its clock
2. The central transmits a packet (may be an empty PDU if it has no data to send)
3. The peripheral responds (data notification, empty acknowledgement, or status)
4. If either side has more data, additional packets are exchanged within the same event
5. Both devices sleep until the next anchor point

A single empty PDU connection event on the nRF52840 (DCDC enabled) typically lasts approximately 300–600 µs at approximately 5 mA per Nordic's product specification — followed by sleep at roughly 2–3 µA. The ratio of active time to sleep time determines average current.

Approximate average current at idle (nRF52840, DCDC enabled, 0 dBm, single PDU exchange, no data queued):

These are order-of-magnitude estimates based on typical values in the nRF52840 product specification. Actual values depend on TX power setting, DCDC vs LDO regulator mode, BLE stack overhead, and concurrent advertising. Always measure with a Nordic PPK2 or equivalent current profiler on target hardware before making battery-life commitments.

Choosing the connection interval: match the interval to the application's acceptable latency. A wearable sensor reading once per second has no need for a 20 ms interval — 500 ms to 1 s costs little responsiveness while saving a large fraction of radio energy. A HID keyboard requires 7.5–20 ms to avoid perceptible input lag. Request a range (min, max) when negotiating — for example, min = 400 ms, max = 500 ms — rather than a fixed value: this gives the central more flexibility and improves the probability of acceptance.

Slave Latency

Slave latency (referred to as peripheral latency in BLE 5.0+ terminology) allows the peripheral to skip up to N consecutive connection events when it has no data to transmit. The central is informed of the latency value at connection time and does not treat the peripheral's absence during skipped events as a link failure.

With slave latency N, the peripheral can sleep for up to (N + 1) connection intervals between wake-ups when idle:

• Effective sleep window (idle) = connection interval × (slave latency + 1)

The peripheral may still wake at any event boundary when it has data to send — latency is an allowance to skip, not an obligation to do so.

Combined effect of connection interval and slave latency on average current (nRF52840, idle):

Slave latency is most beneficial for peripherals that rarely receive data from the central but send notifications on their own schedule — temperature sensors, accelerometers, environmental monitors. It is less useful when the central frequently writes to the peripheral (configuration commands, OTA data), since the peripheral cannot predict when to wake and must respond at its next scheduled event anyway.

Constraints on slave latency:

• Maximum per Bluetooth specification: 499
• Practical constraint: slave_latency × connection_interval must be less than supervision_timeout / 2
• iOS constraint: typically accepts a maximum of 4

Supervision Timeout

The supervision timeout determines how long either device waits without a successful packet exchange before declaring the connection lost and notifying the application. It is expressed in multiples of 10 ms, from 10 (100 ms) to 3200 (32 s).

Minimum supervision timeout (Bluetooth Core Specification requirement):

supervision_timeout > (1 + slave_latency) × connection_interval × 2

This ensures the supervision timer cannot expire while the peripheral is legitimately sleeping through its allowed skip window. Violating this constraint causes intermittent disconnections that are difficult to debug — the link drops at random, more often in radio-noisy environments.

Example: slave latency 4, connection interval 500 ms:

• Minimum timeout = (1 + 4) × 500 ms × 2 = 5000 ms
• Practical recommendation: 6–8 s to absorb one or two missed events from interference

Choosing the timeout: too short causes spurious disconnections in real environments; too long means the peripheral side reports a connection for many seconds after the central has moved out of range (which confuses application state and delays reconnection logic). A timeout of 4–8 s is appropriate for most IoT sensor products. iOS enforces a minimum timeout of approximately 2 s regardless of what the peripheral requests.

Worked Power Example

A BLE environmental sensor on a CR2032 coin cell:

• Sends one temperature notification every 10 s
• Receives configuration writes occasionally (< once per minute)

Before parameter negotiation (central defaults after pairing):

• Connection interval: 30 ms, slave latency: 0, supervision timeout: 2 s
• Average current from BLE connection alone: approximately 100 µA

After requesting updated parameters:

• Connection interval: min 400 ms / max 500 ms, slave latency: 4, supervision timeout: 6 s
• Effective wake interval when idle: 2000–2500 ms
• Average current from BLE connection alone: approximately 3–5 µA

This single parameter negotiation reduces BLE connection overhead by approximately 20–30× for the idle periods between notifications, with negligible impact on notification delivery latency (the sensor wakes at the next event boundary, adding at most 500 ms to the delivery time).

Connection Parameter Negotiation

Parameters are initially set by the central device in the CONNECT_IND link layer packet. The peripheral requests new parameters after connection establishment using one of two procedures:

L2CAP Connection Parameter Update Request (BLE 4.0+): The peripheral sends a preferred range (minimum interval, maximum interval, slave latency, supervision timeout) via the L2CAP signalling channel. The central accepts or rejects.

LL Connection Parameter Request (BLE 4.1+): A link-layer procedure (LL_CONNECTION_PARAM_REQ) that is faster and can be initiated by either side. Zephyr automatically uses this when both devices support BLE 4.1 or later.

In practice, the application calls one API; the stack chooses the correct procedure:

Zephyr NCS (nRF52/nRF53):

static const struct bt_le_conn_param conn_param = BT_LE_CONN_PARAM(
    BT_GAP_MS_TO_CONN_INTERVAL(400),  /* min interval: 400 ms */
    BT_GAP_MS_TO_CONN_INTERVAL(500),  /* max interval: 500 ms */
    4,                                  /* slave latency        */
    BT_GAP_MS_TO_CONN_TIMEOUT(6000)   /* supervision timeout: 6 s */
);

/* Call from the connected callback: */
int err = bt_conn_le_param_update(conn, &conn_param);

ESP32 NimBLE:

struct ble_gap_upd_params upd = {
    .itvl_min            = BLE_GAP_CONN_ITVL_MS(400),
    .itvl_max            = BLE_GAP_CONN_ITVL_MS(500),
    .latency             = 4,
    .supervision_timeout = BLE_GAP_SUPERVISION_TIMEOUT_MS(6000),
    .min_ce_len          = 0,
    .max_ce_len          = 0,
};
ble_gap_update_params(conn_handle, &upd);

The bt_conn_cb.le_param_req / BLE_GAP_EVENT_CONN_UPDATE event notifies the application of the accepted parameters. Always verify the negotiated interval with a BLE packet sniffer — the central may silently accept different values than requested, particularly on iOS.

Platform Restrictions

iOS: Apple's Bluetooth Accessory Design Guidelines impose minimum acceptable ranges:

• Connection interval: ≥ 15 ms (7.5 ms only for HID profile devices)
• Slave latency: ≤ 4
• Supervision timeout: ≥ 2 s; total supervision window ≤ a few seconds (varies by iOS version)

Requests below these thresholds are rejected without error. Test parameter negotiation on physical iOS devices — the nRF Connect app on iPhone shows the negotiated interval and is a fast diagnostic tool.

Android: Android generally honours the peripheral's requested parameters, but OEM Android modifications (Samsung OneUI, Huawei EMUI, and others) can introduce delays or override values. Behaviour also varies between Android versions. Always validate on at least two OEM hardware targets before finalising parameters.

Practical Examples

Parameter sets by application type:

Design Considerations

• Request parameters in the connected callback: call bt_conn_le_param_update() or ble_gap_update_params() from the connected event handler, not at boot. Parameters reset to central defaults on every new connection — the update request must be repeated in each connected callback.
• Separate parameters for OTA updates: a 500 ms connection interval makes firmware updates impractically slow. Request a shorter interval (20–50 ms) before starting an OTA transfer, then restore the power-optimised parameters once the transfer completes.
• Supervision timeout safety margin: always add one or two full effective-skip-window durations above the specification minimum. In practice: supervision_timeout = (1 + slave_latency) × interval_max × 3 is a robust starting point.
• Slave latency and inbound command latency: if the central frequently writes to the peripheral (OTA data, configuration commands), slave latency delays delivery until the next scheduled wake. Design the peripheral application to tolerate command latency equal to the full skip window, or reduce slave latency for command-intensive modes.
• Measure before committing to battery-life claims: the estimates in this page are based on typical datasheet values. Actual current depends on TX power, DCDC mode, clock accuracy, and stack overhead. Use a Nordic PPK2 or equivalent tool on target hardware and measure over at least 60 s to account for timing variation.
• Zeus Design develops low-power BLE peripheral firmware for consumer and industrial IoT products, covering parameter optimisation, iOS/Android compliance testing, and companion mobile app integration.

Common Mistakes

• Supervision timeout shorter than (1 + slave_latency) × interval × 2: the most common cause of intermittent BLE disconnections, especially in RF-noisy environments. Whenever slave latency is non-zero, recalculate the minimum timeout and add a safety margin.
• Requesting a fixed min=max interval: requesting min = 500 ms, max = 500 ms is less likely to be accepted than min = 400 ms, max = 500 ms. A range gives the central scheduler flexibility; iOS in particular prefers a range with at least 15 ms spread.
• Using minimum interval for all applications: 7.5 ms or 20 ms intervals waste battery energy and are rejected by iOS for non-HID devices. Start with the longest latency your application can tolerate, then shorten only if latency testing identifies a genuine problem.
• Not re-requesting parameters after reconnection: each new connection starts with the central's default parameters. The parameter update request in the connected callback handles both first connections and reconnections — do not guard it with a "first connection only" flag.
• Testing only on development kits against a PC Bluetooth host: connection parameter negotiation behaviour varies widely by phone OS and OEM. A negotiation that works between an nRF DK and a PC may fail silently on an iPhone 15 or a Samsung Galaxy. Test on physical end-user devices early.
• Slave latency when the central polls the peripheral: if the central reads characteristics on a regular schedule (polling rather than notifications), slave latency means the peripheral is asleep for most of those polls. The read completes only when the peripheral happens to be awake at a non-skipped event. Design for notification-based data delivery rather than central polling when slave latency is in use.