bt_gatt_notify_cb callback delayed by one connection interval. Faster alternative?

[pertan]

Hi,

I'm developing an application where data is streamed from a BLE peripheral using notifications. I'm currently using bt_gatt_notify_cb to send each packet and wait until the completion callback is invoked before sending the next packet. I've noticed that the completion callback is consistently delayed by about one connection interval. I'm assuming this is related to how the BLE stack handles packet ACKing, as mentioned in this thread the.

Since I'm interested in minimizing latency, I wonder: Is there some other notification mechanism that I could use that does not suffer from this delay, like some lower level SoftDevice or BLE stack events?

I'm using nRF Connect SDK 2.5 and SoftDevice.

Thanks

[Kenneth]

Hello,

You can use bt_gatt_notify() instead of bt_gatt_notify_cb(). All data is allways acked and sent in the correct order by the link layer in BLE, so the additional callback that bt_gatt_notify_cb() provide is not really necessary (it only slow down transfer since it suddenly depends on application do what the link layer is already doing, and the application it not able to do it as fast at the link layer) . For fastest transfer just call bt_gatt_notify() as fast you can until you receive an error that indicate the buffers are full, when buffers are full you typically need to wait until ~connection interval period until you can fill the buffers again. 

Kenneth

[pertan]

Hi Kenneth,

thanks for your reply. I am aware of the bt_gatt_notify strategy you mention, but my application needs to make decisions about what to send just before each notification is transmitted. I'd also like to keep track of the number of available buffers with as little latency as possible, which is why I'm looking for an alternatives to bt_gatt_notify_cb. Do you know if there are any alternatives or is bt_gatt_notify_cb the closest I can get?

[Kenneth]

There is no application interrupt or event that will be able to handle the real time requirements of the BLE (so by the time the application handle the callback it's already too late to add a new packet in that connection event), so the only option I can see is that you somehow allow severals packets sent with bt_gatt_notify() and only intermittently use bt_gatt_notify_cb() in such case.

Kenneth

[pertan]

Getting the callback before the next connection event would be good enough for my use case. Is there perhaps a way of achieving that?

[Kenneth]

I suggest to check out the following example:
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.6.0/nrf/samples/bluetooth/connection_event_trigger/README.html 

Kenneth

[pertan]

Maybe I'm missing something, but that example seems to show how to get events at each connection interval (which I'm already doing in my application using the MPSL radio notifications API). Looking at the sample code and sdc_hci_vs.h it's not obvious to me how it relates to receiving events on completed transmission of notifications. Is it possible to do this using the SoftDevice Controller Vendor Specific HCI Interface? If so, any pointers would be much appreciated.

[Kenneth]

Hello,

My last reply was a suggestion to your question: "Getting the callback before the next connection event would be good enough for my use case. Is there perhaps a way of achieving that?"

I don't really have any other suggestion than what you are already are aware of.

Kenenth