Native Windows 10 Ble throughput

[Zoran]

Hi all,

We are using the nRF52832 as a peripheral to stream IMU data to a windows 10 PC (central). We need to develop our own software through the native windows ble (UWP) to support a high throughput (at least 500kbps). When completing some initial testing, both with UWP and the microsoft Bluetooth LE Explorer, we find that even when trying to stream at 100Hz (with 100byte packets) we only achieve around 85Hz data rate. The same testing with a nRF52 central works perfectly.

Is there an inherent bottleneck in the Windows 10 implementation of Bluetooth support that you can clarify for us? Should we shift our design to a gateway device or something like the bluetooth dongle Nordic provides to achieve the data rate? We are just trying to keep things simple from the number of devices being used.

Cheers

[Edvin]

I agree with . Probably, the reason that you get a higher throughput on the nRF is that the nRF only has one task, to maintain the link with the peripheral that you are developing, while the bluetooth chip that is located in your computer probably needs to keep scanning for other devices, perhaps advertise and maintain one or more connections, if you have a BLE mouse/keyboard connected to it. Even if you don't, it may want to reserve time for this. This is why we often see that phones doesn't provide the optimal connection parameters, as you can get if you control the central completely, using a DK as the central.

A sniffer trace will probably give the answer, yes. You can compare the sniffer trace when you connect to a DK to the sniffer trace from when you connect to the computer. Perhaps it gives a shorter MTU, a shorte connection event length or a longer connection interval, which will all decrease the throughput.

However, there are ways to at least know about what messages are sent and not from your peripheral application, and perhaps you are not getting the most out of the link if you are not aware of it.

If you call sd_ble_gatts_hvx() and this returns NRF_SUCCESS, then this packet will be delivered to the central (because of retransmissions in the BLE specification). So you should always check the return value of sd_ble_gatts_hvx() (possibly called via some other ..._send() function, depending on how you set up your application). 

Does your application check the return value? 

If you are sending a lot of small packets, you can try to combine the payload from several packets, so your packet length is closer to the MTU. This will reduce the overhead/payload ratio, giving you more payload/time.

If one of your calls to sd_ble_gatts_hvx() returns NRF_ERROR_RESOURCES, it means that your sending queue is full. You may try to wait for some of the packets to be acked (...TX_COMPLETE event) and try queuing it again. This may work particularly if your data is coming in large bulks. But if you have a steady stream of data higher than the BLE throughput, this will only postpone the issue.

Lastly, it may be that the central was the one who negotiated a higher MTU (the sniffer trace will tell). Make sure you set the desired MTU in your peripheral. And equally, you may try to update the link to 2MBPS in the peripheral application. It will give a higher throughput in the link. I don't know if you used this when the central was the DK, or if 2MBPS is supported at all in the bluetooth chipset on your computer, but it is worth a shot.

Best regards,

Edvin

[Dmitry]

If your solution will be used on a number of different PC, probably you'll need a gateway to get predictable results with different BT controllers. Our tests show about 9 kbytes/sec transfer rate from Win10 with Intel BT controller to nRF52840 (1Mbps PHY, 180-byte packets, both using HID-over-GATT and Web Bluetooth API - results are close).

[Zoran]

Thank you all for the great feedback. Much appreciated.

[hector_leon]

Hi Zoran  How did you manage to develop your own software through the native windows ble (UWP)? I'm trying to do the same with C# but I don't even know how to start. Thanks in advance.