Does the latest version of S110 support BLE 4.1's "Connection Parameters Request Procedure"?

[jprofit]

I'm wondering if the latest version (8.x) of S110 supports BLE 4.1's "Connection Parameter Request Procedure". This procedure is described in the BLE 4.2 spec Volume 6, Part B, Section 5.1.7.

In particular, I would like to know if Nordic supports the ability for a Peripheral Role device to negotiate acceptable connection parameters with a central via LL_CONNECTION_PARAM_REQ and LL_CONNECTION_PARAM_RSP messages.

[Ulrich Myhre]

Hi,

Currently, there is no support for the connection parameter request procedure. We do however support setting the Peripheral Preferred Connection Parameter (PPCP) characteristic, which some centrals might take into account. It is also possible to put PPCP in advertisement data. We also support slave-initiated connection parameter update request, where you can request the central to change the parameters. (Of course, the central is free to choose other parameters, which is probably why you are asking this question.)

For information about future features and advances, please contact your nearest sales representative. If you do not know who this is, send me a message with your location :)

[jprofit]

Thanks for the quick response. I wish the answer was different, however. :)

As I am sure you know, Android ignores PPCP so that isn't going to help me. Unfortunately, latest versions of Android seem to force a 7.5ms connect interval down every peripheral's throat during service discovery and bonding. This is a problem for devices that run off of limited discharge batteries like mine. Due to this recent change in Android, I suspect you may see others who really need this feature added.

[Ulrich Myhre]

Does sending a slave-initiated connection parameter update request, upon connection, have any effect on this? Or does Android just change the parameters temporarily before each of these procedures, and you want to reject them?

Because even with the connection parameter procedure, you will have to wait at least 6 connection intervals before the updated parameters are used. And this is after exchanging a few PDUs for the procedure. If Android connects with 7.5ms and instantly starts discovery, then it might already have finished before the updated parameters have taken effect.

[jprofit]

A slave initiated connection parameter update procedure works, but it doesn't prevent or change the fact that the Android phone will issue its own param update to try to speed up the discovery and bonding related messages. Since my target can't tolerate the 7.5ms connection interval for even for a short time, I can''t respond with the request fast enough to avoid disaster on my target.