Supervision timeout Multiplier - Connection supervisory timeout

RE: Supervision timeout Multiplier - Connection supervisory timeout

endnode — Thu, 31 Aug 2017 16:16:51 GMT

(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.

RE: Supervision timeout Multiplier - Connection supervisory timeout

endnode — Thu, 31 Aug 2017 16:05:14 GMT

Only RF log will tell you, hardly some piece of paper...

RE: Supervision timeout Multiplier - Connection supervisory timeout

Marc — Thu, 31 Aug 2017 14:55:10 GMT

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.

RE: Supervision timeout Multiplier - Connection supervisory timeout

Marc — Thu, 31 Aug 2017 13:21:07 GMT

The phone is Central (Master). I'll try to find in doc a way to read back the supervisor variable to see if it has changed after an android connection.

RE: Supervision timeout Multiplier - Connection supervisory timeout

endnode — Wed, 30 Aug 2017 21:23:06 GMT

Btw. I missed the important part: is your phone Master (GAP Central)? If yes then what are connection parameters set in connection request? It can easily be 20s;) Print out all events and on some like connection established or connection parameters' update it would be good to print out also event data...

RE: Supervision timeout Multiplier - Connection supervisory timeout

endnode — Wed, 30 Aug 2017 21:21:04 GMT

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).

RE: Supervision timeout Multiplier - Connection supervisory timeout

Marc — Wed, 30 Aug 2017 21:13:32 GMT

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?

RE: Supervision timeout Multiplier - Connection supervisory timeout

endnode — Wed, 30 Aug 2017 21:07:45 GMT

See respective SD flow chart (sequence diagram).

RE: Supervision timeout Multiplier - Connection supervisory timeout

endnode — Wed, 30 Aug 2017 21:06:10 GMT

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...)

RE: Supervision timeout Multiplier - Connection supervisory timeout

endnode — Wed, 30 Aug 2017 21:05:25 GMT

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).

RE: Supervision timeout Multiplier - Connection supervisory timeout

Marc — Wed, 30 Aug 2017 21:05:10 GMT

This is the event I use to conclude I'm disconnected:

        case BLE_GAP_EVT_DISCONNECTED:
        printf("Disconnected!\r\n");
        m_conn_handle = BLE_CONN_HANDLE_INVALID;

RE: Supervision timeout Multiplier - Connection supervisory timeout

endnode — Wed, 30 Aug 2017 21:03:57 GMT

Otherwise indeed connection parameters including Supervision timeout can change during the connection, you should use network analyzer/sniffer to observe when and how exactly the link is terminated by master. Seeing your expensive cage equipment I assume you have that as well...

RE: Supervision timeout Multiplier - Connection supervisory timeout

endnode — Wed, 30 Aug 2017 21:02:29 GMT

You are right, I'm talking about time-out on "lost" connection on phone side (so GAP Central in your case I suppose). Nordic app should get proper event from SoftDevice at right time. Are you sure you print all SD events coming to your handler?

RE: Supervision timeout Multiplier - Connection supervisory timeout

Marc — Wed, 30 Aug 2017 20:59:01 GMT

Just to confirm, are you talking about the timeout in central(Android) or peripheral(Nordic)?

Because when the faraday cage is closed, the Nordic device becomes alone in its world. It then rely to nothing else but its supervisor implemented in the softdevice.

If the delay differ, does it mean the central "override" the value of the supervisor timeout somehow at the negociation when connecting?

RE: Supervision timeout Multiplier - Connection supervisory timeout

endnode — Wed, 30 Aug 2017 20:50:18 GMT

No, there is nothing wrong on your side and not much you can do, this is world of hundred thousand Android devices with embedded BT (+BLE) stacks written by people who don't care much about the specifications. I've seen different time-outs on different Android 4.4-6.0 devices, things between 1 and 20 seconds regardless Supervision timeout value set in Connection Request parameters. In the end I just swore to my cup of tea and accepted it as fact. Welcome to the business!:)