Acknowledged
11 months ago

: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.

ak6i
Parents
  • 11 months ago

    This behavior is by design, like has already been mentioned. The decision was made to not allow Connect IQ apps to override "native" activity data to avoid customer confusion. I understand and generally agree with your argument here, and the same argument has been made before in the past, but I don't anticipate this changing unless we can come up with another solution. Just off the top of my head, maybe Garmin Connect could handle :nativeNum intelligently by keeping the CIQ field data graphed separately but including the data in related totals (e.g. elevation gain you mention in your example).

    I'll pass this along to see whether it's something that can be revisited for future enhancement.

Comment
  • 11 months ago

    This behavior is by design, like has already been mentioned. The decision was made to not allow Connect IQ apps to override "native" activity data to avoid customer confusion. I understand and generally agree with your argument here, and the same argument has been made before in the past, but I don't anticipate this changing unless we can come up with another solution. Just off the top of my head, maybe Garmin Connect could handle :nativeNum intelligently by keeping the CIQ field data graphed separately but including the data in related totals (e.g. elevation gain you mention in your example).

    I'll pass this along to see whether it's something that can be revisited for future enhancement.

Children
  • 11 months ago in reply to Brandon.ConnectIQ

    Thanks for the reply. I think including the data in related totals is the value-adding part here, and would reduce customer confusion - as a customer, I was certainly confused as to why the elevation on my treadmill runs didn’t count! So it would satisfy my need if you went for this solution.

    You’ll know the underlying data model better than I do so you’ll know whether this is feasible, but maybe an alternative would be to import data into native fields but indicate when native data has been provided by ConnectIQ apps by including the IQ logo next to the field? That’s probably a bigger effort though. Maybe in addition to the “fitContributor” permission you could add an extra permission for native field contributions, which would enable more thorough reviews of apps wanting to contribute native fields. I’ll stop now as that’s probably enough scope creep for one day. ;)