nRF52 as central: bad parameters requested by peripheral

[thefool]

We have an nRF52 with dual roles: peripheral for the connection to an app, and central, connecting to multiple third party peripheral devices.

we have a few problems with parameter negotiation as central. The current one is that one of the peripherals seems to be requesting illegal parameters:

When handling BLE_GAP_EVT_CONN_PARAM_UPDATE_REQUEST

we get these:

min_conn_interval: 6
max_conn_interval: 32
slave_latency: 0
conn_sup_timeout: 10000

but allowed are only conn_intervals 6-3200, slave_latency 0-499, conn_sup_timeout 10-3200.
Plus if both conn_sup_timeout and max_conn_interval are specified: conn_sup_timeout * 4 > (1 + slave_latency) * max_conn_interval.

ie the supervision timeout requested is too long.
sd_ble_gap_conn_param_update() fails with ERROR 0x00000007 (NRF_ERROR_INVALID_PARAM)

But If I edit the connection parameters before calling sd_ble_gap_conn_param_update(), with the edited copy, the peripheral disconnects after a while with reason 0x22 (LL_RESPONSE_TIMEOUT)

This happens about 40s after the negotiation, even if I receive data in those 40s

Any best practises how to handle such "illegal requests"?

[Einar Thorsrud]

Hi,

It is difficult to know why the peripheral does what it does without knowing the implementation of it. It is probably best to reject the request when it is invalid. To do that, pass NULL as the second parameter when you call sd_ble_gap_conn_param_update().

[thefool]

I'll get in touch with the manufacturer, to notify them of the issue and ask why they chose those values. 

I tried NULL: that works in this case! Thanks

Is modifying(fixing) the requested parameters before telling the soft device to update them not allowed? i.e is it either accept or reject?

And a related question: lets say in this case I want our central to negotiate a connection interval of 32 instead of the 6, in an attempt to save power. How would I do that, if not by modifying the requested parameters? 

[Einar Thorsrud]

Hi,

Good to hear declining the request works. I have not been able to find anything in the Bluetooth specification that states that it is not allowed to respond with other parameters (reading 5.1.1 Connection Update procedure, starting from page 2869 in version 5.3 of the spec). It could be just that it is not handled properly by this specific peripheral implementation.

thefool said:

How would I do that, if not by modifying the requested parameters? 

Then you use sd_ble_gap_conn_param_update(), but not as a response to a request. In this case you use the same function - sd_ble_gap_conn_param_update(), and this will initiate a connection parameter update procedure. (In other words, this is not only used to respond to a BLE_GAP_EVT_CONN_PARAM_UPDATE_REQUEST event). 

[thefool]

OK, so you're saying how I tried to do it would be OK according to spec and to your implementation (modifying a copy of the parameters before calling sd_ble_gap_conn_param_update() with this copy)?

Good to know calling sd_ble_gap_conn_param_update() outside of the UPDATE_REQUEST event would work.

[Einar Thorsrud]

Yes. It works with our implementation, and I am not able to see anything in the spec that says it should not be allowed.