BLE Central disconnect after exactly 65.5 sec

RE: BLE Central disconnect after exactly 65.5 sec

Marius Heil — Tue, 13 Aug 2019 13:38:11 GMT

Hi, I am not quite sure if I correctly understood the answer. Was this a confirmed softDevice bug? i created a ticket of my own for a similar issue: https://devzone.nordicsemi.com/f/nordic-q-a/50942/still-trouble-with-ble_gattc_evt_timeout

RE: BLE Central disconnect after exactly 65.5 sec

Gordon — Tue, 07 Mar 2017 13:26:40 GMT

Great - thanks for all your help, and for looking in to this further! So it really was just one bug (the central mode) after all.

RE: BLE Central disconnect after exactly 65.5 sec

Petter Myhre — Tue, 07 Mar 2017 11:38:59 GMT

The SoftDevice is disconnecting because the central is not responding to the CPU Request. By not responding it is breaking the specification, and this causes the disconnect after 60 seconds. So it is not a bug, it is expected behavior. The solution is to make the central respond, either with accept or reject. You are ending up in variant #3 in this MSC, but it is incorrect, because you don't get BLE_GAP_EVT_CONN_PARAM_UPDATE. Instead the SoftDevice disconnects, and you receive BLE_GAP_EVT_DISCONNECTED. I have reported this.

RE: BLE Central disconnect after exactly 65.5 sec

Gordon — Mon, 06 Mar 2017 14:28:15 GMT

Fantastic - thanks!

RE: BLE Central disconnect after exactly 65.5 sec

Petter Myhre — Mon, 06 Mar 2017 14:25:17 GMT

I missed that. I investigated some more, and was able to reproduce. This seems like a bug, but I will have to talk with the developers, will add a comment here as soon as I know more.

RE: BLE Central disconnect after exactly 65.5 sec

Gordon — Mon, 06 Mar 2017 09:53:29 GMT

on_conn_params_evt is empty and disconnect_on_fail was set to false - so I'm really struggling to see how it managed to disconnect. Also, when disconnected it gave BLE_HCI_LOCAL_HOST_TERMINATED_CONNECTION, but I assume that if ble_conn_params were the thing that disconnected it should have reported BLE_HCI_CONN_INTERVAL_UNACCEPTABLE?

RE: BLE Central disconnect after exactly 65.5 sec

Petter Myhre — Mon, 06 Mar 2017 09:49:29 GMT

The new sniffer trace makes much more sense :) Your suggested solutions should be sufficient. If you set disconnect_on_fail to false the connection negotiation module shouldn't automatically disconnect, are you sure the disconnection isn't done from on_conn_params_evt()?

RE: BLE Central disconnect after exactly 65.5 sec

Gordon — Fri, 03 Mar 2017 16:02:18 GMT

I'm happy to provide hex images and instructions if it helps at all?

RE: BLE Central disconnect after exactly 65.5 sec

Gordon — Fri, 03 Mar 2017 16:01:58 GMT

Ok, adding a BLE_GAP_EVT_CONN_PARAM_UPDATE_REQUEST handler seems to have fixed the central mode issue... I'm still a bit worried that a connection by something that doesn't support it seems to cause a disconnect even though disconnect_on_fail is false

RE: BLE Central disconnect after exactly 65.5 sec

Gordon — Fri, 03 Mar 2017 15:43:55 GMT

I've just added more traces - I think the original trace might have broken somehow. This time there's an obvious disconnection from the peripheral and the Empty PDUs keep coming until the end (which makes sense as the DK is responsive via BLE right until the end).

So ideally I guess there are 2 fixes needed: Make the central mode negotiate connection parameters if asked, but also stop the peripheral mode auto-disconnecting if it fails? If it helps this is the ble_conn_params code that seems to be causing the issue for the peripheral: github.com/.../d006094b20e4598633abb6822131ab5bb2e901e1

RE: BLE Central disconnect after exactly 65.5 sec

Petter Myhre — Thu, 02 Mar 2017 10:23:51 GMT

I don't know why you get disconnected. Could you do a new sniffer trace with Android? And another one with the DK as a central? Maybe you can try to change the connection parameters? What happens if you increase the minimum connection interval? To say, 30 ms?

RE: BLE Central disconnect after exactly 65.5 sec

Gordon — Wed, 01 Mar 2017 16:59:22 GMT

Actually this isn't usable at the moment - removing 'ble_conn_params' has stopped the PC lowering the connection interval, so now the communication speed is significantly slower. So how can I have 'ble_conn_params', but make it so there aren't disconnects if the central isn't responding? I think I have this problem on iOS too where the connection just drops out after 60 seconds.

RE: BLE Central disconnect after exactly 65.5 sec

Gordon — Wed, 01 Mar 2017 16:20:36 GMT

Ahh, thanks! That explains a lot (like why the interval was much less than I was expecting). So do we have any idea how it could have been disconnecting? Or was it somehow updating the parameters such that the interval for transmissions was far too high?

RE: BLE Central disconnect after exactly 65.5 sec

Petter Myhre — Wed, 01 Mar 2017 15:57:22 GMT

Not really negotiated, the central decides what connection parameters to use upon connection. Then the central can do a connection parameter update (with or without the peripheral sending a connection parameter update request first).

RE: BLE Central disconnect after exactly 65.5 sec

Gordon — Wed, 01 Mar 2017 10:25:04 GMT

Ok - but those are negotiated at the start? It's only if I wanted to be able to change them 'on the fly'?

RE: BLE Central disconnect after exactly 65.5 sec

Petter Myhre — Wed, 01 Mar 2017 10:18:37 GMT

Difficult to say if it is important for your application or not, without it the peripheral will not send connection parameter update requests, it will not request to update the connection parameters (connection interval, slave latency, connection supervision timeout).

RE: BLE Central disconnect after exactly 65.5 sec

Gordon — Tue, 28 Feb 2017 15:27:08 GMT

Odd - actually I didn't notice the gap. I assumed it went straight from the PDUs to advertising. But yes, advertising starts again immediately on disconnection. I had been using ble-conn-params because that's what was used in one of the other examples - but have just removed that and it now works (even though disconnect_on_fail was false before). Just before I set this to answered - what am I missing by not having ble-conn-params - is it anything important?

RE: BLE Central disconnect after exactly 65.5 sec

Petter Myhre — Tue, 28 Feb 2017 15:15:08 GMT

Thx. I'm not sure what is happening here, but from the sniffer trace it doesn't seem like the peripheral is disconnecting. From the trace it seems like there is no communication after 30.5s, and then 35s later the peripheral starts to advertise again? Do you start advertising again when you get the disconnection event? It also seems like the peripheral is sending a Connection Parameter Update request, are you calling sd_ble_gap_conn_param_update() somewhere? If you are, could you try not doing that? Please add the new sniffer trace as well.

RE: BLE Central disconnect after exactly 65.5 sec

Gordon — Tue, 28 Feb 2017 14:33:48 GMT

Just edited to add a sniffer trace

RE: BLE Central disconnect after exactly 65.5 sec

Petter Myhre — Tue, 28 Feb 2017 13:25:32 GMT

Not exactly, but it might give some clues on what is happening.

RE: BLE Central disconnect after exactly 65.5 sec

Gordon — Tue, 28 Feb 2017 13:24:16 GMT

I don't - but could probably get one. Any idea what I'd be looking for? I mean, BLE_HCI_LOCAL_HOST_TERMINATED_CONNECTION implies that it might be a software issue on the peripheral

RE: BLE Central disconnect after exactly 65.5 sec

Petter Myhre — Tue, 28 Feb 2017 13:08:52 GMT

Thanks for checking. I had to ask ;) Do you have a sniffer trace?

RE: BLE Central disconnect after exactly 65.5 sec

Gordon — Tue, 28 Feb 2017 11:18:38 GMT

Ok, now I'm certain. I renamed the function in ble_gap.h and added a stub that printed if it was called. sd_ble_gap_disconnect is never called - by anything outside the softdevice - in my code or Nordic's.

RE: BLE Central disconnect after exactly 65.5 sec

Gordon — Tue, 28 Feb 2017 11:12:33 GMT

Yes, pretty sure. I guess it could be called from one of Nordic's libs - eg ble-conn-params - but I'd expected that if it did, I'd get a different reason than BLE_HCI_LOCAL_HOST_TERMINATED_CONNECTION, since it sends BLE_HCI_CONN_INTERVAL_UNACCEPTABLE?

RE: BLE Central disconnect after exactly 65.5 sec

Petter Myhre — Tue, 28 Feb 2017 10:55:27 GMT

I don't think you will get BLE_HCI_LOCAL_HOST_TERMINATED_CONNECTION without calling sd_ble_gap_disconnect(), but I'm not 100%. Are you absolutely sure you are not calling sd_ble_gap_disconnect()?