For now, we only expose the live heart rate values. Exposing steps the same way won't be difficult.

For more advanced features, companion app need more than just the current value, they'll need an historic of all the data acquired during the day/night, even if the watch was not connected to the companion app when the data was acquired.

This goal of this discussion is to define how the data will be stored and the API InfiniTime will expose to the companion app.

I asked Adam from Amazfish how fitness data were managed on other devices :

• The watch stores the data with a specific granularity along with a timestamp. Ex : number of steps counted every 10 minutes, HR value per minute,...
• The data should be stored in some kind of circular buffer so that we ensure we don't fill the memory
• Using BLE, the companion app request the data from a specific date-time, and of course, InfiniTime sends them if they are available in the buffer.

Questions:

• What would be an ideal granularity for the data/timestamp?
• Should the data be stored in RAM? External flash? Temporarily in RAM and flushed in external flash from time to time (pay attention to wear of the flash memories) ?

Settings

In settings, we define the granularity (the delay between 2 samples). Ex : 10 minutes

Data acquisition

InfiniTime monitores the data (steps + HR if enabled) and accumulates them during the "granularity" period.

When the period elapses, the accumulated data are appended in the circular buffer in the form

struct FitnessData {
  uint64_t timestamp;
  uint8_t nbSteps;
  uint8_t heartRate;
}

We could also add average/min/max for the heart rate value. We can also store a single reference timestamp, and then store a delta from this timestamp in FitnessData to save a few bytes for each sample.

BLE API

Service : FitnessDataService
Characteristics:

• Period (Read/Write) : the companion app can read the current acquisition period and set a new one.
• Commands (Write)
  • Request data from a specified timestamp
  • Clear data (from / to a specific timestamp)
• Data (Read) : requested data will be written on this characteristic
• Data available (Notify) : notifies the companion app that new values are available

The protocol should be designed in such a way it will be possible to extend it (add a version characteristic or field in the data sent to the companion app).

Let's talk about this ;)

These are just some ideas out of my head, feel free to give your opinion.
I'm not sure that 'fitnessData' is the most appropriate name for the data...