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

[mtsunstrum]

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

[Simonr]

Hi

I think the best way to get to the bottom of this would be to do a sniffer trace of the on-air traffic. Do you have a dedicated sniffer or an extra nRF52 DK/Dongle you can use with the nRF Sniffer and Wireshark to do so? That way we should get an idea of what happens every 28-29 seconds. My initial guess would be that the encryption used requires an update between the two devices every X seconds.

Best regards,

Simon

[mtsunstrum]

Thanks Simonr  I do not have a 3rd nRF device, and of course my 2 nRF devices are needed to make a connection between themselves.

To explore your theory, is there a specific LOG  module I could enable ? That would help to confirm if the 29 second issue is coincident with the potential encryption update.

[Simonr]

No, I'm afraid you will need a sniffer device to capture traffic over the air.

I tried to reproduce this on my end with the project you attached, but I did not see any messages of lost packets every ~30 seconds as you describe. Is there something else I will need to change in order to reproduce this issue on my end. For reference I used an nRF52833 and nRF52832 DK for testing (it's what I got at my home office). 

Additionally, in order to sniff the devices, I need to know the passkey for the encrypted connection, as the sniffer won't be able to "join" the connection without it. It would be possible to set the passkey to a static value to make this easier, or to print it to UART/RTT during pairing.

Best regards,

Simon

[mtsunstrum]

Hi @Simonr thanks for your reply.

When you do the build, you will not see the RTT logs showing any errors in peripheral_uart. You will get perfect throughput.

To see the problem, you need to #undef BLE_NUS_DISABLE_BT_CONN_SECURITY in main.c in the central_uart application.  ( See original posting notes )

If you can rebuild central_uart with that modification, please confirm if you see the issue.

I have tested with a nRF52832-DK and a nRF5340-DK device. Another colleague in another location has tested with two nRF5340-DK devices.

---

I'll see if I can dig up a 3rd DK. But that may take a week or so.

In the meantime, can you answer a couple of questions:

• with respect to the issue being possibly related to an encryption update, do you have any information on that process ?
  • Is it known to update every 29 seconds ?
  • Is it configurable ?
  • If so, where / how can that interval be modified ?
  • Is there a LOG that can be enabled to see this operation ? ... before trying sniffer setup

• I will look into setting the passkey to a static value
  • devzone.nordicsemi.com/.../284187
  • I presume above procedure is accurate

[Simonr]

Hi again

Seeing as it is so consistent (every ~28.8 seconds or so, 30 seconds with the 1200ms delay) it's most likely a connection parameter timeout somewhere, but I'm not able to find one matching this in the project you provided. I can't think of what it could be that trigs every 30 second, but there must be something.

You can also try adding some more logging to see if you're able to get some information other than the UART printing. Try logging the BT_CONN_SECURITY process, and perhaps add a way to see an error code from the UART peripheral so we can get more info of what exactly is causing this error.

I will test on my work computer on Monday (I'm restricted to home office due to CoVID atm), as I'm struggling to follow the connection while sniffing for the device for some reason. Hopefully I won't have this issue at my work computer.

I also see that you use the JUST WORKS security, so setting a passkey should not be necessary.

Best regards,

Simon