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!

[Sigurd]

Hi!

CrazyDave said:

The pictures look as follows:

Could you upload the Wireshark logs as well?

[CrazyDave]

Hi Sigurd! Thank you very much for your answer! One of my colleagues will follow as soon as possible (hopefully later today, if not tomorrow morning) with the logs, from the moment the devices get connected to the data streaming step. Thanks again for your help!

[BigJoe]

Hi Sigurd! Thank you very much for your reply! Allow me to insert the two log files from Wireshark. Best way to see the files is throught the Wireshark software itself.

The log_nrf_3_GOOD shows the communication log with the NRF CONNECT AND THE USB DONGLE. The connection starts in line 974.

log_nrf_3_GOOD.pcapng

The log_pyt_3_ISSUE shows the communication log with the built-in bluetooth with a python script. The connection starts in line 4127. 

log_pyt_3_ISSUE.pcapng

Hope that this will be of any help. 

Thank you again!

[Sigurd]

Hi,

Nordic UART peripheral example

This from nRF5 SDK? The ble_app_uart example? If yes, try increasing  NRF_SDH_BLE_GAP_EVENT_LENGTH in sdk_config.h to a higher value. Try setting it to 100. The BLE connection interval is much higher in the log_pyt_3_ISSUE.pcapng , so for max throughput you want to increase NRF_SDH_BLE_GAP_EVENT_LENGTH so that it at least matches the connection interval you see here.

[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!