Hi All,
I'm currently designing my implementation of BLE Services/Characteristics and wanted a quick review to make sure I'm on the right path based on my implementation. For example, here are my product requirements: (Note that this isn't exactly my requirements, but close enough for the purposes of discussions and my challenges)
- My device takes a temperature sample from 16 different temperature sensors each second and records the data to an EEPROM device.
- My device limit checks each temperature sensor and generates an "event" if a temperature goes out of limits. It records this event also to EEPROM. The event contains a timestamp, event number, temperature sensor number, temperature data, etc (Roughly 64 bytes)
- The device does the above 24/7, regardless of its BLE connection. There are no requirements to act differently when a temperature "event" occurs. It simply records that such an event happens.
- When a central BLE device (likely a smartphone app), connects, the phone should have the ability to interrogate the peripheral device and acquire:
Number of Events Occurred
Raw data for each event
Raw data from all temperature sensors that have been recorded
...I see this very similar to like a Fitbit. A Fitbit is recording a bunch of data all of the time (steps, HR, etc)... and then the phone app downloads all of this data when it's opened.
So, in terms of a BLE design, here are my current thoughts:
1 Service for my "Custom Temperature Logger"
- UUID #1: Number of Events Recorded (read only)
- UUID #2: Raw Data Command (read/write)
- UUID #3: Raw Data Response (read/notify)
In this implementation, the smartphone app would read UUID #1 to determine that 3 events have been recorded. Then, I would implement some sort of command set where the phone would write into UUID #2 to send event data for event #1. Upon sending this command, the BLE device would start "streaming" notifications in UUID #3 with the raw data from the event until complete, and then set UUID #2 back to an "Idle" command. After which, the phone would then cycle through the other two events in the same fashion. I would have a similar command to read the 24/7 raw data from the device, where the device would just send a much larger data set, using the same architecture.
Is this appropriate? I ask since I want to make sure I'm not just implementing a "serial port" emulation and really using BLE characteristics appropriately. However, I cannot think of a more efficient way to structure my data, since each time my device will have a different number of temperature events logged, along with a different amount of raw 24/7 data.
In addition, in the BLE link layer, are notifications ACKed / retried if not ACKed correct? Or does one typically have to implement a way to ensure that all "streamed" data from continuous notifications are received correctly? I've found this thread and planning on using the basis of this to send my raw data: devzone.nordicsemi.com/.../
Thank you all in advance!! Let me know if you need more information!
