Acknowledged

:nativeNum field is ignored by Garmin Connect so accessories can't be integrated properly

Currently, when writing fields to FIT data that correspond to native fields, with the :nativeNum field populated, they are shown in Garmin Connect as ConnectIQ fields.

Why is this a problem?

Whilst Garmin's support of hardware accessories is pretty comprehensive, there will always be gaps.  For fitness equipment, for example, indoor bike trainers are supported, but treadmills are not.  Devices lke the NPE Runn implement ANT+ FE-C, which the latest Garmin watches claim to support, but they don't support FE-C Treadmill devices, so incline and elevation are not incorporated into workouts.  When developers implement apps or data fields to read the FE-C Treadmill data and store it in FIT contributions, these data can only ever show up as Connect IQ fields, which Garmin Connect doesn't do anything with.

As such, elevation gained on a treadmill does not count towards the 4-week elevation gain used to calculate Hill Score.  This is particularly important in the winter!

What should the solution look like?

When FitContributor data are provided with the :nativeNum field populated, the data should be stored in the correct native field.  Garmin should provide a list of supported native fields that will be correctly incorporated into workouts, and details of how each data field contributes to each activity.

Parents
  • I know Garmin won’t let you do it right now. I’m asking for a change to that as I consider it a bug: the harm done by not supporting :nativeNum is greater than the potential harm done from apps that let you fake data.

    It doesn’t have to be full support of every field - I’ve seen elsewhere some discussion around faking distance, for example - but there are plenty of fields where it would make sense, and there’s no need for Garmin to support overriding already-populated fields. I’m sure they could even somehow make it so that the native values are only incorporated when apps are downloaded from the store, meaning that they could go through the approval process and hence be vetted to avoid “cheating”.

Comment
  • I know Garmin won’t let you do it right now. I’m asking for a change to that as I consider it a bug: the harm done by not supporting :nativeNum is greater than the potential harm done from apps that let you fake data.

    It doesn’t have to be full support of every field - I’ve seen elsewhere some discussion around faking distance, for example - but there are plenty of fields where it would make sense, and there’s no need for Garmin to support overriding already-populated fields. I’m sure they could even somehow make it so that the native values are only incorporated when apps are downloaded from the store, meaning that they could go through the approval process and hence be vetted to avoid “cheating”.

Children
No Data