Connection param update delay

[James Yu]

I'm running into a weird problem where there is a long delay that is variable between calling ble_conn_params_change_conn_params() and receiving the BLE_GAP_EVT_CONN_PARAM_UPDATE event.

I have the following connection params:

#define MIN_CONN_INTERVAL_IDLE          MSEC_TO_UNITS(500, UNIT_1_25_MS)
#define MAX_CONN_INTERVAL_IDLE          MSEC_TO_UNITS(1000, UNIT_1_25_MS)
#define MIN_CONN_INTERVAL_CAL           MSEC_TO_UNITS(250, UNIT_1_25_MS)
#define MAX_CONN_INTERVAL_CAL           MSEC_TO_UNITS(500, UNIT_1_25_MS)

#define SLAVE_LATENCY                   0      
#define CONN_SUP_TIMEOUT_IDLE           MSEC_TO_UNITS(4000, UNIT_10_MS)
#define FIRST_CONN_PARAMS_UPDATE_DELAY  APP_TIMER_TICKS(1000, APP_TIMER_PRESCALER)
#define NEXT_CONN_PARAMS_UPDATE_DELAY   APP_TIMER_TICKS(30000, APP_TIMER_PRESCALER)
#define MAX_CONN_PARAMS_UPDATE_COUNT    3

I'm using an iOS device as a central and according to Apple's Bluetooth Design Guidelines (developer.apple.com/.../BluetoothDesignGuidelines.pdf) my connection params are valid.

Here's the log of one run:

[11:11:35:263] Start advertisement
[11:12:01:449] Connected
[11:12:01:702] Auth correct
[11:12:02:840] Conn param update: 798, 798
[11:12:02:840] BLE_CONN_PARAMS_EVT_SUCCEEDED
[11:13:16:142] Update connection parameters: CAL
[11:13:30:110] Conn param update: 399, 399
[11:13:30:110] BLE_CONN_PARAMS_EVT_SUCCEEDED
[11:14:07:305] Update connection parameters: IDLE
[11:14:14:282] Conn param update: 798, 798
[11:14:14:282] BLE_CONN_PARAMS_EVT_SUCCEEDED

So the first param update occurred about 1 sec after the connect event so that is correct. But there is 14 sec delay for the 2nd conn param update and a 7 sec delay for the 3rd.

Here's another run:

[11:15:27:190] Start advertisement
[11:15:55:492] Connected
[11:15:55:765] Auth correct
[11:15:56:902] Conn param update: 798, 798
[11:15:56:902] BLE_CONN_PARAMS_EVT_SUCCEEDED
[11:16:56:885] Update connection parameters: CAL
[11:17:17:840] Conn param update: 399, 399
[11:17:17:840] BLE_CONN_PARAMS_EVT_SUCCEEDED
[11:17:49:951] Update connection parameters: IDLE
[11:17:58:926] Conn param update: 798, 798
[11:17:58:926] BLE_CONN_PARAMS_EVT_SUCCEEDED

Once again the first param update is correct but now the delay for the 2nd update is 21 sec and 9 sec for the 3rd update.

What is going on here? Why are the delays so long and different between updates? Is this something that iOS does which is not documented? Or am I missing something here?

Thanks for your help.

[awneil]

Related: devzone.nordicsemi.com/.../ ?

[Ulrich Myhre]

Hi James,

The Connection Parameter Update procedure requires you to wait at least 6 connection intervals before actually doing the update. Additionally, the peripheral side can only request an update from the central*, and the central has to receive, process and respond to this request before initiating the actual update. If your connection interval is slow, e.g. 1000ms, this initial exchange of packets can easily take 2*1000ms. Then there is a minimum of 6*1000ms from the exchange until the parameters have updated. This delay is mandated by the specification, to make sure that both sides have a good chance to receive the information about the change before it happens.

The variable delays you are seeing are a consequence of this. Changing from a slow connection interval is slow, and from a fast is fast. If you add slave latency into the mix, the slowness will be multiplied with the latency count.

* There is a Connection Parameter Request procedure that lets the slave initiate now, but our current SoftDevices do not support it.

[James Yu]

Thanks for the info, its clear now. I have a followup question: Since my purpose for using the update procedure is to periodically burst notification data to the central, should I wait until the parameters are updated to the shorter interval before sending the notifications? Can I begin notifications with the current parameters or can that potentially delay the update even further?

[run_ar]

You can begin notifications with the current parameters.