Long time to disconnect

RE: Long time to disconnect

Karl Ylvisaker — Tue, 11 May 2021 09:23:32 GMT

Hello again Nordev,

[quote user="nordev"]This is the sniffer hex file I am using. I followed the sniffer setup steps months ago, so I don't remember exactly where I got it from. But the instructions I used were here. I am not sure that I got it from the SDK, but I am sure I got it straight from a Nordic source, and I definitely did not modify the sniffer prior to using it. [/quote]

This seems to be our official sniffer firmware, yes. Thank you for clarifying.

[quote user="nordev"]I don't know what changed, but suddenly I seem able to sniff the connection as expected:[/quote]

I am glad to hear it is working as expected now, at least.
For future reference, it would be better if you uploaded the trace instead of screenshots, so I may take a look at it myself.

[quote user="nordev"]The problem is if I let the phone screen go dark, it turns back to "bad mic" [/quote]

Are you saying that the sniffer will start reading bad mic packages if you let the screen on your phone go dark? Is this consistently happening?
It would be great if you could upload a sniffer trace of this, and indicate which packet number this behavior starts on, so I may take a closer look.
This sounds very strange to me, and I have never heard of anything like it before, but if this turns out to be correlated I suppose there have to be some other power saving setting setting in at the same time as the screen goes dark. Again, this sounds very strange to me, and I'd love to see a trace of this so I may try to understand it better.
Bad mic packets primarily happens when the sniffer is unable to decrypt the packet, so unless the devices update this (without the sniffer seeing it), I dont immediately see how this could happen.

[quote user="nordev"]Advertising PHY is LE 1M. What does that mean? Low Energy 1Mbps? [/quote]

Correct.

[quote user="nordev"]

Sample captures while disconnecting are below:

When I press disconnect BEFORE the 30s is up, I get a lot of Empty PDU after I press disconnect on the phone.

[/quote]

Great detail to your explanation! It is good that you relate everything to the packet number. However, here it would be great for me to have the sniffer trace myself, so I can see more than just the packets included in the screenshot.
Could you please provide me the complete trace - use the "Insert -> File" option here on DevZone - so I may go through your detailed explanation here, but rather see it in the trace directly? This would make the debugging much easier.

[quote user="nordev"]time 209.819[/quote]

Please be advised that the 'time' column is USB time (i.e when wireshark reads it from the sniffer device), and it is thus not as accurate as the delta time column, for example.

[quote user="nordev"]Any ideas what is happening? Is there other data you want me to collect?[/quote]

It is unfortunately not immediately clear from the description and screenshots alone. I find it very strange that the sniffer suddenly is unable to decrypt the packets, so it would be great to have a look at the packets leading up to this.
Please provide the full trace file(s), so I may take a look for myself.

I look forward to getting to the bottom of this weird behavior you describe in your comment! 🙂

Best regards,
Karl

RE: Long time to disconnect

nordev — Thu, 06 May 2021 18:57:03 GMT

Hi Karl,

This is the sniffer hex file I am using. I followed the sniffer setup steps months ago, so I don't remember exactly where I got it from. But the instructions I used were here. I am not sure that I got it from the SDK, but I am sure I got it straight from a Nordic source, and I definitely did not modify the sniffer prior to using it.

I don't know what changed, but suddenly I seem able to sniff the connection as expected:

The problem is if I let the phone screen go dark, it turns back to "bad mic"

But I can just delete the bonds from the phone and let the sniffer sniff the pairing process. this should be good enough for testing, I think!

Advertising PHY is LE 1M. What does that mean? Low Energy 1Mbps?

Sample captures while disconnecting are below:

When I press disconnect BEFORE the 30s is up, I get a lot of Empty PDU after I press disconnect on the phone.

A) Then I eventually got this (#21714, time 209.819):

B) Then I get this later (#21889, time 212.578)

I tried again keeping better track of time this time:

all this stuff happened ~504 (pairing)

@ 512, got this:512.641 Master_0x5065659d Control Opcode: LL_CHANNEL_MAP_IND

~519 pressed disconnect. Got this (mostly empty PDU, all packets were Bad Mic from 515 onward, but they are very sparse -- maybe 3 total packets before the final disconnection)

~537 finally disconnected Same kind of packet flow as B above, except instead of the actual opcode, I got "bad mic" this time for the last message (I assume it was the termination opcode though)

If I wait MORE than 30s to disconnect, then I get this and it disconnects immediately.

Any ideas what is happening? Is there other data you want me to collect?

RE: Long time to disconnect

Karl Ylvisaker — Thu, 06 May 2021 08:21:04 GMT

[quote user="nordev"]My sniffer is a Rigado BMD Development Kit with NRF52840 on it.[/quote]

Which sniffer firmware and software are you using?
As far as I know the nRF Sniffer is only compatible with the nRF52840 PCA10056 and PCA10059.
Are you able to successfully sniff any other pairing process? i.e if you flash your DK with an unmodified example from the SDK, and connect to it with your phone, are you able to sniff this connection just fine?

[quote user="nordev"]I am not sure how to make sure my peripheral is only advertising on 1Mbps or that my sniffer is compatible with 2Mbps. Do you have guidance on this?[/quote]

The nRF52840 is compatible with 2 Mbps PHY, so that is fine.
Are you able to see the PHY used for the advertising of each packet in Wireshark? I.e when you see an advertising packet, are you able to tell with PHY it is being advertised on?
The advertised PHY is what will be used when connecting.

[quote user="nordev"]I am sorry, what is LTK?[/quote]

Sorry, it is the long term encryption key. It is possible to provide this directly to the sniffer, if the sniffer is unable to sniff the bonding (such as when using LESC security). We should however first see if we can get the sniffer to work as expected, before moving to this approach.

Best regards,
Karl

RE: Long time to disconnect

nordev — Wed, 05 May 2021 16:06:45 GMT

Thanks, I hope you are well, too!

Yes, I am using a newer iOS device as the central. Although the same thing happened when using an older Android device as the central. My sniffer is a Rigado BMD Development Kit with NRF52840 on it. I am not sure how to make sure my peripheral is only advertising on 1Mbps or that my sniffer is compatible with 2Mbps. Do you have guidance on this?

[quote userid="87869" url="~/f/nordic-q-a/72834/long-time-to-disconnect/308335#308335"]we might look into providing the LTK key manually to the sniffer,[/quote]

I am sorry, what is LTK?

RE: Long time to disconnect

Karl Ylvisaker — Wed, 05 May 2021 11:48:01 GMT

Hello again nordev,

I hop you are well! :)

[quote user="nordev"]Thank you again so, so much for your thorough replies. I was called away on other work for a while and am finally back on this. [/quote]

No problem at all, I am happy to help!
We'll continue this whenever you have the chance, no worries.

[quote user="nordev"]I tried sniffing by letting the sniffer sniff the pairing process, as you suggested, but then I got no packets coming in on Wireshark[/quote]

Are you using a newer iOS device as the central here? What device are you using as your sniffer?
I know that never iOS devices switch to 2 Mbps PHY for the pairing if possible, so if you are using a nRF51 series device as your sniffer that might be why you are not seeing any packets for the pairing process. If it does not show up at all, this might be why.
Could you make sure that you peripheral is only advertising on the 1 Mbps PHY, or that your sniffer device is compatible with 2 Mbps PHY?

[quote user="nordev"]then after connecting, I see a lot of "61623 805.470 Slave_0xaf9a83e0 Encrypted packet decrypted incorrectly (bad MIC) LE 1M LE LL 12 150µs 1 0 True 9382" [/quote]

Yes, this is to be expected - if the sniffer does not have the encryption key, it will not be able to decode the contents of the message, it will only see that a message is being exchanged.

[quote user="nordev"]What is "Just Works"? Do you have other recommendations for sniffing the connection?[/quote]

Just Works is one of the available security procedures. If we are unable to sniff the pairing procedure we might look into providing the LTK key manually to the sniffer, but let us keep trying with the sniffer first.

Best regards,
Karl

RE: Long time to disconnect

nordev — Mon, 03 May 2021 20:07:08 GMT

Hi Karl,

Thank you again so, so much for your thorough replies. I was called away on other work for a while and am finally back on this.

[quote userid="87869" url="~/f/nordic-q-a/72834/long-time-to-disconnect/301408#301408"]The trick for sniffing non-LESC connections is that the sniffer needs to be listening when the connection and bond is being established, so that it may save a copy of the key used for the encryption.[/quote]

I tried sniffing by letting the sniffer sniff the pairing process, as you suggested, but then I got no packets coming in on Wireshark -- I am not sure, maybe this is a Wireshark bug? If I have already paired and I am just connecting, I see a lot of ADV_INV, and then after connecting, I see a lot of "61623 805.470 Slave_0xaf9a83e0 Encrypted packet decrypted incorrectly (bad MIC) LE 1M LE LL 12 150µs 1 0 True 9382"

I would expect if the sniffer has sniffed the encryption process, these Master / Slave packets would still be coming in, and they would have actual data. But I just get nothing. I get ADV_INV before connection, then after the connection, no packets, and when I disconnect, I get ADV_INV again. I am filtering to only look for data from a particular device.

I saw this resource as well -- What is "Just Works"? Do you have other recommendations for sniffing the connection?

RE: Long time to disconnect

Karl Ylvisaker — Tue, 23 Mar 2021 11:46:35 GMT

Hello again nordev,

Thank you for your patience with this.

[quote user="nordev"]I am sorry, I am not sure how to tell for sure whether this is the case, but I don't think so, because I have tried changing the parameters so they no longer match apple's requirements, as such:[/quote]

It would be implemented as part of your ble_evt_handler. If no case is implemented to disconnect on a rejected update request, or if an conn param update event is received, which does not match the peripheral's requirements. If none of these cases is implemented, your peripheral will accept whatever the central sets.

[quote user="nordev"]I have tried this, but I couldn't get the packets to be decrypted, even if I start watching the peripheral from the device dropdown menu prior to connection. Do you have other suggestions?[/quote]

With the security parameters you have set there should be no issue sniffing this connection. It is really only LESC security that makes sniffing the connection hard.
The trick for sniffing non-LESC connections is that the sniffer needs to be listening when the connection and bond is being established, so that it may save a copy of the key used for the encryption.
So, if your android already is bonded with the device it will use its stored key, and the sniffer will only then get the BAD MIC packets, because it is unable to decrypt them.

Please make sure to delete bonds on the peripheral and central side, and then restart the bonding process with the sniffer actively listening. Let me know if you still are unable to see the packets' content after doing this.

[quote user="nordev"]One last thing of note... I am not sure we have MITM and the passkey set up properly. Do you think this could contribute to the problem? I notice that on Android, the phone always requests a passkey to be entered before pairing. On iOS, using the same firmware, it never asks us for a passkey before pairing. This is the only other difference between iOS and Android, so maybe the problems are related?[/quote]

This would be a lot easier to debug and pinpoint with a trace. Lets pursue getting the trace up and running, and then return to this once we see what is happening in the exchange.

Best regards,
Karl

RE: Long time to disconnect

nordev — Thu, 18 Mar 2021 18:38:51 GMT

[quote userid="87869" url="~/f/nordic-q-a/72834/long-time-to-disconnect/300702#300702"]What connection parameters are you using for your connection? [/quote]

#define APP_BLE_OBSERVER_PRIO            3                                          /**< Application's BLE observer priority. You shouldn't need to modify this value. */ 1                                          /**< A tag for the SoftDevice BLE configuration. */ 244                                        /**< The advertising interval (in units of 0.625 ms. Value of 300 corresponds to 187.5 ms). */ 0                                          /**< The advertising timeout in units of seconds. */ MSEC_TO_UNITS(25, UNIT_1_25_MS)            /**< Minimum acceptable connection interval (0.1 seconds). */ MSEC_TO_UNITS(1500, UNIT_1_25_MS)          /**< Maximum acceptable connection interval (0.2 second). */ 0                                          /**< Slave latency. */ MSEC_TO_UNITS(5000, UNIT_10_MS)            /**< Connection supervisory timeout (4 seconds). */ APP_TIMER_TICKS(5000)                      /**< Time from initiating event (connect or start of notification) to first time sd_ble_gap_conn_param_update is called (5 seconds). */ APP_TIMER_TICKS(30000)                     /**< Time between each call to sd_ble_gap_conn_param_update after the first call (30 seconds). */ 2                                          /**< Number of attempts before giving up the connection parameter negotiation. */ 1                                          /**< Perform bonding. */ 0                                          /**< Man In The Middle protection required for Passkey */ 0                                          /**< LE Secure Connections not enabled. */ 0                                          /**< Keypress notifications not enabled. */ BLE_GAP_IO_CAPS_DISPLAY_ONLY               /**< Changed for Passkey */ 0                                          /**< Out Of Band data not available. */ 7                                          /**< Minimum encryption key size. */ 16                                         /**< Maximum encryption key size. */ APP_TIMER_TICKS(400)

[quote userid="87869" url="~/f/nordic-q-a/72834/long-time-to-disconnect/300702#300702"]And, is your peripheral device programmed to terminate the link if the connection parameters does not follow its preferences?[/quote]

I am sorry, I am not sure how to tell for sure whether this is the case, but I don't think so, because I have tried changing the parameters so they no longer match apple's requirements, as such:

[quote userid="85290" url="~/f/nordic-q-a/72834/long-time-to-disconnect/299915#299915"]but I followed all the parameters in section 36.6 here, and the issue persisted. [/quote]

and I was still able to connect.

To be clear, if I let the iOS phone stay connected to the peripheral for longer than 30s, it will always disconnect immediately. It just seems like there is a minimum 30s waiting period before any disconnect request is processed.

[quote userid="87869" url="~/f/nordic-q-a/72834/long-time-to-disconnect/300702#300702"]It would be great if you could produce a sniffer trace of a disconnect using an android, and another one when using an iOS device. [/quote]

I have tried this, but I couldn't get the packets to be decrypted, even if I start watching the peripheral from the device dropdown menu prior to connection. Do you have other suggestions?

As you may (or may not) be able to see from my original post in this thread, the only thing I noticed was that after pressing disconnect, I would get "Empty PDU" for however many seconds it took until I started getting advertising packets again (signifying successful disconnection). If it was a good disconnection, I would go from getting packets ("BAD MIC") to advertising almost immediately, without a lot of "Empty PDU" in between. When I set a breakpoint in the code, the call stack for a "good" disconnection and a long disconnection look the same, except that the long disconnection just takes up to 30 seconds before it is actually triggered.

[quote userid="85290" url="~/f/nordic-q-a/72834/long-time-to-disconnect/299908#299908"]I checked the call stack for when the disconnect is triggered and compared between my app and the Nordic example. It is the same exact thing in both cases (screenshot from bms app): [/quote]

One last thing of note... I am not sure we have MITM and the passkey set up properly. Do you think this could contribute to the problem? I notice that on Android, the phone always requests a passkey to be entered before pairing. On iOS, using the same firmware, it never asks us for a passkey before pairing. This is the only other difference between iOS and Android, so maybe the problems are related?

RE: Long time to disconnect

Karl Ylvisaker — Thu, 18 Mar 2021 14:07:44 GMT

[quote userid="85290" url="~/f/nordic-q-a/72834/long-time-to-disconnect/300208#300208"]thank you so much!!![/quote]

No problem at all, nordev!

[quote userid="85290" url="~/f/nordic-q-a/72834/long-time-to-disconnect/300208#300208"]I am calling the disconnect via the disconnect button inside the NRF Connect app for iOS (v2.4.8), or within our custom iOS app, not via the bsp. The long disconnect only happens on iOS. When I try using NRF Connect for android (v4.24.2), it always disconnects immediately, even when I try to disconnect immediately, like 1s after connecting. [/quote]

My apologies, I got this wrong when reading through the case history - I thought the problem was that the disconnect procedure did not start on the peripheral device.

[quote userid="85290" url="~/f/nordic-q-a/72834/long-time-to-disconnect/300208#300208"]My interrupt priorities are as follows:[/quote]

Thank you for providing these.

[quote userid="85290" url="~/f/nordic-q-a/72834/long-time-to-disconnect/300208#300208"]The disconnect on iOS happens, without fail, exactly 30s after the initial connection. EX: if I start the connection at t=0, no matter if I press "disconnect" on the phone at t=7, t=12, t=20, etc., the disconnect will always trigger on the BT device at exactly t=30s. I would think if it were an interrupt priority problem, this time period would vary. [/quote]

What connection parameters are you using for your connection? And, is your peripheral device programmed to terminate the link if the connection parameters does not follow its preferences?

It would be great if you could produce a sniffer trace of a disconnect using an android, and another one when using an iOS device. This way, we should be able to rule out a couple of possibilities right off the bat. The sniffer trace will tell us whether the problem lies with the iOS's link termination packet or not.
I think that currently, the case might be that the iOS device is demanding parameters that does not align with the configuration of the peripheral, and when these are not met, the peripheral triggers the disconnect after 30 s. However, I find it very strange that your attempt to trigger the disconnect is not working either.

Make sure to select your peripheral device from the device drop down menu (shown in the included image) in Wireshark before starting the first connection, so that the sniffer will follow into the connection and be able to decrypt the packets being sent between the central and peripheral.

You could do multiple connections and reconnections in the same trace, to highlight the issue.

Looking forward to resolving this issue together!

Best regards,
Karl

RE: Long time to disconnect

nordev — Tue, 16 Mar 2021 15:47:43 GMT

Hi Karl, thank you so much!!!

I am calling the disconnect via the disconnect button inside the NRF Connect app for iOS (v2.4.8), or within our custom iOS app, not via the bsp. The long disconnect only happens on iOS. When I try using NRF Connect for android (v4.24.2), it always disconnects immediately, even when I try to disconnect immediately, like 1s after connecting.

My interrupt priorities are as follows:

#define SPI_DEFAULT_CONFIG_IRQ_PRIORITY 6
#define UART_DEFAULT_CONFIG_IRQ_PRIORITY 3
#define APP_TIMER_CONFIG_IRQ_PRIORITY 7

The disconnect on iOS happens, without fail, exactly 30s after the initial connection. EX: if I start the connection at t=0, no matter if I press "disconnect" on the phone at t=7, t=12, t=20, etc., the disconnect will always trigger on the BT device at exactly t=30s. I would think if it were an interrupt priority problem, this time period would vary.

I know when the disconnect happens because inside ble_evt_handler, case BLE_GAP_EVT_DISCONNECTED: I put logs and I toggle an LED.

One last piece of possibly useful info:

[quote userid="85290" url="~/f/nordic-q-a/72834/long-time-to-disconnect/299922#299922"]

on very very rare occasions, I also see a random disconnect with reason 0x08, /**< Connection Timeout. */

Do you know what timeout this would be? I am just wondering if it is related because the fact that it takes a different amount of time each time to disconnect suggests that maybe we are waiting for some kind of timeout, and we just happen to start at a different place in the timeout each time.

[/quote]

(and by "different amount of time to connect," i mean different amount of time from when the disconnect button was pressed, which is consistent with the 30s finding above).

RE: Long time to disconnect

Karl Ylvisaker — Tue, 16 Mar 2021 14:52:59 GMT

Hello again nordev,

I will be taking over this ticket, as Joakim has been pulled away to other tasks for the time being.

From your initial ticket and answers I am thinking that it is your call to disconnect is not being handled properly. Looking at the screenshot from the traces you sent, it seems that the disconnection is working as intended when it is sent, but that the termination packet is not being sent during the 'long disconnect' intervals.
I therefore think we should look to the sd_ble_gap_disconnect calls that you have earlier mentioned does not get triggered when stepping through the code. I am confident that this is an error in the application layer / code.

I know from your other ticket that you have a lot of other tasks going immediately after a connection. I suspect that your call to disconnect takes a long time to trigger because of a priority mismatch.

If you are attempting to trigger the disconnect using a button press, what priority are you using for your bsp handler? And, what is the priority of your other interrupt based functions?

Looking forward to resolving this issue together!

Best regards,
Karl

RE: Long time to disconnect

nordev — Tue, 09 Mar 2021 00:29:18 GMT

Hi Joakim, are you still looking at this ticket? If not, should someone else be assigned to this ticket, perhaps?

Thank you!

RE: Long time to disconnect

nordev — Sat, 06 Mar 2021 01:57:15 GMT

I have another clue:

The "long disconnect" only happens when we try to disconnect within 30s of starting a new connection.

If the device has been connected for more than 30s, it will disconnect immediately when the disconnect is initiated.

If the device has been connected for less than 30s when the disconnect is initiated, it will disconnect 31 seconds after the initial connection, no matter whether the disconnect was initiated 10s, 15s, 20s, etc after the initial connection.

Again, the below is the only thing in my code that seems to use a 30s delay:

#define NEXT_CONN_PARAMS_UPDATE_DELAY    APP_TIMER_TICKS(30000)                     /**< Time between each call to sd_ble_gap_conn_param_update after the first call (30 seconds). */

But changing this parameter does not seem to affect the long disconnect.

So, why might this be happening?

RE: Long time to disconnect

nordev — Wed, 24 Feb 2021 15:01:00 GMT

I see... normally, when the long disconnect happens, it is with disconnect reason 0x13, which I think is normal: remote user terminated connection.

are you saying that disconnect reason 0x08 “connection timeout” is when the central stops responding? Not the peripheral?

i didn’t think this would matter, but I made some small changes to the SDK, I added the files suggested by Peter here: https://devzone.nordicsemi.com/f/nordic-q-a/29926/bug-in-peer-manager-in-sdk-14-2

also In ‘app_bds_util.h’, comment out:

typedef struct

{

uint16_t year;

uint8_t month;

uint8_t day;

uint8_t hours;

uint8_t minutes;

uint8_t seconds;

} ble_date_time_t;

Then #include ble_date_time.h in app_bds_util.h

Although, the NRF example code I ran disconnects perfectly with no issue, so I don’t think it’s the SDK...

Are you using SDK 14.2? Out of curiosity what were the build errors and how did you resolve them?

RE: Long time to disconnect

Joakim Jakobsen — Wed, 24 Feb 2021 10:23:30 GMT

Hi again.

I had some trouble building the example you sent. When I did, I didn't see any issue, so I'm still looking into this.

The connection timeout is the disconnect reason that I would expect you to see. In your code the supervision timeout is defined:
#define CONN_SUP_TIMEOUT MSEC_TO_UNITS(5000, UNIT_10_MS)

In your case, when the peripheral doesn't receive any response from the central anymore. It should disconnect (with the timeout reason) after the defined timeout.

Br,
Joakim

RE: Long time to disconnect

nordev — Tue, 23 Feb 2021 21:38:02 GMT

I don't know if this is maybe related, but in case it is a helpful clue, on very very rare occasions, I also see a random disconnect with reason 0x08, /**< Connection Timeout. */

Can you let me know if you were able to duplicate the issue? Thanks.

RE: Long time to disconnect

nordev — Thu, 18 Feb 2021 08:13:42 GMT

Thanks for the notice. Did you manage to find anything out yet? I have been thinking about it more... the softdevice should have the highest interrupt priority, so there must be something going on with the softdevice whenever i try to disconnect that prevents the disconnect from being processed for so long, right?

RE: Long time to disconnect

Joakim Jakobsen — Wed, 10 Feb 2021 10:12:52 GMT

Thanks.

I've downloaded the .zip now, so you can disable sharing if you feel safer.

I'll start looking at your project today.

Br,
Joakim

RE: Long time to disconnect

nordev — Tue, 09 Feb 2021 16:54:16 GMT

Thank you - I just uploaded my files to the chat message. If you just delete the files later, I can turn off the sharing link, so that we don't have to delete this ticket. It would be helpful to be able to refer to it later.

RE: Long time to disconnect

Joakim Jakobsen — Mon, 08 Feb 2021 20:29:10 GMT

I saw you message.

I turned this ticket private so that you can safely upload any sensitive information here.

Only you and Nordic employees will have access to the content of this ticket from now on.

Br,
Joakim

RE: Long time to disconnect

nordev — Thu, 04 Feb 2021 19:33:15 GMT

Yes, testing using NRF connect for mobile. App versions 2.4.7 and 2.3.2 on iOS, vsns 4.24.2 and 4.24.1 on Android.

I sent you a note in private message, do you see it?

RE: Long time to disconnect

Joakim Jakobsen — Thu, 04 Feb 2021 11:31:00 GMT

Thank you for that information. The fact that the problem only exists on iOS is very useful.

I will check my inbox for the project.

Are you testing this using our nRF Connect for mobile?

Br,
Joakim

RE: Long time to disconnect

nordev — Thu, 04 Feb 2021 07:53:50 GMT

I will send it to you via private message.

As a further update, I noticed that the long disconnect does not happen with Android devices, which all disconnect immediately. It only happens with iOS devices. I tried with multiple Android devices and multiple iOS devices.

This would seem to suggest that maybe it is a phone issue, but the iOS devices disconnect just fine when I use one of the Nordic example apps. So it is maybe something to do with how the iOS BLE stack interacts with the softdevice?

(I know Apple has particular requirements for the connection parameters, but I followed all the parameters in section 36.6 here, and the issue persisted. Values I used are below)

#define MIN_CONN_INTERVAL                MSEC_TO_UNITS(15, UNIT_1_25_MS)            /**< Minimum acceptable connection interval (0.1 seconds). */
#define MAX_CONN_INTERVAL                MSEC_TO_UNITS(500, UNIT_1_25_MS)          /**< Maximum acceptable connection interval (0.2 second). */
#define SLAVE_LATENCY                    0                                          /**< Slave latency. */
#define CONN_SUP_TIMEOUT                 MSEC_TO_UNITS(5000, UNIT_10_MS)

RE: Long time to disconnect

Joakim Jakobsen — Tue, 02 Feb 2021 20:41:05 GMT

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

RE: Long time to disconnect

nordev — Tue, 02 Feb 2021 16:18:34 GMT

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

[quote userid="20690" url="~/f/nordic-q-a/70359/long-time-to-disconnect/292492#292492"]What is the CONN_SUP_TIMEOUT defined as?[/quote]

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

[quote userid="85290" url="~/f/nordic-q-a/70359/long-time-to-disconnect/288781#288781"]here is some code: [/quote]

#define CONN_SUP_TIMEOUT MSEC_TO_UNITS(5000, UNIT_10_MS)

[quote userid="20690" url="~/f/nordic-q-a/70359/long-time-to-disconnect/292492#292492"]Are you seeing this behaviour using the stock ble_app_bms example and nRF Connect?[/quote]

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

[quote userid="85290" url="~/f/nordic-q-a/70359/long-time-to-disconnect/291904#291904"]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[/quote]