conn_sup_timeout

[ConcourseOscar]

Good day,

We have a requirement for our medical device to detect disconnection of the Bluetooth link in a very timely and consistent manner.

We have an application layer supervisor to check the connection status by checking the last time a valid application layer packet was received. 

We would like to be able to rely on the GATT disconnection event as a backup means of detecting a disconnection as it is critical for the safety of the patient.

Disconnection generates a BLE_GAP_EVT_DISCONNECTED event and gap_evt.params.disconnected.reason is set to 0x08.

We would like to be able to set the exact time that the SoftDevice (S140) will need before it generates a disconnect event. 

We have tried setting

   gap_conn_params.conn_sup_timeout = BLE_GAP_CP_CONN_SUP_TIMEOUT_MIN;

   gap_conn_params.conn_sup_timeout = BLE_GAP_CP_CONN_SUP_TIMEOUT_MAX;

   ...

   err_code = ble_conn_params_change_conn_params(&gap_conn_params, conn_handle);

and either way, we get the same result (disconnection event generated after about 3 seconds).

Nothing we do changes the disconnection timeout. Can you please point us in the right direction as to what conditions are required for a connection to be disconnect and how to set the timing?

Thank you heaps

OP

[Einar Thorsrud]

Hi,

Are we talking about a BLE peripheral or central device? In the following I am assuming a peripheral device.

The connection supervision timeout is one of the essential connection parameters in the Bluetooth protocol. A peripheral can request the supervision timeout as part of a connection parameter update procedure (this is part of what the Connection Parameters Negotiation SDK module that you refer to code helps doing). However, it is always the central that decides.

If you always see 3 seconds I assume that is because the supervision timeout is always 3 seconds? You can verify this from a sniffer trace, or by for instance logging the connection parameters used initially when you get the BLE_GAP_EVT_CONNECTED event and any subsequent BLE_GAP_EVT_CONN_PARAM_UPDATE events.

There are several ways to approach this issue. If you are also making the central, you could simply make the central use the connection parameters you want, and it is able to dictate that. Alternatively, make sure to request the connection parameters you want, typically using the SDK module we have discussed. There are a number SDK examples that do this, for instance the BMS sample (examples/ble_peripheral/ble_app_bms/). But the central can still decide to use other parameters.

[ConcourseOscar]

Thanks for your insight. It took me on the correct path to understand the problem.

I have tried to set 

gap_conn_params.conn_sup_timeout = BLE_GAP_CP_CONN_SUP_TIMEOUT_MIN;

 

Or

gap_conn_params.conn_sup_timeout = BLE_GAP_CP_CONN_SUP_TIMEOUT_MAX;

followed by  sd_ble_gap_ppcp_set during system initialization.

This is hardcoded in all devices. I don't get any BLE_GAP_EVT_CONN_PARAM_UPDATE events in any device.

I have set up a reset button on the peripheral device, I get a BLE_GAP_EVT_DISCONNECTED event on my central about 3 seconds later regardless of settings. 

I'm still trying to figure out why the setting has no effect 

Thanks

OP

[Einar Thorsrud]

It is the central that decide which connection parameters to use, so even if the peripheral requests a different supervision timeout, that may not be used. Or it could be that there is an issue in your application so that you don't actually request new connection parameters.

Can you make a sniffer trace so that we can see what is actually happening on the link? Start with the peripheral advertising, then the connection and keep sniffing for some time so that we will see any connection parameter update procedures. That way we will know more of what is (or is not) happening, so that we will know where to look closer.

[evelynwang]

Hello,

Thank you for sharing the detailed information about your issue. To adjust the Bluetooth disconnection timeout, please ensure that the connection parameters are set correctly. Here are some points to consider:

1. Check the conn_sup_timeout value: Make sure you are using a value within the range of BLE_GAP_CP_CONN_SUP_TIMEOUT_MIN to BLE_GAP_CP_CONN_SUP_TIMEOUT_MAX. If you've tried both without any changes, there might be another issue.

2. Update connection parameters: After setting gap_conn_params, ensure you call ble_conn_params_change_conn_params() with the correct conn_handle and check the returned error code.

3. Check connection status: Ensure there are no interferences from the application or other hardware that could affect the disconnection timing. my location

4. Documentation and examples: Review the SoftDevice S140 documentation for guidance on configuring connection parameters and look for specific examples.

[politicslesson]

The BLE disconnect event timing is dictated by the connection supervision timeout agreed during link negotiation; the peripheral can propose values, but the central ultimately decides—so changing conn_sup_timeout on your side alone won’t override it; to get faster detection you need the central to accept a shorter supervision timeout (minimum 100 ms), otherwise you’ll always see ~3 s default.

bloodmoney