Notifications stops when using internal bluetooth

[PauDC]

Hello,

I've asked this question already at StackOverflow, and while I try Wireshark I wanted to see if someone has experienced the same issue and/or can provide further information. Thestack overflow link is the following: Link. The explanation of the issue will be pretty much the same.

I'm developing an UWP app meant for Windows10 that prints connects to the sensor and prints some of the data it sends. It doesn't do anything else.

I have a BLE sensor based on the Nordic nRF52832 SoC that sends data at a frequency of 100Hz and I've developed an UWP application to receive this data. I'm having a weird issue where after a couple of seconds of everything working fine, I stop recieving notifications for new data and the sensor disconnects.

Now, I say it's weird because this happens when I'm using the laptop's internal bluetooth but not when using a bluetooth dongle. When using the dongle it works fine and never stops. Both internal bluetooth and dongle drivers are updated to the latest version Windows can find.

A bit of information about my code:

• I have a Sensor.cs class in which I handle the connection and the streaming of the data.
• I'm using BluetoothLEAdvertisementWatcher in order to find the sensor.
• The GattCharacteristic's are private members of the Sensor class.
• I subscribe to notifications by calling:

  await _gattDataSensorsCharacteristic.WriteClientCharacteristicConfigurationDescriptorAsync(
     GattClientCharacteristicConfigurationDescriptorValue.Notify);

  
  
  
  
• The characteristic I'm calling admits read/notify. And the issue is that characteristic.ValueChanged += Characteristic_ValueChanged; stops firing.

I've done quite a research and couldn't find anything similar. I've found posts about notifications stopping because the object was taken away by the GC, the characteristics were local variables instead of class members or calls weren't awaited.

Things I've tried:

The laptop is running the max performance power consumption profile, this issue happens when the laptop is plugged to a power source or not.

In Windows Device Manager under Bluetooth device properties. Right clicked and checked the propeties of the BT, in the  Power Management tab "Allow the computer to turn off this device to save power" is unchecked.

As posted in StackOverflow, the link to the code I'm using is here: GitHub

Does anybody know why does this happen? Or point me to the right direction to solve the issue? Having to carry the dongle is a pain in the ass and they are rather fragile, I've already broken 2 this month.

Thanks.

1st edit

I've scanned the traffic usig USPCap and loading the data to WireShark. Tried to understand what the pcap file generated by USBPcap, but I simply don't understand. I've tried the issue with 2 sensors and the disconnect/notification stop pattern looks different for each sensor. I've made a Dropbox folder containing the two pcap files: Dropbox

From what I understood, in the file "ble-FE592382586F.pcap" the interesting line No are: 12647 and 12681. It says the source is the controller and the destination is host. Is the controller the laptop's bluetooth driver?

[PauDC]

Hi Hung,
I've updated the dropbox with a second and third capture. I think it's worth mentioning that the sensor isn't disconnecting, but I stop receiving notifications. In the 3rd log I saw as I was measuring that the notifications stopped coming at around line 1350. But decided to leave it capturing a bit more because of this Slave - Master things it sniffed.

[Hung Bui]

Hi Pau, 

It seems the PC was NACKing the packets from the nRF52. What I can see in the trace is that that the peripheral (I assume nRF52) was sending notification every 50ms. And it's about 187 bytes for each notification, split into 8 packets. This is normal. However, at #1238, a fragmented packet started and never ended. The same payload was transmitted again and again and the Sequence Number remained. This indicate that the central received the packets but NACKed them. Usually this behaviour happens when the peer's buffer is full and it wouldn't want to receive any new data. (You can read about the Sequence Number (SN) and NESN here: https://devzone.nordicsemi.com/nordic/short-range-guides/b/bluetooth-low-energy/posts/bluetooth-smart-and-the-nordics-softdevices-part-2) 

I'm not sure how it work on the PC side, but if this happens on the Softdevice side, it usually due to the application failed to pull the events out from the Softdevice's buffer. Do you have any activity in your PC application that can cause a long latency ? 
If you test using Microsoft demo example, would you see the same problem ? 

[PauDC]

Thanks for the reply.

The answer to your questions:

Hung Bui said:

Do you have any activity in your PC application that can cause a long latency ? 

No, the laptops I'm running the software in only have chrome and this program installed, nothing running in background. The laptop is running plugged in and max performance mode.

Hung Bui said:

If you test using Microsoft demo example, would you see the same problem ? 

Just double checked this, and yes. It stops receiving notifications too after a few seconds.

[Hung Bui]

Could you give some more information about the internal Bluetooth chip ? Manufacturer and the driver version etc ? 

[PauDC]

Hi Hung,

I've a HP g430 g3, a lenovo 81HN, a lenovo miix 320-10ICR all with the same bluetooth hardware ID is: vid_8087&pid_0a2a&rev_0001, from Aida64 I read that it's an Intel Dual Band Wireless-AC 3165. And the driver version in order are: 20.100.6.4, 20.100.6.2 and 20.100.6.2. All these versions are the latest recommended versions by Windows. I've tried to update the driver on the HP using Intel's tool to version 21, but in Windows device manager's the same old version is showing.

Meanwhile I found that a colleague with a Fujitsu lifebook e558, hardware id: VID_8087&PID_0A2B&REV_0010 and driver version: 20.0.0.11, and the hardware is Intel Dual Band Wireless-AC 8265 works flawlessly.