is there is a list of known (and unknown) Event 21 types?

On top of this I find many undocumented fields for documented message types, e.g. fields 8, 9, 10, 11, 12 in gps_metadata for VIRB Ultra 30.

sub event 7 is "off course"

sub event 10 is a "course point"

these can flood the FIT for obvious reasons if used

undocumented global 79 appears to contain some of the event 21 data fields the next activity so these are user profiles of some kind as they change or are updated used by firstbeat/garmin metrics

event 21,49 becomes 79,11  which we know is LT HR

event 21,48 becomes 79,12  which I am still not sure, but since it's between two LT data, likely LT related

global 140,16 appears to become 79,13 and that one I have some notes, it is LT pace / 36 = meters per second

so global 79 is very interesting, even more than 21

according to "golden cheetah" in 79

#1: default Min HR 

#2: default Max HR

#5: user Min HR 

#6: user Max HR

ah, since #2 is 100% HR it is considered LT HR when that mode is set on the watch

when LT detection is not set on the watch fields 11 and 13 do not appear to be set

12 is still set though and it's the same for me years ago as it is today, is it weight? if so it's an odd multiplier

0 looks very interesting, I think it might be metmax related

0, 3, 8, 9  are a mystery but appear even on an ancient vivoactive v1 without HR so they are user profile related

update: 79,8 appears to be remaining recovery time in minutes at the start of the new activity, so it's a carry-over from the ending recovery time in 140,9

79,9 is mysterious though, large number, I think it's related to weekly load by can't understand the multiplier

I was wrong, sub-event 39 aka "performance condition" happens at seemingly random times.

I have runs at six minutes, I have runs at 6:45, today it was at a whopping 14 minutes.

It's a firstbeat mystery, something in their algorithms that's not documented, I doubt it's waiting for a certain number of heartbeats because that's too many minutes difference, it's waiting for some kind of consistent data or some kind of change.

The number it generates is unsigned, where 100 is equal to "0" (zero) performance condition change, 99 would be "-1" and "101" would be +1 etc.

Except I've noticed that "performance condition" is not based on the vo2max (metmax) the activity starts with, it's some kind of new calculation that I cannot find in the data stream. It may be why it takes 6-14 minutes to start.

The performance condition is then placed into every record as as developer field 90 (and how garmin-connect makes the graph)

Figuring out EPOC and the vo2max at the point performance condition is measured is driving me crazy.

I'm thinking the answer has to be somewhere in global 79 at pre-activity and then something in global 140 after the activity but none of the undocumented numbers seem to match any pattern

okay now I understand sub event 39 is actually the starting performance condition calculation base -100 offset (though I still don't know what time it chooses or why, it can be 6 minutes or 14 minutes or anywhere in between)

the event is when it pops on your screen on the watch, it's easier in the FIT than scanning for the first 20 record with a performance condition

since performance condition is a rounded vo2max which is rounded metmax it's possible to work backwards

65536/3.5 = 18724.57 is the scale for metmax to vo2max conversion

final metmax for the activity is stored in 140,7 and sometimes elsewhere but I've never found a pre-activity metmax saved

you can also use the timestamp on the event to check for HR at that moment in the records, and what else was going on, etc.

btw I wonder if Garmin realizes they could issue a FIT file with only 207/206 globals defining all the native fields in addition to the spreadsheet, that would be very meta, FIT defining FIT

So the "recovery heart rate" difference does NOT always match the last heartrate recorded for the last record in an activity, there doesn't seem to be a consistent pattern for how far back it goes and it doesn't appear to be an average of say the last few seconds

Any chance a garmin dev will look at the code and tell us the exact formula for which last beat is used to compare?

Is it possible the watch keeps a last beat in memory for the calculation that doesn't get written to the FIT records because of the "stop all" button press event?

I am referring to this, examination of the records shows the bracketed difference does not always match the last record.

support.garmin.com/.../

Was hoping, expecting actually, that there would be an event when a new Max HR is detected, just like when new LT HR is detected.

But new max HR happened today and nothing in the FIT. 

Just quietly added to the firstbeat global message number 140, using field number 1

Also very confusing, the max HR never appears in the records, today was an easy run and I never got even close to that HR

There's no timestamp, nothing, just the new HR

It's not like the 220+ you see when the HRM strap disconnects so I don't think it's imaginary, in fact the number is very plausible.

Makes no sense to me, I have to study it more and try to understand how it is coming up with the number.

Since I am using an HRM-TRI it may appear in the downloaded data but I hate doing that because it removes the original FIT from the watch, which I can restore but it messes with the totals and stuff.

No timestamp seems really odd for hr, and it's key to most of the data.

Doing a FIT CSV -> FIT using dev data would be kind of cool. The good thing with text is that its easily edited. The bad thing with text is that it's easily editable... I imagine having a fit-file with all definitions as dev data would also integrate really well with most fit-workflows (as opposed to parsing a specially formatted csv from the sdk).

Can you go through some of your own FIT files and look at event 21, sub event type 48 and/or the unknown global 79 field 12 which will be the same value and see if it holds any logic for you?

For me this number does not change ever, for years and years. It's a low number for me, 126 so I thought maybe it's the low heartrate for an activity but no that does not appear in any records and I am past that a minute into the run.

Looking at Rainmaker's files, he's had 239 and 299 for that, even a disconnected HR monitor does not jump that high.

Because it is copied to 79, I think it has to be heartrate/zone related. But it also does not appear on garmin-connect for calculated heartrate zones.

For 79, the local 11 is LT HR, the local 13 is LT pace

So 12 has to be ??? Hmm.

(I found another event, 37, from years ago when I had a 620 with a HRM strap (620 didn't have optical). 37 is not used on the Fenix that I can find. It is a low number, might be detected resting heart rate vs user manually entered.)

For VIRB there nothing really in there from looking at several files, just the timer start (just single record for 21 so no timer stop):

[1] Global ID: 21 | Message type: event | Header: 2/0b00000010
    id: 253 timestamp             : UINT32([2]) 
    id:   3 data                  : UINT32([0]) 
    id:   0 event                 : ENUM([0]) timer
    id:   1 event_type            : ENUM([0]) start
    id:   4 event_group           : UINT8([0])

For the files in the big fit-file stash you posted it's mostly the same, but some event_type/1 fields denoting "marker" and seemingly some bike stuff (from Lezyne and 9,10,11,12 all are gear related, such as 9 "front_gear_num", see 07Mar2017 - Run/Lezyne Enhanced Micro C GPS - 3321482E.fit in that big zip). Also mostly only a single record per file.

Seems like a message type for a bit of everything, pre-developer data perhaps?