For a BLE link the connection parameters control the fequency at which data can be exchanged between the peripheral and central once a BLE link has been established between the two. These parameters are negotiated between the central and master during link establishment. Examples of connection parameters are as follows.
a. Connection Interval (CI): The central sets the CI when the BLE connection is first established between central and peripheral. The peripheral specifies interval minimum and maximum values, which are the upper and lower limits of the connection interval desired by the peripheral. Most centrals will use some default CI, and will generally ignore the max. and min. numbers specified by the peripheral. The peripheral generally will need to generate a connection parameters update request some time after the BLE connection is established, to try and change the CI that is within the range. The central will respond with a connection interval that may or may not be in this range. If the peripheral accepts the number, this will be the new CI.
b. Slave latency
c. Connection supervisory timeout.
The connection interval and slave latency typically affect the performance of a BLE link the most. The lower the slave latency and faster the connection interval the faster the effective data transfer rate between the peripheral and central. On the other hand this also leads to higher average current consumption in the peripheral.
The connection parameters for a BLE connection is a set of parameters that determine when and how the Central and a Peripheral in a link transmits data. It is always the Central that actually sets the connection parameters used, but the Peripheral can send a so-called Connection Parameter Update Request, that the Central can then accept or reject.
There are basically three different parameters:
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.5 ms and 4 s.
Slave latency: By setting a non-zero slave latency, the Peripheral can choose to not 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. The text book example of such device is for example keyboard and mice, which want to be sleeping for as long as possible when there is no data to send, but still have low latency (and for the mouse: low connection interval) when needed.
Connection supervision timeout: This timeout determines the timeout from the last data exchange till a link is considered lost. A Central will not start trying to reconnect before the timeout has passed, so if you have a device which goes in and out of range often, and you need to notice when that happens, it might make sense to have a short timeout.
Depending on which platform you're working with, there can be platform specific recommendations or requirements on these. For iOS, Apple maintains a "Bluetooth Accessory Design Guidelines" document, which among other things includes rules on these parameters.
"When the Peripheral requests an update, it supplies a maximum and a minimum wanted interval. " I think the Peripheral tells the Central the max and min connection interval , and the central will respond with a connection interval that may or may not be in this range.
But what's the real connection interval ,for example , in the project of *\nrf51822\Board\nrf6310\s120\experimental\ble_app_multilink_central? Is the Central determine the connection interval ?And how can I change the connection interval?
"The central will respond with a connection interval that may or may not be in this range."
Then what happens if the CI is not in the range ? How is it dealt by the Central / by the peripheral ?
Thx in advance !
" A Central will not start trying to reconnect before the timeout has passed"，I wonder if the central will try to reconnect until the timeout has passed and if there is no answer, then makes a decision that it is lost? Since there can be an accidental lose.
