Garmin should allow datafield devs to append extra info into activity summary details

rinserepeat said:

For years I've wanted to see the actual vo2max with decimal, the finishing performance condition for a run,

I know this isn’t exactly what you’re looking for, but you can see this information in runalyze.com

- runalyze shows your average VO2 max after each run, to 2 decimal places. (this is clearly some sort of rolling average, based on the fact that it never changes too much from run to run, and also based on various things Garmin has said about its VO2 Max estimates, and the fact that this number matches those estimates, after rounding)

This matches what’s graphed on the watch in the VO2 Max page of the Training Status glance. (The current VO2 Max number itself in the glance is rounded, but the graph in the glance reflects the changes in the unrounded number over time, unlike Connect, where the points on the graph are rounded and connected with straight lines.)

Unfortunately, Garmin does not record a strictly per-activity, non-averaged VO2 Max, although runalyze does calculate its own per-activity VO2 Max, independently of Garmin.

- runalyze shows your starting and ending performance condition

rinserepeat said:

Why not allow datafields to append those averages into the FIT file via the API and if they are in the FIT file then show them on the details page?

As long as your data field has access to the data you’re interested in, it’s absolutely possible to record it to the FIT file [*]. (Not sure how you will obtain VO2 Max with more than 0 decimal places, for example, since VO2 Max in the API is a Number, so it must be rounded just like the number that’s displayed in Connect and on the watch.)

[*] subject to limits on the amount of data that can be recorded, both for a single CIQ data field, and for all CIQ data fields in the same activity.

[https://developer.garmin.com/connect-iq/core-topics/activity-recording/]

[https://developer.garmin.com/connect-iq/api-docs/Toybox/ActivityRecording/Session.html#createField-instance_function]

In your data field, you will want to call FitContributor.Field.createField() with a mesgType of MESG_TYPE_SESSION, for each custom value that should be saved to the FIT file and displayed in the activity summary in Connect.

Not exactly the same but I opened a feature request not long ago in similar "spirit": forums.garmin.com/.../feature-request-include-custom-fit-session-fields-in-the-activity-summary-or-all-stats-displayed-after-saving-an-activity

Oh sorry, I assumed you meant displaying custom activity data in Connect, but now I see maybe you meant displaying it on the watch?

I mean, yeah, a data field can write custom data to the FIT file, but you do have to use the Connect app on your phone or the Connect website to actually see the data.

If you want to see custom activity data on your watch, then flocsy's feature request would be relevant.

I don't even use runalyze, I wrote my own code to take the FIT file apart and not even trust the API

which is handy because I can sometimes decode corrupt FIT files the API won't process

many undocumented fields are now available from various open-source projects

But for a decade now Garmin refuses to put decimal places for many metrics on the watch and it's annoying as *** that I have to wait until I get to a computer to see the result

Remember when Strava was like that years ago, everything only whole numbers?

Everything changed when they added at least one decimal place.

And it's not just vo2max which stupidly rounds up 55.50 to 56

Recovery Time too, ie. 25.1 hours is shown as 26

and many other metrics

Garmin it is 2025, at least add one decimal place in the details if you don't want to bother on the general display

There isn't even a vo2max datafield available, only performance condition, so if the Firstbeat formula bumps the vo2max in the middle of an activity (it happens) you'll never know and wonder why the performance condition goes to zero

They could show  55.5 +1   as vo2max + PC as a optional datafield but nope

Maybe another decade they'll finally do it

Not sure I follow your rant.

I know in math round(55.5) is 55 but I think Garmin understandably uses ceiling(55.5) which is 56. ceiling(0.1) is 1. Because they display hours as integer I think this is a logical decision. It's better to wait a few minutes more, than to start to run a few minutes earlier ;)

As for displaying floats in Garmin connect,  it's possible, you create a field with FitContributor.DATA_TYPE_FLOAT and you can set the precision you want it to be displayed with in Garmin Connect in the fitcontributions.xml:

I see, so you are asking for the ability to display additional information in the activity summary on the watch.

It wasn't 100% clear from the OP, since you also seemingly asked for the ability to do something which already exists (add information to the FIT file), and you also mentioned doing some thing which are currently impossible (having a CIQ data field access certain data that's already available, but with greater precision than normal, or data that isn't available.)

I mean, it seems there's a couple of separate feature requests here (albeit all directed at a common use case for you):

- allow devs to have FIT session fields appear in the watch's activity summary, not just in Connect (flocsy's feature request)

- allow devs to access certain information that's already available, but with greater precision than normal, on the watch (e.g. access unrounded VO2 Max; currently VO2 Max is only available as an integer in the CIQAPI)

- allow devs to access certain information that's not already available via CIQ, such as performance condition

All I can say is I'll vote for your feature requests if you open them.

I think they're saying that certain built-in Garmin metrics are written to the FIT file as floats (like VO2 Max), but only displayed in Connect as integers.

That's why I mentioned VO2 Max in runalyze, which is not rounded. And as rinserepeat said, it's also possible to just decode the FIT file yourself.

And yeah, I think the OP is talking about a lot of completely separate issues (united by a common use case I guess) in a way that's slightly confusing.

Like I said, there's at least 3 separate feature requests in OP, but it's presented as if it was a single issue.