With Bluetooth Framework you can read and change the Bluetooth LE connection parameters. This feature is supported with BLED112 USB Bluetooth dongle on any Windows platform and with Microsoft Bluetooth driver on Windows 11 and above. Bluetooth Framework allows to set predefined connection parameters as well as any custom values.

Predefined connection parameters

  • Balanced
    The balanced set of connection parameters, offering a balance between throughput and power usage.
  • Power Optimized
    The more power-efficient set of connection parameters. Optimized for power usage at the expense of throughput. Also allows for more simultaneous connections to other Bluetooth devices.
  • Throughput Optimized
    The more aggressive set of connection parameters, optimized for faster throughput at the expense of power usage. Also reduces the number of simultaneous connections that can be made to other Bluetooth devices.

What Is Connection Parameter

The connection parameters are important for BLE communication, because they affect the power consumption, the data transfer speed and the stability of the connection. The connection parameters for a BLE connection are a set of parameters that determine when and how the central and peripheral in a link transmit data. The parameters are exchanged when the central and peripheral initially connect. It is always the central that actually sets the connection parameters used, but the peripheral can send a Connection Parameter Update Request, that the central can then accept or reject. The three different parameters are:

Connection Interval

The connection interval determines how often the central will ask for data from the peripheral. When the peripheral requests an update, it supplies a maximum and a minimum wanted interval. The connection interval must be between 7.5ms and 4s. The connection interval time has an inverse affect on data throughput of the BLE connection, as shown in the following equation: DataThroughput = (8 * BytesPerPacket*PacketsPerInterval * 1000) / ConnectionInterval. To save power we need to change the connection interval to a much longer period when we know the connection is going to be in idle state for a period of time.

Slave Latency

By setting a non-zero slave latency, the peripheral can choose not to answer when the central asks for data up to the slave latency number of times. However, if the peripheral has data to send, it can choose to send data at any time. This enables a peripheral to stay sleeping for a longer time if it doesn't have data to send but still send data fast if needed. Furthermore, slave latency can be applied to help the peripheral (slave) device to further reduce power consumption. This parameter is helpful to avoid changing connection parameters frequently to achieve both high speed data transfer and low power consumption during idle.

Connection Supervision Timeout

This timeout determines the timeout from the last data exchange until a link is considered lost. The central will not try to reconnect before the timeout has passed, so if you have a device that goes in and out of range often and you need to notice when that happens, it might make sense to have a short timeout.

Effective Connection Interval

The effective connection interval is equal to the amount of time between two connection events, assuming that the slave skips the maximum number of possible events if slave latency is allowed (the effective connection interval is equal to the actual connection interval if slave latency is set to 0).

The slave latency value represents the maximum number of events that can be skipped. This number can range from a minimum value of 0 (meaning that no connection events can be skipped) to a maximum of 499. The maximum value must not make the effective connection interval (see the following formula) greater than 16s. The interval can be calculated using the following formula: Effective Connection Interval = (Connection Interval) * (1 + [Slave Latency])

Consider the following example:
Connection Interval - 80 (100ms)
Slave Latency - 4
Effective Connection Interval - 100ms * (1 + 4) = 500ms

When no data is being sent from the slave to the master, the slave transmits during a connection event once every 500ms.

Connection Parameter Considerations

In many applications, the slave skips the maximum number of connection events. Consider the effective connection interval when selecting or requesting connection parameters. Selecting the correct group of connection parameters plays an important role in power optimization of the Bluetooth Low Energy device. The following list gives a general summary of the trade-offs in connection parameter settings.

Reducing the connection interval

  • Increases the power consumption for both devices
  • Increases the throughput in both directions
  • Reduces the time for sending data in either direction

Increasing the connection interval

  • Reduces the power consumption for both devices
  • Reduces the throughput in both directions
  • Increases the time for sending data in either direction

Reducing the slave latency (or setting it to zero)

  • Increases the power consumption for the peripheral device
  • Reduces the time for the peripheral device to receive the data sent from a central device

Increasing the slave latency

  • Reduces power consumption for the peripheral during periods when the peripheral has no data to send to the central device
  • Increases the time for the peripheral device to receive the data sent from the central device

How and When Connection Parameters are Set

Connection parameters are initially set when a connection is established between the devices. According to the BLE specification, upon connection establishment, the connection interval shall be set to the recommended value (30-50ms), with 0 slave latency. And when no further action is pending and TGAP time elapses, the central device checks the advertising/scan response data or the peripheral preferred connection parameters characteristic (PPCP) to determine the connection parameter to be used for this connection, which triggers a connection parameter update procedure. On the peripheral side, it can also trigger a connection parameter update procedure after the TGAP time when no further action is pending.

Connection parameters can be changed from the peripheral side during the connection but the negotiation result with the central may not always be successful.