nRF Connect SDK NUS throughput modifications and issues for peripheral_uart/central_uart example applications

There are many questions on DevZone on modifications to NCS peripheral_uart/central_uart NUS example applications to support higher throughput.

We have been mostly successful in modifying both applications so that BLE throughput can operate at 1380-1400 kbps.

After peripheral_uart/central_uart establish a connection, the central_uart will setup link parameters to improve BLE throughput:

  • negotiate to use 2M PHY
  • negotiate to use DLE (data length extension) set to 251 bytes
  • negotiate to use connection interval of 400ms

The UART has been modified to run at maximum speed of 1000kbps.

This work was done on NCS 1.8.0, but also demonstrated on NCS 1.6.1 and 1.7.1

It has been tested on nRF5340-DK and nRF52832-DK boards.

In the attached file nus_throughput_test_repo.zip there is a Git repo which shows all the code/project modifications, starting from the original NCS peripheral_uart/central_uart example applications. Fairly straightforward to see all the modifications.

If you build them, they will operate in a BLE throughput test mode, ignoring any UART communications.

After connecting and exchanging link negotiations, the peripheral_uart will send a 240 byte message as fast as possible, and central_uart will put out periodic RTT logs indicating the BLE received data rate of approximately 1380-1400 kbps

The throughput is perfect ( assuming your are in a clean RF environment )

One problem we have though is the following:

  • in present central_uart application (main.c), we have defined #define BLE_NUS_DISABLE_BT_CONN_SECURITY for our own purposes
  • this #define BLE_NUS_DISABLE_BT_CONN_SECURITY will make sure central_uart does not establish link security
    • via bt_conn_set_security(conn, BT_SECURITY_L2)

But if one sets #undef BLE_NUS_DISABLE_BT_CONN_SECURITY, the link security will be successfully established. Both endpoints will operate at 1380-1400 kbps throughput but with one important caveat / odd behavior.

  • What we observed is that every 28-29 seconds, the link communications will stumble
  • At this time, the throughput will drop drastically for upwards of 1200 ms ... a long time !
  • Then it will recover to perfect throughput, and this process will repeat every 28-29 seconds.

It appears there is something in the security/encryption mechanism that is responsible for this periodic throughput impairment.

Any ideas in the DevZone world on this issue ?

Issue appears to exist in NCS 1.6.x through to NCS 1.8.x

Thanks for your help !

nus_throughput_test_repo.zip

Parents
  • Hi

    Indeed, I also tried changing the SMP_TIMEOUT on my end, and this indeed doesn't seem to be the culprit. I've also finally been able to get a sniffer trace of the application. The RTT log somehow buggered up the nRF Sniffer, so I had to get a hold of our Ellisys Vanguard sniffer to get a good look at what's going on. I'm still reviewing the trace, as it's not clear cut what the issue is yet, but I wanted to give you an update. I'm not sure if you'll be able to open this trace without the Ellisys Bluetooth Analyzer software, but here you go nonetheless:

    30 sec fails.btt

    Best regards,

    Simon

Reply
  • Hi

    Indeed, I also tried changing the SMP_TIMEOUT on my end, and this indeed doesn't seem to be the culprit. I've also finally been able to get a sniffer trace of the application. The RTT log somehow buggered up the nRF Sniffer, so I had to get a hold of our Ellisys Vanguard sniffer to get a good look at what's going on. I'm still reviewing the trace, as it's not clear cut what the issue is yet, but I wanted to give you an update. I'm not sure if you'll be able to open this trace without the Ellisys Bluetooth Analyzer software, but here you go nonetheless:

    30 sec fails.btt

    Best regards,

    Simon

Children
  • OK, thanks for the update @Simonr 

    No, I am not able to obtain the Ellisys analyzer software.

    Hopefully we are getting closer ... :}

    I was trying to look further into the Bluetooth transmit task, but could not decipher the code details to understand where it may be blocking for such a long time.

    Are you familiar with Zephyr RTOS and Bluetooth stack enough to trace where the blocking may be occurring ?

    Likely it is blocking on a semaphore somewhere ...

    Note I had swapped out the Nordic Bluetooth stack with the Zephyr Bluetooth stack, but the issue remained.

Related