How to serve queued data via BLE?

[espruino-discuss]

Posted at 2021-08-18 by ChristianW

Let's say I have a Puck/Pixl/MDBT42Q collecting data in a queue.
Before any overflow happens this data should be polled via BLE by another system as BLE central.

So as BLE peripheral I use NRF.setServices() to create some Service/Characteristics for pushing out data.

The thing is: How can I know if the central actually read the data so I can remove it from my queue?

For the other direction onWrite is a synchronous API for writing data back, but for reading there is only:

• notify: true and/or
• indicate: true which is documented as notify + ACK.

But how does it work?
As peripheral I am supposed to call NRF.updateServices() and set a new value.
But how can I detect if this value was successfully read by the connected central?
How often should I call updateService() in case the queue got filled up a bit and there are N items waiting?

My current idea is a multipart API:

• use onWrite so the central can request the next item
• in return the requested item is presented via updateServices()

If the queue entries have some kind of timestamp or sequence number I can assume that all previous entries are read already and safely remove them.

What do you think?

[gfwilliams]

Posted at 2021-08-18 by @gfwilliams

As peripheral I am supposed to call NRF.updateServices() and set a new value.

Yes, that's right, and you specify notify:true: http://www.espruino.com/Reference#l_NRF_updateServices

But how can I detect if this value was successfully read by the connected central?

Unfortunately I don't think there's any way of doing that at the moment. You could try just calling NRF.updateServices until you get an exception?

My current idea is a multipart API:

I think that's probably the best idea. On newer firmwares the device should have been able to negotiate a higher MTU so you can send 50 bytes each time (not 20) as well, which should make things easier.

I guess on your onWrite event you could have different message types:

• request a packet of data
• acknowledge receipt of last packet of data, request a new one
• acknowledge receipt of last packet of data and request a new one

[yerpj]

Unfortunately I don't think there's any way of doing that at the moment. You could try just calling NRF.updateServices until you get an exception?

I am also trying to push as much data as possible into the 20-byte buffer of a BLE characteristic and therefore I need to know if the lastest data has been sent so that I can send more. Does anyone know if anything has been added since then?

[yerpj]

In S132 it seems that a BLE_EVT_TX_COMPLETE event can be used for that. Someone achieved 32kbps and documented it here
However I don't know if it can be used in Espruino, I don't even remember which softDevice is used.

[gfwilliams]

Ok, interesting - looks like that's for older softdevices, but we handle it at https://github.com/espruino/Espruino/blob/ef51f1f37e4ed778da225b1d556bcd31ca088074/targets/nrf5x/bluetooth.c#L1532

If you write a characteristic with the Web Bluetooth-ish API then we handle that and resolve the promise when it's done.

I guess NRF.updateServices could be made to return a promise which resolved when the packet had been sent? However if we did that it'd only be able to have a single NRF.updateServices in-flight at once, which is perhaps worse than the current situation?

[gfwilliams]

... also I should add that in most Espruino builds now I'm pretty sure we support >20 byte characteristics? So you could just put more data into each write

[yerpj]

Yeah that's maybe better to keep it as is, even if at some point, providing a mechanism capable of maximizing the throughput could be a great differentiator against other BLE platforms. Whoever wants to log data always wants at some point to optimize either for throughput or for low power consumption, the latter being already excellent with Espruino.

[yerpj]

I see that something has been started regarding this event but without providing an index for queued data it is not possible to tell which one is done and which one is not.