Slave Latency

Slave Latency

peripheral can skip." data-category="Fundamentals">Slave latency (also called peripheral latency) is a BLE connection parameter that specifies the number of consecutive connection events a peripheral is allowed to skip without being disconnected. It is one of the most effective power-saving mechanisms available to battery-powered BLE devices.

How Slave Latency Works

When a peripheral has no data to send and no pending acknowledgments, it can choose not to wake its radio for the next connection event. With a slave latency value of N, the peripheral can skip up to N consecutive events. It must respond to at least every (N + 1)th event to maintain the connection and prevent the supervision timeout from firing.

For example, with a connection interval of 30 ms and a slave latency of 9, the peripheral can sleep for up to 300 ms (10 x 30 ms) between wake-ups. If the peripheral does have data to send, it can wake up at any connection event regardless of the latency setting -- slave latency only defines the maximum number of events that may be skipped, not a forced delay.

Interaction with Connection Interval

Slave latency and connection interval together determine the effective polling rate of the peripheral. A shorter CI with high slave latency can achieve the same average power as a longer CI with zero slave latency, but with the advantage of lower worst-case latency. When the peripheral has data, it can transmit within one CI (e.g., 30 ms), whereas a long CI of 300 ms would impose that delay unconditionally.

This pattern is especially useful for Human Interface Devices (HID). A BLE keyboard might use CI = 7.5 ms with slave latency = 30, sleeping for 225 ms during idle periods but responding to a keypress within 7.5 ms. This gives the user instantaneous response while preserving battery life during pauses.

Supervision Timeout Constraint

The Bluetooth specification requires that the supervision timeout be larger than (1 + slave_latency) x connection_interval x 2. This ensures the central does not declare the connection lost while the peripheral is legitimately sleeping. A common configuration for sensor applications is CI = 100 ms, slave latency = 4, supervision timeout = 2000 ms. Violating this constraint will cause the connection to drop unpredictably, so BLE stacks typically validate the relationship at parameter negotiation time.