Supervision timeout Multiplier - Connection supervisory timeout

[Marc]

Hi,

I made an experiment and the result doesn't correspond with my view on how the BLE communication "connection" mechanism works.

I have an app running on the nRF52832 using example code and here is what I use as a supervisor timeout delay of 4 seconds:

#define CONN_SUP_TIMEOUT                 MSEC_TO_UNITS(4000, UNIT_10_MS)             /**< Connection supervisory timeout (4 seconds). */

...

memset(&gap_conn_params, 0, sizeof(gap_conn_params));

gap_conn_params.min_conn_interval = MIN_CONN_INTERVAL;
gap_conn_params.max_conn_interval = MAX_CONN_INTERVAL;
gap_conn_params.slave_latency     = SLAVE_LATENCY;
gap_conn_params.conn_sup_timeout  = CONN_SUP_TIMEOUT;

err_code = sd_ble_gap_ppcp_set(&gap_conn_params);
APP_ERROR_CHECK(err_code);

I have a Faraday cage, grounded, www.everythingrf.com/.../718-645-tc-5921ae

With this box, I put the nordic device in it and I can cut the communication by closing the box. Using a USB Serial that pass thru the box, I can monitor device events such as disconnection.

Using a computer Bluetooth dongle I initiated the BLE connection, close the box and measure the time I see the disconnect message in the log. We did this to check the device reliability and as expected, the device disconnect after 4 seconds. This was repeated a lot.

I repeated the experiment but this time with an Android device, Alcatel One touch Idol 3, with the nRF Connect app. With this setup, the delay before disconnection is around 20 seconds!

My understanding of 'conn_sup_timeout' is the delay of no activity (no "connection packet" received) before assuming the connection lost and disconnect.

How the central device, Android or PC, could affect or change this interval?

Thanks

[Marc]

By updating the connection parameters settings with this function: (note the "ble_conn_params_change_conn_params()" )

static void gap_params_update(void)
{
uint32_t                err_code;
ble_gap_conn_params_t   gap_conn_params;
memset(&gap_conn_params, 0, sizeof(gap_conn_params));

gap_conn_params.min_conn_interval = MIN_CONN_INTERVAL;
gap_conn_params.max_conn_interval = MAX_CONN_INTERVAL;
gap_conn_params.slave_latency     = SLAVE_LATENCY;
gap_conn_params.conn_sup_timeout  = CONN_SUP_TIMEOUT;

err_code = ble_conn_params_change_conn_params(&gap_conn_params);
APP_ERROR_CHECK(err_code);
}

And calling this function after a "Connected" event like this:

    case BLE_GAP_EVT_CONNECTED:
        printf("Connected!\r\n");
        m_conn_handle = p_ble_evt->evt.gap_evt.conn_handle;
        gap_params_update();
        ...

I eliminated the issue. My device will disconnect after 4 seconds, as desired, regardless of Dongle connection or Android.

However

Calling ble_conn_params_change_conn_params() while receiving packets seems to drop the packets. I put the ble_conn_params_change_conn_params() call at a strategic place (when receiving a message so the central wait for a reply, called once after a connection) and it did work with the PC dongle. But unfortunately even this seems to mess with the android device and after some data transfer it stop working.

I suspect that the min/max_conn_interval get changed too and reverting them is not an option. With the current API it doesn't seem possible to read back this information so my "solution" is unusable.

So I guess I'm stuck with the original behavior.

[endnode]

(use a sniffer use a sniffer;) Now you are debugging black box, not seeing what is actually exchanged over the air leads to just guessing and burning valuable time.