Connection interval is the primary power lever inside a BLE connection, but it’s only half of a two-parameter system. Tune it without understanding peripheral latency and you’ll either over-constrain latency to protect battery life or leave the biggest gains on the table. This article covers what the connection interval actually does to power consumption, where the tradeoff lives, and how peripheral latency changes the calculation.
If you’re new to BLE connection parameters, start with Understanding BLE Connections. If you already know how they work, keep reading.
Why Does BLE Drain Battery
Once a BLE connection is established, the Central and Peripheral communicate at a periodic interval called the connection interval. At each connection interval, a connection event takes place in which the Central sends a packet and the Peripheral responds with a packet.
If there’s data to be sent by either side, they send it in the packet. If there’s no data, an “empty packet” is sent. Those empty packet exchanges are the mechanism that keeps the connection alive even when no application data needs to move. They’re also the source of the power cost.
The reason this matters: radio transmission and reception modes are the primary power consumers in the BLE portion of an application. Receiving (even if no packet is actually being received) costs power. A peripheral sitting idle in a connection with a 20ms connection interval is waking its radio 50 times per second to exchange empty packets.
Most BLE stacks ship with a default connection interval under 100 milliseconds and a peripheral latency of 0. Those defaults are optimized for responsiveness, not battery life. They’re a reasonable starting point for getting a connection working. They’re almost never the right values for a shipped product with a battery target.
BLE Connection Interval and Power Consumption: The Core Tradeoff
Power consumption during a BLE connection is primarily configured by the connection parameters. These parameters are the connection interval, peripheral latency, and supervision timeout. The combination of connection interval and peripheral latency defines how frequently the Central and Peripheral exchange packets.
Connection interval is configurable from 7.5ms up to 4 seconds. By reducing the interval at which a peripheral’s radio is in receive or transmit mode, using a longer connection interval can substantially reduce peripheral power consumption, but at the expense of increased latency when data needs to be transmitted.
A shorter connection interval means less latency. It also means many connection events occur with no data to be exchanged, wasting power. Lengthening the interval directly reduces how often the radio wakes, which reduces power draw. The cost is that when data does become available, both devices have to wait until the next connection event to transmit it.
Platform floors matter here. Android supports a minimum connection interval of 7.5ms. iOS enforces a minimum of 15ms for standard apps (in multiples of 15ms). Devices implementing an HID GATT profile are allowed a lower minimum on iOS.
For the other side of this tradeoff, or how to configure the connection interval when your goal is maximizing throughput rather than preserving battery, see BLE Connection Interval and Peripheral Latency: How to Configure for Throughput.
Why a Long Connection Interval Alone Usually Isn’t Enough
A static connection interval is always a compromise. Set it long for the idle stretches and it hurts throughput when the device needs to move data. Set it short for the data transfer windows and the peripheral is waking its radio constantly during idle periods when nothing is happening.
Most real devices have variable activity patterns or periods of active data exchange followed by stretches where nothing needs to move. A fixed interval tuned for one condition will be wrong for the other. That’s the setup for what peripheral latency actually solves.
BLE Peripheral Latency and Power Consumption
Peripheral latency is a connection parameter that defines how many consecutive connection events the peripheral is allowed to skip. With a peripheral latency of 0 (the default), the peripheral listens for and responds to every connection event. If the peripheral latency is N, the peripheral intentionally ignores N consecutive connection events, then responds to the next one, ignores N again, and so on.
The reason this is more useful than simply setting a long connection interval is what happens when the peripheral has data to send. The peripheral doesn’t need to wait N connection events. If data is ready to be transmitted, it can forgo skipping and send in the next connection event. A short connection interval combined with a high peripheral latency has all of the benefits of a high connection interval when there’s no data to exchange, while still allowing for ow latency in peripheral-to-central communication when there is data to send.
Central-to-Peripheral Asymmetry
The asymmetry to understand is this: a high peripheral latency only reduces power when the peripheral is the one with data to send. It does nothing for central-to-peripheral latency. If your central needs to push data to the peripheral with low latency, peripheral latency cannot be set high, the peripheral is effectively asleep during the skipped events and won’t see the incoming data until it wakes.
In practice this asymmetry is usually acceptable for a low-power peripheral, and design can soften it where it isn’t. If a command has to reach the device fast, put the trigger on the peripheral side, so a stop control lives on a device button rather than depending on a message from the central. Where the central has to drive the interaction, the app can set the expectation, showing the user that the device will respond on its next connection event instead of appearing frozen.
Using Connection Interval and Peripheral Latency Together
The right approach for most battery-constrained peripherals is to treat connection interval and peripheral latency as a system, and to request different parameters depending on what the application is actually doing.
It’s possible to request unique connection parameters depending on system state — requesting fast connection parameters when needing to perform lots of data transfers and requesting slow connection parameters when the system does not. During active data transfer, fast parameters keep latency and throughput where they need to be. During idle periods, slow parameters let the radio rest.
How to Request Parameter Changes on iOS and Android
The catch is that neither iOS nor Android allows apps to interact with connection parameters directly. Android gets closest with BluetoothGatt.requestConnectionPriority(), available since Android 5.0, though it exposes only three coarse presets rather than specific interval values. High priority requests a fast interval in the range of roughly 11.25 to 15ms, balanced is the default, and low power requests something around 100ms. The request still routes through the same negotiation, and the central makes the final call.
The embedded device must request any preferred values through its BLE stack. The Central has final authority over what the connection parameters actually are, but peripherals can request preferred values, including a range of preferred connection intervals.
A common workaround to allow the app to drive parameter changes: have the app send the preferred parameters to the peripheral via an application-level message. Upon receiving that message, the firmware requests those connection parameters from its BLE stack, which handles the negotiation with the central.
Apple’s Connection Parameter Constraints
For iOS-connected products, the parameter combination has to satisfy Apple’s constraints. Apple’s Accessory Design Guidelines specify the following requirements:
- Interval Min ≥ 15ms (multiples of 15ms)
- Interval Min + 15ms ≤ Interval Max
- Interval Max × (Slave Latency + 1) ≤ 2 seconds
- Interval Max × (Slave Latency + 1) × 3 < connSupervisionTimeout
- Slave Latency ≤ 30
- 2 seconds ≤ connSupervisionTimeout ≤ 6 seconds
Android is more permissive. It supports the BLE spec minimum of 7.5ms and allows a much higher supervision timeout of around 30 seconds.
What Connection Parameters Should You Actually Use?
Treat connection interval and peripheral latency as a system, match them to application state. Fast parameters when data is moving, slow parameters when it isn’t. A static compromise gives you neither full power efficiency nor full responsiveness.
Before going deep on parameter tuning, verify that BLE radio activity is actually the dominant power consumer on your peripheral. Many devices have sensors, processors, or other subsystems that consume more than the radio, and if BLE is a small fraction of overall budget, parameter optimization won’t move your battery life number.Find the actual bottleneck first. Our guide to balancing battery life and performance in firmware covers how to categorize the real power consumers and measure them, so you can tell whether BLE is even the right lever to pull.
Connection parameters govern what a connection costs while it’s open. When to advertise, when to connect, and when to disconnect are the other half of the power picture, and our Ultimate Guide to Managing Your BLE Connection covers that full lifecycle.
