Reading log data records from a BLE device

Question

I am implementing a BLE device which stores some log data based on sensor data and a iOS app which acts a Central to access the data.

I know how to read GATT characteristics data, but I wonder how to read a bunch of from the device. Is there standardized way to do this?

My naive approach would be the following:

• Create a custom readonly-characteristic (A) which contains the number of log records
• Create a custom writeonly-characteristic (B) which contains the index of a record
• Create a custom readonly-characteristic (C) which contains the data of the log record with the index of (B).
• Create a custom writeonly-characteristic (D) to delete all stored records.

To get the log data I would have to read the number of records (A), then do a loop and write an index to (B) and read the data (C).

Is this the way to go or is there a better approach?

My log data records would contain a timestamp and a 8 bit value with sensor data.

Answer 1

This is a good way and it would work, but if you will always read all the records, then it is inefficient to be doing multiple writes from the central (in a loop). Instead, you can just do a one time write from the central, then the code on the peripheral would go in a loop and send all the data to the central. In this scenario, your solution would have the following on the GATT server:-

• A custom characteristic that is notifiable.

And that's it, that is all you need. When you want to read the log data, you can use the following sequence:-

1. The central device enables notifications on the peripheral.
2. The peripheral device sends out a notification to the central device with the first set of logs.
3. The peripheral device sends out a notification to the central device with the second set of logs.
4. The peripheral device would keep sending out notification to the central device until the list of logs is complete.
5. The peripheral device can send a special notification (e.g. all 0s) indicating that all the logs were sent completely. Alternatively, the peripheral can stop sending notifications altogether, and the inactivity would be an indication to the central that there is no more data to send.
6. The central can then disable notifications on the peripheral device so that no new data is sent. The central can actually stop the transmission of the logs at any point by disabling the notification.

Finally, you can set your characteristic to be indicatable instead of notifiable. The only difference is that there will be acknowledgements when it is indicatable therefore the transfer is more reliable. However, the transfer will also be slower as a result of the extra acknowledgement packets.

I hope this helps.