I am getting some weird results for months now with the firstbeat lactate threshold autodetect in my Fenix6 with a HRM-Pro-Plus
Pretty sure this is due to the broken firmware on the pro-plus which Garmin seems to refuse to fix but it might also be lag or outright bug on the realtime pace calculation, because the HR bpm seems plausible but the LT pace is clearly wrong.
But while I can see -if- LT is autodetected in a FIT file, I cannot see WHEN a record or second was used, which is especially confusing if the heartrate detected appears many times in a run
message 79,11 is the current user's profile heartrate for LT (lthr) and 79,13 is the LT pace
message 3,41 is the current user's profile timestamp when that LT autodetect was originally SAVED (not detected)
message 21,49 is the auto-detected event for LT heartrate and 21,50 is the auto-detected LT pace
(afterwards there is also the activity summary message 140,14 for LTHR and 140,15 for LTpace repeating the same autodetection)
The problem is event 21 is only done AFTER the activity when it is being saved, not realtime.
The timestamp it uses is the same as the close of the session so it is during the saving process, not the actual event.
So there is no timestamp marker around that event inside the FIT file to understand where or when it happened.
event (21, type: 14, length: 14 bytes): timestamp (253-1-UINT32): 2024-05-18T06:46:02 (1084963562) data (3-1-UINT32): 158 event (0-1-ENUM): 49 event_type (1-1-ENUM): marker (3) event (21, type: 14, length: 14 bytes): timestamp (253-1-UINT32): 2024-05-18T06:46:02 (1084963562) data (3-1-UINT32): 3277 event (0-1-ENUM): 50 event_type (1-1-ENUM): marker (3) session (18, type: 5, length: 308 bytes): timestamp (253-1-UINT32): 2024-05-18T06:46:03 (1084963563) start_time (2-1-UINT32): 2024-05-18T05:43:59 (1084959839) total_elapsed_time (7-1-UINT32): 3580.857 s (3580857) total_timer_time (8-1-UINT32): 3580.857 s (3580857) total_distance (9-1-UINT32): 12198.60 m (1219860)