hci ble timeout disconnections seems to happen regularly every 1 hour and 21 minutes, using Microsoft Ble Virtual Sniffer to monitor disconnections

[astella]

To the kind Nordic support team,

I have got a nRF52833 based Raytac module I'm using to develop before using a custom board.

I'm using Microsoft Bluetooth Virtual Sniffer (https://techcommunity.microsoft.com/t5/microsoft-bluetooth-blog/introducing-bluetooth-virtual-sniffer-btvs-exe/ba-p/2113478)

so to monitor ble disconnections. I left this test system on from 19:00 in the evening to about 9:00 in the morning. I'd like to repeat this thing more and I'll be updating this post.

What I found is that I'm not apparently experiencing random disconnections, but they seem to follow a very regular pattern.

What could it mean theoretically, in your opinion? You think I could act on connection parameters whatsoever to improve this (never get disconnections)? At this point I'm not sure if these disconnections are due to RC internal source (there is no external 32.768 kHz clock) or to some problem inside the firmware.

My application is always sleeping, but ble event can wake up the app, just to serve ble events. So there is always a background active communication and my prototype is always listed in Windows as Connected and never as Paired. After this Disconnections, the advertising is immediately triggered and the re-connection is done in about a second. Let me please know if need any other detail so to discuss at least theoretically this thing.

Best regards

-----------------------------------------------------------------

19:57  (Rcvd Disconnection)
21:18  (Rcvd Disconnection) ---> 1h21
22:40  (Rcvd Disconnection) ---> 1h22
00:01  (Rcvd Disconnection) ---> 1h21
01:22  (Rcvd Disconnection) ---> 1h21
02:44  (Rcvd Disconnection) ---> 1h22
04:05  (Rcvd Disconnection) ---> 1h21
05:26  (Rcvd Disconnection) ---> 1h21
06:47  (Rcvd Disconnection) ---> 1h21
08:08  (Rcvd Disconnection) ---> 1h21

-----------------------------------------------------------------

[astella]

It seems like there is an expiring time of "1h21" since latest usage (on this test system). If I'm using the device sending actual data, it stays connected more. Could be like a second level timeout host side? I mean, maybe the host is waiting for actual data packets, other than service empty packets. But I could not find anything useful in Bluetooth Core Specifications at the moment regarding this. I'm curious to test in other systems, other operating system/chipsets, to understand if the problem is host/device side. 

17:07 (Rcvd Disconnect) ---

.... sending actual data sometime
.... no disconnections until 19:15
last time I sent actual data at: 19:15

20:36 (Rcvd Disconnect) --- 3h29 from latest disconnection, 1h21 from latest usage
21:58 (Rcvd Disconnect) --- 1h22
23:19 (Rcvd Disconnect) --- 1h21
00:41 (Rcvd Disconnect) --- 1h22
02:03 (Rcvd Disconnect) --- 1h22
03:24 (Rcvd Disconnect) --- 1h21
04:45 (Rcvd Disconnect) --- 1h21
06:07 (Rcvd Disconnect) --- 1h22
07:29 (Rcvd Disconnect) --- 1h22
08:50 (Rcvd Disconnect) --- 1h21

[ovrebekk]

Hi Stella

This could very well be some kind of activity timeout on the host side, in order to save resources by disconnecting devices that are (apparently) not being used. 

This is not something the Bluetooth specification requires, so it would have to be something that Microsoft came up with. 

You might be able to find out a bit more if you do some logging or debugging when the disconnect happens, and print out the disconnect reason. 

Alternatively, a Bluetooth sniffer trace could also shed some light on the situation, by showing whether or not this is an intentional disconnect by the host (seems likely under the circumstances). 

Best regards
Torbjørn

[astella]

Hi ovrebekk, thank for replying. This is what is reported by Bluetooth Virtual Sniffer, the infamous 0x08. Do you think, based on your experience, that it shows the controller intentionally dropped the connection? This error code is matching what is reported Nordic chip side.

[ovrebekk]

Hi Stella

It would be odd to get disconnect reason 0x08 if the host drops the connection on purpose. When either side drops the link on purpose it should disconnect the link explicitly, and would usually provide disconnect reason 0x13 or 0x16. 

Disconnect reason 0x08 occurs if one of the peers simply stop sending or responding to any Bluetooth packets. 

As an example, if the central (Windows machine) stops polling the peripheral the peripheral will disconnect with reason 0x08 after the connection supervising timeout period expires. 

Best regards
Torbjørn