How does conn_param_update behave?

[Thomas]

Hi,

Because we heavily depend on timeslots we cannot do the main work before the parameters are honored. But we were experiencing some issue's with the standard implementation of the connection parameters negotiation procedure. The timer would not go off after the expected duration.

Therefore we made our own implementation. We noticed that the BLE_GAP_EVT_CONN_PARAM_UPDATE would fire before we even requested an update. How is that possible? We only connect using a Android smartphone and looking at the hci log there isn't any request from Android. Can we have our implementation depend on the event being fired?

Also what's the motivation behind the delay in the original implementation provided? Are there any specs we can look at?

[Ulrich Myhre]

Hi Thomas,

The Connection Parameter Update feature can only be initiated by the central. When you are calling sd_ble_gap_conn_param_update as a peripheral (e.g. S110), you are only sending a request to the central asking it "Please set the new connection parameters between X and Y". The Central can then accept or reject the request. If it accepts, the central is still free to choose whatever parameters it wants, completely ignoring your wishes. This is all by the official Bluetooth Specification (linked in one of the questions below).

The central can also initiate the procedure without the peripheral asking for it, which is why you were seeing the event fire before the request going out. Central will never send any L2Cap traffic when doing so, unless the peripheral has sent a request first.

For more information, see these questions:

devzone.nordicsemi.com/.../

devzone.nordicsemi.com/.../

Especially the guidelines for the various mobile operating systems.

[Thomas]

I cant find any information about the delay between connecting and requesting a parameter change in the Bluetooth specification. Is this minimum delay platform dependent?

[Ulrich Myhre]

When the new parameters are negotiated, the spec mandates that you must schedule the change at least 6 connection events into the future. Depending on the current connection interval, this can be quite a long delay. This is listed in Bluetooth Spec 5.0, Vol 6, Part B, Ch 5.5 "Procedures with instants".