Is it possible to update or flush stale notify data so a subscriber gets the freshest possible data even with a long connection interval?

[JustinL]

I am using nrf52840 via NRF Connect and Zephyr configured to use the Nordic SoftDevice BLE controller.

My use case is for a central to sample a rapidly changing real-time sensor on the peripheral with the condition that when a connection event occurs, the data is as fresh as possible.
Functionally this is working perfectly with the exception of freshness. 

Using the Zephyr API it is not possible to either know when a connection event starts or to overwrite or update the current notify data. Instead, whenever bt_gatt_notify() is called the data copied and put into a queue and will be served to the subscriber on the next connection event no matter how late that is.

This leads to a situation where the data pushed into the queue with bt_gatt_notify() could be very stale by the time the next connection event happens, even though the peripheral itself has much fresher data to hand from the sensor.

The zephyr team has confirmed this is a limitation of the architecture at the current time in the issue I raised https://github.com/zephyrproject-rtos/zephyr/issues/28809.

So my question is: is it possible to use the SoftDevice api directly (or through HCI custom commands)  to either overwrite the current notify data instead of queuing? or to provide a pointer to the data instead of a copy of the data? or to get a callback to my code to provide the notify data response when a connection event occurs (I understand that could be very bad in terms of strict timing). 

Or some other way that I can ensure the very lastest data on the peripheral is what is served to central during a connection event?

My current solution takes a notify sent callback to call bt_gatt_notify(). This means the data is always at least one connection interval old, which can be much staler than available data.

Many thanks.

[Hung Bui]

Hi Justin, 

As mentioned in the github issue you quoted, it's not possible to flush the data that's already queued to the controller. 

I checked with the team and providing pointer to the data is also not an option. 

Please note that BLE is a reliable protocol, so data can be retransmitted. On the peer side, it shouldn't expect that the notification just arrives is the latest data, it can be retransmitted data. So the best option I think is to have a timestamp in each of the packet. This way you can discard the data that has less meaning. 

Another option is to use radio notification, so that you can setup a timing event, a distance before the radio is active and can sample the data and queue it just right before the connection event. Again, there isn't any guarantee that the data will be sent at the exact connection event as there can be queued data, or retransmitting data. 

[JustinL]

Thanks for the quick reply.

I don't think timestamps will help since it is a real-time system so timestamps will let you know how stale the data is, but not actually allow improvement in the freshness itself.

However, the radio notification signal looks like it will basically solve the problem for me, if the data can be reliably queued just in time for the connection. So that is an excellent idea.

I look forward to trying it.

Thank you for your help.

[JustinL]

Thanks for the quick reply.

I don't think timestamps will help since it is a real-time system so timestamps will let you know how stale the data is, but not actually allow improvement in the freshness itself.

However, the radio notification signal looks like it will basically solve the problem for me, if the data can be reliably queued just in time for the connection. So that is an excellent idea.

I look forward to trying it.

Thank you for your help.