Accidental duplicate post. Please delete this Discussion copy and retain the Question version.

【Duplicate submission created accidentally. Please delete this Discussion thread. The Question version is the intended thread:

 How should more than five RR intervals from one BLE notification be serialized into FIT hrv messages?  】

I would like to distinguish between the capacity of one FIT hrv message and the number of RR intervals delivered by a sensor in one BLE notification.

In a previous FIT SDK discussion, Ben FIT explained that the hrv.time array contains between one and five valid RR intervals, with five physical slots provided because the maximum heart rate representable in a FIT Record message is 254 bpm:

https://forums.garmin.com/developer/fit-sdk/f/discussion/255690/fit-file-hrv-data-array-interpretation/1220787

However, an incoming BLE Heart Rate Measurement notification does not necessarily represent one second of measurements and does not necessarily correspond one-to-one with a FIT hrv message.

The Bluetooth Heart Rate Service specification states that:

  • the RR-Interval Present flag may change during a connection;

  • a Heart Rate Measurement may contain no RR intervals or multiple RR intervals;

  • with the default 23-byte ATT MTU, one notification may contain up to eight or nine RR-Interval fields, depending on the other fields present;

  • the notification interval is determined by the sensor and may vary.

Specification:

https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/HRS_v1.0/out/en/index-en.html

A valid sensor implementation may therefore send several heart-rate-only notifications and then include the accumulated RR intervals in a later notification. If it batches approximately two seconds of data, a single notification can contain more than five RR intervals when heart rate exceeds approximately 150 bpm.

My FIT-format questions are:

  1. Is the five-value capacity only a limit of each individual FIT hrv message?

  2. If a recording device receives six to nine RR intervals in one BLE 0x2A37 notification, is the expected FIT representation to write the first five values in one hrv message and the remaining values in one or more immediately following hrv messages?

  3. Is it valid for multiple consecutive FIT hrv messages to originate from the same incoming BLE notification?

  4. Since hrv messages have no independent timestamps, are the values in these consecutive messages simply interpreted as one continuous RR-interval sequence in file order?

This question was prompted by an actual Forerunner 955 activity:

  • Approximately 2,004 seconds / one-second Record messages

  • 1,018 FIT hrv messages

  • Average spacing of approximately 1.968 seconds per hrv message

  • Physical capacity: 1,018 × 5 = 5,090 RR-interval slots

  • Valid RR intervals in the FIT file: 5,012

  • RR intervals in the aligned sensor-local sequence: 5,294

  • Difference: 282 RR intervals

If only one five-slot hrv message is written every 1.968 seconds, the maximum storage rate is:

5 × 60 / 1.968 ≈ 152.4 RR intervals per minute

This is very close to the heart-rate range above which the discrepancy becomes apparent.

In a separate low-heart-rate test, an nRF Connect log showed that the sensor sent a Heart Rate Measurement notification approximately every 700 ms but included accumulated RR intervals only about once every two seconds. All 136 RR intervals covered by that capture were present in the BLE payloads, in the correct order.

I have not yet captured the BLE payloads during the high-heart-rate portion, so I am not claiming that the FR955 has definitively discarded the missing values. I am first trying to establish the intended FIT serialization behavior.

Could the FIT team confirm whether more than five RR intervals received together should be preserved by writing multiple hrv messages, and whether that representation is supported by Garmin activity files?