Slow BLE connection with computer if using built-in and 3rd-party USB dongles. BUT nRF52840 dongle with nRF Connect for desktop works perfectly.

[CrazyDave]

Hello everyone!

Long story short, we are developing a BLE application based on the Nordic UART peripheral example. The board (STM32 micro + BL652 BLE module w nrf52832 inside) receives different commands from a central (PC running nRF Connect for desktop in this case) and sends back either a discrete response or streams data until another command is received to stop the streaming. All these responses are received via notifications.

The problem is that when connected to the device via either the built-in Bluetooth transceiver of the latptop, or a 3rd-party UBS dongle and some Python or Matlab script (as PC app), the connection performs much worse than when connected to our device via nRF52840 USB dongle and nRF Connect for desktop.

We logged the traffic in Wireshark for this data streaming when triggered from both nRF Connect and Python. The pictures look as follows:

NRF CONNECT and nRF52840 USB dongle:

3rd-party (or built in laptop BLE) with Matlab or custom Python script:

As you can see, in the second picture, there seem to be extra transactions taking place involving the link layer. The time between the two events marked with a red vertical line is ~50ms!!! This ruins our data rate and severely cripples the performance of the device.

Unfortunately we do not know who is at fault here and how to properly interpret what we see in the picture. Is the master requesting something and the slave device does not answer in a timely manner? Or, is the slave maybe failing to send another notification and the master sends some confirmation again?

The proper understanding of the events taking place at this link layer is currently baffling us.

Any help is much appreciated.

Thank you very much!

[CrazyDave]

Hi Sigurd!
First of all thank you very much for your reply and help!
We tried your solution and unfortunately the module does not start at all if we modify that define to 100. I'm not sure if the advertising does not start or if an internal crash occurs altogether ((have not yet debugged the issue).

Now, would you have some other hints regarding a possible solution? Some other settings we might try?
I know this topic was discussed in other threads which we have read through and got the first suggestions from, on how to improve the throughput.
The only thing which actually made a difference was reducing the MIN_CONN_INTERVAL to 7.5ms. This alone worked to substantially improve the bitrate of our connection.
Reducing the MTU to 96 bytes (our largest packet), in previous optimization attempts, led to all 3rd party devices no longer being able to pair and bond to our board at all. nRF Connect worked fine though.
And yes, this is based on the standard SDK example for the UART peripheral, since you asked previously.
We now have:
#define MIN_CONN_INTERVAL               MSEC_TO_UNITS(7.5, UNIT_1_25_MS)            /**< Minimum acceptable connection interval (7.5ms instead of the default 20ms, for much improved data rates), Connection interval uses 1.25 ms units. */
#define MAX_CONN_INTERVAL               MSEC_TO_UNITS(75, UNIT_1_25_MS)             /**< Maximum acceptable connection interval (75 ms), Connection interval uses 1.25 ms units. */

And I have also attached the sdk_config.h file which might be of help to you.
Any other suggestions on how to change or improve the throughput in our application is welcomed.

Thank you very much!

[Sigurd]

CrazyDave said:

We tried your solution and unfortunately the module does not start at all if we modify that define to 100. I'm not sure if the advertising does not start or if an internal crash occurs altogether ((have not yet debugged the issue).

You likely need to allocate more RAM to the SoftDevice after this change. 
This guide covers it, but the numbers might be a little different since it's a older SDK version used in that guide: https://devzone.nordicsemi.com/guides/short-range-guides/b/getting-started/posts/adjustment-of-ram-and-flash-memory

[CrazyDave]

Hi Sigurd! Your solutions worked! Therefore thank you very much for all your help, it is highly appreciated!

Since we might need further improvement of the bitrate in the (near?) future, could you recommend us extra tuning which we could do to obtain even better throughput? Or, is there any good guide discussing this topic you could point point me to?

Thank you very much again!

[Sigurd]

CrazyDave said:

Hi Sigurd! Your solutions worked! Therefore thank you very much for all your help, it is highly appreciated!

Nice, great to hear that!

CrazyDave said:

Since we might need further improvement of the bitrate in the (near?) future, could you recommend us extra tuning which we could do to obtain even better throughput? Or, is there any good guide discussing this topic you could point point me to?

If both side of the link support 2M PHY, then enabling that might be an easy way to get some more bitrate. This 3rd party blog post here might helpful: https://www.novelbits.io/bluetooth-5-speed-maximum-throughput/