Long time to disconnect

[nordev]

Hi, 

Our NRF52840 (running 14.2) often takes a very long time to disconnect, from when a disconnection is initiated by the phone. It can take 30s, sometimes even more, for the disconnect to happen. Sometimes the disconnect happens immediately like it should, but I would say that it is more common for the disconnect to take a long time than for the disconnect to be normal. 

I installed the NRF Sniffer and have done a capture, but I am not really sure what to make of the result. 

The below was a bad disconnect. Here, the highlighted line was about when the disconnect was initiated on the phone (image 1). Then I got "Empty PDU" for a long time. The empty PDU continues for a long time, with only one "encrypted packet decrypted incorrectly" in between, then in the second image, the highlighted line shows when the disconnect actually happens. There is ~13 sec in between the initiation and the actual disconnect.

By contrast, this was one of the times that I got a normal disconnection. 

The above was done with our custom app. The issue also happens when using the NRF Connect App for iOS. For reference, below is the capture when the disconnect was initiated by the NRF app:

I pressed the disconnect button around the time of this highlighted line: 

There is no command of any kind here though; the closest command is this one (but I don't know if they're even related, this is just the first command I found when scrolling up):

The disconnect comes what looks like 23 seconds later: 

My questions:

(MAIN QUESTION) How can I find out why it is taking a long time to disconnect? Note that it happens with different phones, but we have only been able to test with iPhones so far.

AUXILLIARY QUESTIONS: 

1. What are control opcodes and why do they only show up in the test using the NRF app, but not our custom app? Should we do something to enable these opcodes? 

2. What is empty PDU? 

3. What is "bad MIC"?

4. Where do I learn about how to interpret the captured packets? I read this but it doesn't really explain what I should be looking for.

Thanks!

[nordev]

Hi Joakim Jakobsen, are you still planning to look at this today?

EDIT: the below is now obsolete. I changed this parameter from 30,000 to 10,000; also tried 2000. It did not seem to affect the length of the disconnects. When this param was = APP_TIMER_TICKS(10000), the disconnect times were: 13s, 28s, 23s, 20s, 27s, 24s, 11s, 20s. When it was 2000, it was 28s. So I concluded that NEXT_CONN_PARAMS_UPDATE_DELAY  does not actually seem to have an effect on the long disconnect.

===================

xxxxxxxxxxxxxxxxxxxxxxxxxxxx

I suspect the issue has something to do with this:

#define NEXT_CONN_PARAMS_UPDATE_DELAY    APP_TIMER_TICKS(30000)  

30s is the longest-defined delay, and it is approximately the right length, considering the lengths of the timeouts I'm receiving.

Can you tell me more about when sd_ble_gap_conn_param_update() gets called? What processes call it? How is it involved in disconnects?

Thanks!

[nordev]

Hello Joakim Jakobsen, just sending another ping so that you don't miss it again. Thanks!

[Joakim Jakobsen]

Thanks for the reminder.

I haven't missed your reply this time.

I don't believe that NEXT_CONN_PARAMS_UPDATE_DELAY has anything to do with the disconnect times.

Are you seeing this behaviour using the stock ble_app_bms example and nRF Connect? I've tested that and I don't see any delay in the disconnect.
From the code you uploaded, it seems that the disconnect is handled correctly. When the BLE_GAP_EVT_DISCONNECTED event is received by the application.

I think the problem is that the disconnect event isn't received by the application, and it disconnects upon the CONN_SUP_TIMEOUT instead, when not receiving any response from the central. What is the CONN_SUP_TIMEOUT defined as?

Br,
Joakim

[nordev]

I think I already answered your questions above, but for convenience, I have quoted them for you here:

Joakim Jakobsen said:

What is the CONN_SUP_TIMEOUT defined as?

As you can see here, this is CONN_SUP_TIMEOUT is 5 seconds:

nordev said:

here is some code: 

#define CONN_SUP_TIMEOUT                 MSEC_TO_UNITS(5000, UNIT_10_MS)

Joakim Jakobsen said:

Are you seeing this behaviour using the stock ble_app_bms example and nRF Connect?

As you can see here, I did not experience a delay using the stock ble_app_bms example.

nordev said:

i have tried loading a Nordic example to see if the issue persists. The one I used is ble_app_bms. The disconnects happen immediately, so the problem must be somewhere in my code

[Joakim Jakobsen]

Thanks.

Do you have a minimized project  where I can reproduce this that you can upload here, so that I can test on my end. That way I can take a closer look at what is going on?

Br,
JOakim