Sending multiple notify packets per connection interval

[Neil_CPD]

Hi,

Device: NRF53

I'm trying to send 3 notify packets in a 15ms connection internal but I can send 2.

I'm using Nrf connect and Zephyr.  is there a limit or a define to set this.

Thank you for any guidance and help

Regards

[Neil_CPD]

Thanks for the update Simon.

[Simon]

I tried to increase the buffers in both the ble host as well as the controller, but it didn't help. I've asked internally about this and waiting for an answer.

[Neil_CPD]

Hi,

Sorry for the delay but I been on vacation..

I've spent some time this week trying to re-create the performance that you've managed to find but i've not been able to. I tried with the central and also on my phone but no success. 

I've attached your projects with my build folders in.  If you could please verify on a nrf5340-dk that would be great.

I've also looked at the log for the rpmsg and the messages seem to also be groups of two.3264.hr_mp_NC.zip

nc_hr_mp_test.pcapng

[ovrebekk]

Hi 

Hung is on leave, and I will help you out in the mean time. 

Normally issues with throughput on the nRF53 are caused by not configuring the hci_rpmsg application running on the network core properly. 

If you take a look at the throughput example in the nrf repository you can see that they define a separate config file for this application, in a folder called child_image:
https://github.com/nrfconnect/sdk-nrf/tree/master/samples/bluetooth/throughput/child_image

Can you try something similar for your project and see if it improves the number of notifications you can achieve?

Best regards
Torbjørn

[Neil_CPD]

Thanks for the reply,  I've checked  the "nrf connect SDK project.." in hci_rpmsg_menuconfig and they seem to be correct,  If there a good way to verify that the values have been built into the project?

if I add the child image folder do I need to regenerate the project in nrf Connect?

Thanks

Neil

[ovrebekk]

Hi Neil

Neil_CPD said:

If there a good way to verify that the values have been built into the project?

If you open your build folder, and navigate to the subfolder \hci_rpmsg\zephyr, there should be a file called .config which contains all the pre-compiled configuration settings:

In this file you can search for the config parameter you are interested in (such as CONFIG_BT_CTLR_RX_BUFFERS), and verify that it is set as you expect. 

Neil_CPD said:

if I add the child image folder do I need to regenerate the project in nrf Connect?

Yes. This is not picked up by the build automatically, and you need to re-run cmake in order for these settings to be included. 

You can do this from the command line by running west build with the -c parameter:

west build -c

If you use Segger Embedded Studio there is a menu option to rerun cmake:

Menu -> Project -> Run CMake...

Best regards
Torbjørn

[Neil_CPD]

Hi Torbjørn,

Thank you for the advice.  I can see all the config values that Hung has set in the project that he has attached but this hasn't made any difference I still only get 2 notify packets per connection.

Do you have a nrf5340-dk that you could test with and attach the build folder so I could program the hex as a test please?

Or if you have any other suggestions to try next that would be great.

Thank you.

Neil

[ovrebekk]

Hi Neil

I can try to reproduce the issue here, yes. My first test wasn't very fruitful as it showed a lot more notifications sent per connection event, but I was testing with a higher connection interval. I will spend some more time with this tomorrow and see if I can make an example demonstrating higher throughput with 15ms connection interval. 

Best regards
Torbjørn

[Neil_CPD]

Thank you Torbjørn,  I can only get two packets on any connection interval. it doesn't seem to matter if it's 40ms or 15ms

[ovrebekk]

Hi Neil

Checking my test results again I realized it was still only sending two packets pr connection interval, it is just the interval that was much shorter than I expected. In other words I got the same issue as you. 

Discussing this with the software team it seems there is a limit in the SoftDevice controller on how many packets it can queue, which is set by the SDC_DEFAULT_TX_PACKET_COUNT define in \v1.6.1\nrfxlib\softdevice_controller\include\sdc.h:

/** @brief Default maximum Link Layer TX packet count per connection.
 *
 * With the default count, the application is able to refill the buffers during a connection event.
 */
#define SDC_DEFAULT_TX_PACKET_COUNT 3

Normally this isn't a big limitation, as it is possible to upload new data while the connection event is active, but in your case you are sending very short packets, which makes the timing much tighter. 

On the nRF52 this works, but on the nRF53 there is some additional overhead because the packets have to be transferred from the Bluetooth host running on the application core to the Bluetooth controller in the network core. 

If you change the number above and recompile you should see that you can send more packets pr connection event. I set it to 5, which gave me 4 packets pr connection event consistently. 

Alternatively, if you send longer packets you should be able to send more of them, but I don't how long they need to be. The throughput example uses packets > 200 bytes, and doesn't have this problem (if it did the issue would probably have been spotted earlier). 

I will discuss this with the team and see if we can get a better solution in the future, such as a configuration parameter that you can set in the project, so that editing the library header files is not necessary. 

Best regards
Torbjørn

 

[Neil_CPD]

Thank you for the feedback, I will try this today.  Do you know how Hung managed to send so many packets?

[ovrebekk]

Hi Neil

Looking at his sniffer trace I see that he sent longer packets (35 bytes, including the 3 byte attribute header). 

Clearly this is long enough to loosen the timing enough so that you can upload more packets during the connection event. 

If your end goal is to maximize throughput, rather than sending many small packets, this is a simple fix to the problem. Just ensure you use a characteristic that supports longer packets (the heart rate measurement characteristic does not). 

Best regards
Torbjørn