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]

I've created the same issue that i've been having with a basic hr example using NCS 1.6.1.  in the 1st example I loop round 3 packets then sleep 5ms the other I sleep 30ms. See attached 2 sniffer traces. You can see in the 4ms trace it sends two packets per connection interval to one with 30ms sleep it sends 3 per con interval.hr_example_3packetLoop30ms_sleep.pcapnghr_example_3packetLoop5ms_sleep.pcapng

[Hung Bui]

Hi Neil, 

Attached you can find my example of sending 25 notifications in a 15ms interval connection. 

It's not the maximum limit I believe. If you increase CONFIG_BT_CONN_TX_MAX you should have more but the CONFIG_BT_CTLR_RX_BUFFERS is limited to 18. 
I found that what slowing down the rate in the original centralhr example was the printk inside notify_func() that causing the central to NACK the packet from the peripheral. 

In my test with my Galaxy S10 it achieved similar number of packets.

Please try the example I provided here and if it works please follow the configuration in my projects.

3264.hr_mp.zip

4745.sniffertrace2.pcapng

[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