Acknowledged
CIQQA-4770

The new includeTimestamps in SensorData is not working, burst problem - FIT file attached

Title: Per-sample sensor timestamps are wrong and don't reflect the actual sampling times (fēnix 8 47 mm, FR 265/965, fēnix 7X Pro, .. )

Summary. With includeTimestamps on, the per-sample timestamps in SensorData come in clumps of 1 ms steps followed by 40 to 50 ms jumps, on 65 to 83 % of batches on the affected models. The samples themselves are intact: exactly 25 per 250 ms page for both sensors, 20,000 of 20,000 in the attached log, pages on cadence, exactly 100 Hz. The stamps claim 25 samples in 109 to 149 ms, which no sensor delivering a steady 25 per 250 ms can do. So the stamps likely describe when the FIFO was drained, not when the samples were taken.

One real page (attached log, page 5, ms from the page base):

acc observed : [0, 1, 2, 43, 47, 48, 49, 50, 52, 53, 94, 95, 97, 98, 99, 100, 101, 101, 102, 144, 145, 146, 147, 148, 149]
gyro observed: [0, 1, 5, 6, 7, 8, 9, 50, 52, 53, 54, 55, 56, 57, 58, 58, 100, 102, 103, 104, 104, 106, 106, 108, 109]
expected     : [0, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 150, 160, 170, 180, 190, 200, 210, 220, 230, 240]

Impact. Our acc/gyro alignment uses these stamps for sensor fusion. Obviously we get bogus results with this bogus data. 

Ask. Please resolve that on all models the stamps are actually correct. 

Attachment: raw sensor log from a fēnix 8 47 mm (session 2577806). Just open it in fitfileviewer.com to see the bursts in timestamps.  https://drive.google.com/file/d/1WOBx1sLW7QVorYrXgzeuUq5xKoLjmCS4/view?usp=sharing

Notes:

- Restart of the watch seems to resolve it, for a while till it breaks again.