• State Suggested Answer
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 75 subscribers
  • Views 1881 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

    This can be a scheduling issue on the link controller of the PC running Windows 10, so for completeness please report the Bluetooth IC that is used on the Windows 10 PC and the Windows 10 build number. Yes, just connecting at the link will change the bandwidth allocation on the PC Bluetooth. The additional info that this works 1/100 times points towards a scheduler issue possibility.

    You can do a few experiments to get some more insight 

    1. Run this on a PC with a different Bluetooth IC. Verify that you have the latest driver for the Bluetooth IC that you are using so any patches can be applied.

    2. Track the BLE_GATTS_EVT_HVN_TX_COMPLETE messages for the notifications and see if they are getting delayed. You should get a BLE_GATTS_EVT_HVN_TX_COMPLETE event with a count so you get an idea of the number of notifications being done. you can log this with a timer timestamp so you get an idea of the speed of the notifications. You can also adjust the Handle Value Notification queue size using that ble_gatts_conn_cfg_t::hvn_tx_queue_size make sure you have set it to a number that fits your application.

    3. If you use the nRF Sniffer you will need to use 2 sniffers to sniff the 2 peripherals and you should see the actual connection interval and the data being sent.

    4. Change the connection intervals that you are requesting to 30ms - 50ms or something more relaxed to see if the peripherals can co-exist.

    5. Check if you are getting a SD_BLE_GAP_CONN_PARAM_UPDATE that changes the connection interval and may explain the delayed notifications.

Reply
  • 0

    This can be a scheduling issue on the link controller of the PC running Windows 10, so for completeness please report the Bluetooth IC that is used on the Windows 10 PC and the Windows 10 build number. Yes, just connecting at the link will change the bandwidth allocation on the PC Bluetooth. The additional info that this works 1/100 times points towards a scheduler issue possibility.

    You can do a few experiments to get some more insight 

    1. Run this on a PC with a different Bluetooth IC. Verify that you have the latest driver for the Bluetooth IC that you are using so any patches can be applied.

    2. Track the BLE_GATTS_EVT_HVN_TX_COMPLETE messages for the notifications and see if they are getting delayed. You should get a BLE_GATTS_EVT_HVN_TX_COMPLETE event with a count so you get an idea of the number of notifications being done. you can log this with a timer timestamp so you get an idea of the speed of the notifications. You can also adjust the Handle Value Notification queue size using that ble_gatts_conn_cfg_t::hvn_tx_queue_size make sure you have set it to a number that fits your application.

    3. If you use the nRF Sniffer you will need to use 2 sniffers to sniff the 2 peripherals and you should see the actual connection interval and the data being sent.

    4. Change the connection intervals that you are requesting to 30ms - 50ms or something more relaxed to see if the peripherals can co-exist.

    5. Check if you are getting a SD_BLE_GAP_CONN_PARAM_UPDATE that changes the connection interval and may explain the delayed notifications.

Children
No Data
Related
Terms of service