Connection param update delay

RE: Connection param update delay

run_ar — Wed, 18 May 2016 05:51:29 GMT

You can begin notifications with the current parameters.

RE: Connection param update delay

James Yu — Fri, 13 May 2016 15:12:18 GMT

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?

RE: Connection param update delay

Ulrich Myhre — Fri, 13 May 2016 07:29:25 GMT

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.

RE: Connection param update delay

awneil — Thu, 12 May 2016 22:51:51 GMT

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