• State Suggested Answer
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 75 subscribers
  • Views 1879 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 262581
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Windows 10 throughput / connection window clashes

dingari

I'm facing a problem with a product I'm developing. The problematic setup is as follows:

  • Two nRF52832 peripherals (S132 v6.0.0), each notifying on two characteristics in two separate services (~100 Hz).
  • A Windows 10 central using native C++ SDK bindings to discover and connect to the peripherals.
  • The connection interval is configured to min 7ms and max 15ms on the peripheral. I can monitor that the negotiated interval is 15ms.
  • GATT MTU: 64 bytes
  • GAP data length: 27 bytes (just tried updating to 64 to match the MTU but that didn't change anything).

The problem is that I can connect one peripheral and receive notifications at the correct rate. As soon as I connect another peripheral, the first one starts failing to send notifications (sd_ble_gatts_hvx returns with NRF_ERROR_RESOURCES due to too many notifications queued). This happens even when the other peripheral is not sending anything, just connected to the central. The newly connected peripheral has no problem with sending notifications at a correct rate.

We don't observe this problem on other platforms (tested on macOS and Android), so I don't think it's an OTA throughput issue. Could it have something to do with how the Windows central spaces out the connection intervals/windows? Can the newly connected peripheral just be "stealing" the windows from the other peripheral? Is there something we can do on the peripheral side to prevent this from happening?

And just to make it extra special, on some rare occasions it just seems to work fine. Maybe once in every 100 connection attempts or so.

Open to any and all ideas...

Parents
  • 0

    @daviddedwin Thanks for the reply. The machine I'm testing on is running the latest Windows build (10.0.19041) and according to the Device Manager the Bluetooth adapter driver is "up to date", whatever that means.

    This is a CSR USB dongle (USB\VID_0A12&PID_0001&REV_8891), but I experience this issue on my laptop as well. I'm running macOS Catalina on the same hardware and don't experience this issue.

    I'd really like to keep it at the lowest possible value. I can see that the only connection parameter update received from the Windows central on the nRF52832 sets it to 15ms.

    Also, disabling WiFi is not a solution (while I understand trying to limit the variables in this equation). We are nowhere near any thresholds for BLE bandwidth/throughput, and this setup works fine on another OS on the same hardware.

    I'd love to hear any input you might have on this subject. If there's anything we can do to improve the performance since it's very sub optimal as-is.

  • 0 in reply to dingari

    Looking at the driver tab that you have posted, the generic Microsoft Bluetooth driver is controlling the dongle on Windows 10. The CSR hardware uses a RAM based patch system to get updated code to the hardware, this patch is usually distributed through the vendor's driver. It would be good to use the vendor's latest driver instead of the generic microsoft driver.

    Since the patch is distributed with the driver, it is possible that the mac OS has a later version of the driver and associated patches and hence performs better.

    I would still encourage you to switch off WiFi and do a test (agreed, it is not a solution), so if the performance of the system improves from its current 1 in 100 attempts to have 2 peripherals, then we are certainly looking at a scheduler issue

    Additionally and I think fairly important, you should test this on a inbuilt  Win 10 Bluetooth hardware, as the dongle does not have the WiFi co-existance and will have worse performance as the WiFi will keep hitting on the Bluetooth packets. The dongle is something that a typical Win 10 user will not be using.

    Summary of my hypotheses :
    * Performance differences between macOS and Win 10, likely due the use of the generic windows driver which may not be at the right patch level.
    * Test with WiFi off to see if performance improves pointing to a scheduler issue
    * Dongle is not a typical use case for Win 10 so test with built-in Bluetooth and a vendor supplied driver

Reply
  • 0 in reply to dingari

    Looking at the driver tab that you have posted, the generic Microsoft Bluetooth driver is controlling the dongle on Windows 10. The CSR hardware uses a RAM based patch system to get updated code to the hardware, this patch is usually distributed through the vendor's driver. It would be good to use the vendor's latest driver instead of the generic microsoft driver.

    Since the patch is distributed with the driver, it is possible that the mac OS has a later version of the driver and associated patches and hence performs better.

    I would still encourage you to switch off WiFi and do a test (agreed, it is not a solution), so if the performance of the system improves from its current 1 in 100 attempts to have 2 peripherals, then we are certainly looking at a scheduler issue

    Additionally and I think fairly important, you should test this on a inbuilt  Win 10 Bluetooth hardware, as the dongle does not have the WiFi co-existance and will have worse performance as the WiFi will keep hitting on the Bluetooth packets. The dongle is something that a typical Win 10 user will not be using.

    Summary of my hypotheses :
    * Performance differences between macOS and Win 10, likely due the use of the generic windows driver which may not be at the right patch level.
    * Test with WiFi off to see if performance improves pointing to a scheduler issue
    * Dongle is not a typical use case for Win 10 so test with built-in Bluetooth and a vendor supplied driver

Children
  • 0 in reply to daviddedwin

    Duly noted!

    One other thing I'm wondering if it might have some say in this matter is the GAP data length parameter. When connecting to my peripheral on macOS, the rx/tx octets are updated according to what I set `NRF_SDH_BLE_GAP_DATA_LENGTH` to (64). But when connecting to the Windows side, it just stays at 27. Could this have some significance?

  • 0 in reply to dingari

    Absolutely, I would take this as supporting the hypothesis that the firmware patches are different for the mac OS vs the windows PC.
    As a final test  you can setup a sniffer and capture the traces from the Windows and the mac OS. Look for the VERSION_IND packet from the CSR, this will also have an identifier for the firmware levels. The caveat is that the CSR firmware may not send the VERSION_IND but its worth a try as well. However do look at the hypotheses i have stated earlier as well.

    Please give my answer an upvote if this has been helpful.

Related
Terms of service