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

RE: 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 — Mon, 22 Feb 2021 17:53:59 GMT

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.

RE: 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 — Mon, 22 Feb 2021 16:45:09 GMT

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.

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

Hung Bui — Mon, 22 Feb 2021 16:27:22 GMT

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.