BLE Streaming Question

[dgutierrez]

Hi,

Using the nRF52 dev kit with S132 Soft Device, with code based on examples with notifications.

I'm trying to send 20-byte notifications to an Android central each connection interval to see how low I can get the latency. Currently, when notifications are enabled I call sd_ble_gatts_hvx() to enqueue an initial notification. Afterwards, each BLE_EVT_TX_COMPLETE event enqueues a new notification in order to transmit each connection interval (read this on other posts on the forum). The notification data are all zeros so no overhead fetching, etc.

Observations

1. There must be always two notifications in the queue in order to transmit each interval, and this effectively doubles the latency (as expected). If notification A is in the queue, then B must be added, wait for A to transmit, then B is transmitted on the next interval.

2. If the queue only always has one notification (same scheme above but without the initial enqueue) then transmission only occurs every other interval, which gives the same latency. The central and peripheral exchange empty PDUs between transmissions.

3. Every once in a while the code happens to enqueue another packet when the radio is still on so two notifications are transmitted. Not sure if the central has something to do with this, or how it could force the peripheral to receive more. Found this out by setting up the ble_radio_notification signal.

Question

Is there something internally that is causing this behavior or am I using the Soft Device incorrectly? Even though queue contents can't be modified, is there a way to transmit each connection interval only one notification without the need to pack two notifications in the queue?

Also tried enqueuing with a timer, delaying after BLE_EVT_TX_COMPLETE before enqueue, and using the ble_radio_notification handler to enqueue the next handler. None solved the multiple notifications issue. A goal with this effort is to only send one notification at a time.

I know this may not be the best application for BLE, but just want to see what it is capable of.

Thanks in advance for your help.

[dgutierrez]

Hi,

I did try enqueuing with the on_active event, but didn't try the on_inactive event. Will try that and report, thanks.

As to a longer interval, that was interesting. Fastest the Android phone could go was an interval of 11.25 ms. By not keeping the queue always full with two packets, a notification happens every other interval (effectively a 22.5 ms interval) and there are no multiple packets. In between notifications an empty PDU is exchanged. However when I change the connection params to have a 22.5 ms connection interval and notify every interval the same problems occur which makes it seem like it has to do with the way the queue is being used...