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

[endnode]

Because on the other side you are never sure if your RF isolation really works 100% unless you see the packets on link layer where Master (Central) should be repeating PDUs with the same SN/NESN flags (showing no response detected).

[endnode]

No, that's wrong, there is GAP TIMEOUT event (and many more, if you really do exhaustive test like this I assume you print everything to debug output...)

[endnode]

See respective SD flow chart (sequence diagram).

[Marc]

No we don't have such analyser. Long story about this cage but we don't have the luxury having such analyser. Having a leaky faraday cage would get inconsistent results (sometime 4 sec, 10sec, 20sec, etc), I assume having a consistent delay imply that the faraday cage works. Even if I don't trap the "right" event, why it is different between the PC and the Android device?

[endnode]

Interesting question. Not having sniffer you have only event trace from nRF FW's SD event handle on Nordic so firstly log everything over UART or RTT. Also using Nordic sniffer on $40 nRF51 DK might give you some more data with little bit of patience (it's nice tool but cannot compete with several thousand USD devices from Frontline or similar companies so you need to do more re-tries to catch all necessary packets).