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.

[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

[Neil_CPD]

Morning Torbjørn,

The end goal is to be able to send a minimum of 3 x160 byte packets every 15ms interval so this should be fine.  My new issue is that the original project is on an older SDK version that the fix doesn't work on but the fix for that is to update the sdk to the latest.

Thanks for all your help.

[ovrebekk]

Hi Neil

In that case the fix should probably not be needed, if you are sending 160 byte packets. 

Migrating to a newer SDK should be less of a hassle now than it was in the old days (with the nRF5 SDK), but this depends on how complex your project is obviously. 

The best of luck

Best regards
Torbjørn

[Neil_CPD]

Hi Torbjorn,

Thank you for your support with this, I've integrated with the project and it's working well.

...also thank you Simon and Hung

Many thanks,

Neil