Weird behaviour when dynamic updating connection parameters

[Jur]

Hi all,

I'm working on a project using the nrf52832 with SDK 15.3.0. Our device is battery powered and in peripheral mode. When a central connects it sends +- 300 bytes and disconnects. Then the device goes back to sleep and advertises itself at a slow rate. We are currently working on a bridge that is permanently connected to our device. This means our device is able to sleep less and we should reduce the impact on the battery life by tweaking the connection parameters. However, if no bridge is present we still want a fast connection speed for those small "burst" interactions.
To achieve this I created a "power management characteristic". As soon as the central (our bridge) enables notifications on this characteristic, the device calls sd_ble_gap_conn_param_update and sets new connection parameters that reduce power usage. You can see in Wireshark how the new connection parameters are accepted by the central:

However, they do not seem to be actually applied. Our target payload is transmitted in ~0.2 seconds, like when using our default parameters.
When we boot with the parameters shown in the wireshark dump (so instead of setting them dynamically) our target payload is transmitted in ~1.9 seconds.
How is it possible that despite both devices seem to agree on the new settings they do not seem to be applied?

Thanks a lot

[Kenneth]

Typically when agreeing on new connection parameters, these parameters will take affect some time in future (look for connection event), this is to ensure if there is packet loss/re-transmissions, that they will not loose connection due to difference in connection parameters.

Kenneth

[Jur]

Hi Kenneth, Thanks for your reply! Would you happen to have any indication of how long this is supposed to take?

[Kenneth]

Can you share your sniffer log? Then I can show you how to find it.

Kenneth

[Jur]

Hi Kenneth,

A little change: The low power connection parameters are now applied after the central writes a certain payload to the main characteristic, instead of enabling notifications:

You can see the L2CAP package after the payload is sent. The problem is that right after the LE Connection Update Complete package, my device is sending a NEW L2CAP which requests to go back to the previous settings..

I do not understand why this is happening at all. Could this have something to do with the values passed to ble_conn_params_init ?

Here is a PCAP containing the communication.

connparams2.pcap

[Jur]

UPDATE: it seems like I needed to use 

ble_conn_params_change_conn_params

 instead of 

sd_ble_gap_conn_param_update

!
It seems to work OK now, thanks for looking into this :)

UPDATE2:

I have one more question. ble_conn_params_change_conn_params takes a connection parameter, and when a device disconnects i would like to reset the desired connection parameters back to the original fast parameters. How would I do this without an active connection?

UPDATE3:

This seems to be the default behaviour :)

[Kenneth]

Good to hear you have solved the issue.

A peripheral device can only request the central device to initiate a connection parameter update, so that should explain your UPDATE 1.

Typically a central device will re-connect using the previously used connection parameters yes.

Kenneth

[Jur]

Fair enough! Thanks a lot for taking the time to look into this!