BLE Connection Parameter Validator

A BLE ACL connection is organized into regularly scheduled connection events. The connection interval sets the event cadence, peripheral latency allows the peripheral to skip a bounded number of events, and the supervision timeout determines when a silent link is considered lost.

A parameter request usually carries an interval range rather than one guaranteed interval. The Central selects the connection interval that is ultimately applied, subject to the capabilities and scheduling constraints of both devices.

Baseline connection intervals are encoded in 1.25 ms units from 7.5 ms through 4 seconds. Peripheral latency is a whole number from 0 through 499. The supervision timeout is encoded in 10 ms units from 100 ms through 32 seconds.

The parameters are coupled. For a baseline request, the supervision timeout must be strictly greater than:

2 × (peripheral latency + 1) × maximum connection interval

The maximum interval is used because the Central may choose any allowed value inside the requested range. The validator rounds the resulting lower bound up to the next valid 10 ms timeout value.

Peripheral latency is permission to skip events, not a requirement to sleep through them. If latency is four, the peripheral may wait until every fifth connection event before listening when the link conditions permit it. Incoming or outgoing traffic can bring it back sooner.

The reported listen spacing is therefore a scheduling upper bound for the negotiated interval—not an application round-trip guarantee. ATT acknowledgements, controller queues, radio retries, host scheduling, and application work all contribute additional latency.

• Shorter intervals create more transmission opportunities and usually improve responsiveness, at the cost of more frequent radio activity.
• Higher peripheral latency can reduce idle receive activity, but it increases the longest scheduled gap before the peripheral must listen.
• A longer supervision timeout tolerates longer periods of interference or missed packets, but delays detection of a genuinely lost link.

Treat presets as starting points. Measure wake time, transaction latency, disconnect recovery, and energy consumption on the product hardware under representative RF conditions.

A valid result confirms that the baseline tuple is representable and satisfies the Bluetooth relationship between interval, latency, and timeout. A phone, operating system, or controller may still select another interval in the range, modify a Link Layer request, or reject parameters it cannot schedule.

Inspect the parameters actually applied by the controller before attributing a latency or power regression to application code. Platform APIs do not always expose every negotiated field, so controller logs or an over-the-air trace may be necessary.

Bluetooth Core 6.2 introduced the optional Shorter Connection Intervals feature, with new feature exchange and connection-rate procedures. Capable devices can negotiate intervals below the baseline 7.5 ms floor. The baseline rules shown here apply to established HCI and GAP parameter workflows. Shorter Connection Intervals require separate feature support and negotiation.

The numerical rules used here come from the Bluetooth Core Specification, Link Layer sections 4.5.1, 4.5.2, and 5.1.7, together with the HCI LE Connection Update command. See the official Link Layer specification and HCI specification.

Use the encoded values as a review aid when comparing firmware configuration, HCI traces, or controller logs. In application code, work through the platform connection APIs and then observe what the peer actually negotiated.

SimpleBLE provides a consistent connection and GATT API across supported desktop and mobile targets. Start with the SimpleBLE tutorial and use the throughput calculator to evaluate the transfer side of the same link.

In HCI traces, baseline interval values are expressed in 1.25 ms units and timeout values in 10 ms units. For example, 0x0018 represents a 30 ms interval.