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 Simon,

Have you heard any more from the team? Are there any early indications on where the limitations are?

Thanks

[Hung Bui]

Hi Neil, 
Simon is on vacation so I'm taking over the case. 

Could you please explain a little bit more on what you did to " have to sleep for 30ms in the thread to enable this to happen,  " 

If you keep calling the notification send which error do you have ? 

Note that when you change the buffer configuration make sure you reflash the network core. This is not done automatically if you flash using SES.

Do you need to send notification in separate packets ? If you always send 3 notifications per connection interval , can you combine them into one notification with longer payload ? If you have control over both sides of the connection , you can assign a larger ATT_MTU and update the data length to get bigger radio packet. 

[Neil_CPD]

Hi Hung Bui,

Thank you for picking this up.  The ultimate aim is to send160 bytes per notification packet three times per 15ms connection interval and this needs to happen every connection interval untill the user stops the device.

I can send two packets but not three, I don't get any errors returned.

As mentioned above Simon and I have used the uart example to test this. I can send 3 notifications in a loop within one connection interval if I wait for a delay of at least one connection interval in-between. Once a shorter delay is used it reverts to only two packets for connection interval.  I've tested this using the nrf sniffer. If you need any more explanation please ask.

Kind regards

Neil

[Hung Bui]

Hi again Neil,

Could you send a sniffer trace  ? 
Could you show how you send the notification in your code ? With and without the delay. 

Which firmware you use on the central side ? 

Would be nice if you can provide some minimal code so that I can test here (on both sides)

[Neil_CPD]

Hi Hung,

Please bear with me as i'm away from my desk for a couple of days but basically my setup was:

NCS 1.6.0 peripheral_uart example with the connection set to 15ms.

Central was my phone Sony XQ-AS52 with Android 11

while(1)

{

     loop 3 times

     {

         bt_gatt_notify_cb(.....)

      }

       k_sleep( 30 ms) or k_sleep( 5 ms) 

}

when I wait 30 ms I see 3 packets on the sniffer per.. but If I reduce the delay so it's every interval only 2 packets.

I'm not going to be able to send an nrf sniffer output for a week or so,  but the code is quite basic.

[Hung Bui]

Hi Neil, 
 I suspect that the central was not able to handle more than 2 packets per connection event. A sniffer trace would be very helpful to reveal this. 

[Neil_CPD]

Hi,

I will try to get you a sniifer trace but I do remember the more data flag being set to false on the second packet.

I also thought that Simon had tried this test with two nrf dk's.  Could you do a sniifer trace of it working with an nrf dk central please. If it's a limitation of the central then I can explain this to my customer.

Thanks

[Hung Bui]

There is a chance that it's hitting the limit of the stack. But we do need a sniffer trace to really understand the situation. 
Please also look at the throughput example. As far as I know you can reach around 700kbps at 1Mbps.given that the ATT_MTU is configured correctly and Data length extension is applied.