FitContributor with Data Field WITHOUT having to create entire App?

I need to do something very simple without having to write the code for an entire app. I've created a ConnectIQ Data Field which can easily be added to the pre-existing Garmin Run activity to show ANT+ sensor Power in watts from a force sensor in the running shoe, just like you would inside the Bike activity if you were riding with an ANT+ power meter. This combination with the Run activity allows combination of watts with Running Dynamics fields already available from the Garmin run strap. It works just find for display on the watch, but does not save to the pre-existing .FIT file generation within Garmin's own Run activity. Of course, it can work with the Bike app and save the power in watts, but then the running dynamics are not available there.

Is there any way to use the FitContributor module to simply add this additional Power field to all the other ones already being recording in the Run activity .FIT file? I know you can do this by writing a complete app like the Moxy Sample, but this is for lots of fields in a truly unique configuration and I just need to add one field to the one-second record for power in watts.

It says in the documentation that FitContributor works for a Data Field and App, but it does not say a Data Field WITHOUT creating a custom Watch App.

Any thoughts? Great stuff in the forum on how to use FitContributor with Apps like Moxy sample, but not something simpler. Before I try it on my own, to strip Moxy way down to work as a Data Field for only one value, I'd like to know if it's even possible.

Thanks,

Ironman.Texas
  • I am confused about the root problem you are describing here. Just to clarify. Have you observed that just adding the :nativeNum=>7 option to the Fit field initialization in your app changes the data written to the FIT file on the 735XT?

    i.e. Changing from something like this:

    power = dataField.createField("myPower", 1, Fit.DATA_TYPE_UINT16, { :mesgType=>Fit.MESG_TYPE_RECORD, :units=>"watts" });

    to something like this:

    power = dataField.createField("myPower", 1, Fit.DATA_TYPE_UINT16, { :nativeNum=>7, :mesgType=>Fit.MESG_TYPE_RECORD, :units=>"watts" });

    where everything else is left the same causes different data to be written in the records of the FIT file?

    edit: I ran a quick test on my 735XT and did not observe a problem like this. Both the nativeNum and non-nativeNum data were as expected in the FITtoCSV converted file.
  • Fixed all User Settings and :nativeNum problems--thanks again for help

    I feel pretty stupid now, having figured out what was wrong with my user settings. After rewriting the UserSettings code and the resources files about 50 times and uploading about 20 different builds, it finally dawned on me that the reason I could NOT see those three little white-on-gray dots to change user settings in Garmin express was because MY APP TITLE WAS TOO LONG. It simply drove the icon out of the scroll window of Garmin Express. Instead of DO NOT APPROVE, I put DO NOT APPROVE! DEVELOPER TESTING ONLY, which filled the field and overwrote the clickable three-dot icon. Really stupid and it took about 10 hours of programming changes before I saw it. I had it right the first time.

    And the :nativeNum=>7 parameter is now working for TrainingPeaks and other apps, because I was tring to write an INT to the FIT file in stead of a FLOAT. They say in the programming guide it can be various types, but really, only FLOAT works even if you are getting a three-digit integer from currentPower. It ends up looking like an INT in Garmin Connect and elsewhere, but if you try to write specify INT you get a weird number, off by 50% or so.

    Someone should SAY only to specify FLOAT to the FitContributor fields. Seems weird and uneconomical, but there it is.

    So I think I'm done, the first-ever simple data field for POWER in watts running within the context of other Garmin Running Dynamics fields like GCT, Stride Lenth, Vertical Oscillation, etc.
  • Glad to hear everything is working now for you. I'm not sure why you needed to adjust to use a float when the FIT profile says it should be UINT16. If it's working I guess leave it but this one is working for me:

    var fieldWatts = feSession.createField(Ui.loadResource(Rez.Strings.FIT_Field_Power), 12, Fit.DATA_TYPE_UINT16,
    { :mesgType => Fit.MESG_TYPE_RECORD, :nativeNum => 7, :units => Ui.loadResource(Rez.Strings.FIT_Field_Power_Units) });
  • Dynastream posted this guidance on their forum, but it's still not clear to me that a float should be used for nativeNum power fields.

    www.thisisant.com/.../
  • Dynastream posted this guidance on their forum, but it's still not clear to me that a float should be used for nativeNum power fields.

    www.thisisant.com/.../


    I've seen that but have tried to maintain the correct types where possible. It seemed like maintaining the correct value was the best for things like power, heart rate, etc where no conversion (or shift) was required. The things like speed where there was a conversion (or shift) I put in FLOAT for my values since the guidance seems to suggest that end value after shift was what the developer field should be storing and sites consuming. I understand the goal but I personally would have opted for no variance in type when using nativeNum mapped fields.
  • Garmin Connect can't be used to test the data field because it relies on the FIT contributor definition file from the store when an app is published. All of your FIT file analysis for the simulator or side loaded apps will need to happen with Monkey Graph or the FIT to CSV tool from the FIT SDK. How are you determining that no data is in the file?

    Thank you! I just stumbled on this post - would have saved me a decent amount of time if this was called out in the docs! https://developer.garmin.com/connect-iq/programmers-guide/positioning-sensors#fitdeveloperfieldsconnectiq1.3