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.
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 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 !
Slave Latency doesn't affect the performance at all. If there are data to be exchanged, they are transmitted with the rate determined by Connectio Interval. Slave Latency applies only to periods when there is no data to send.
"The peripheral generally will need to generate a connection parameters update request" In a use case where a peripheral is content with what the central dictates (peripheral doesn't care), is it possible for a central to require a negotiation? That is, what BLE events related to connection parameters MUST a peripheral respond to (to insure a connection is made), when the peripheral app is implemented without the connections module? In other words, the connection module is relatively new to the SDK, and older examples worked without it, is there any code in the older examples that must be used as substitute for the connections module? Maybe BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST?
