Ticket Created
over 2 years ago

WERETECH-12749

feature-request: enable CIQ apps to indicate no-data/missing-data/incorrect-data in a Fit field.

Native apps have a way to indicate missing/no/invalid data in the FIT data file. For native apps' data GCM and web both are able to display correctly the gaps. For CIQ apps we currently only have the choice to send some data (like 0) that is "incorrectly" rendered on the graphs.

Please add a way for CIQ apps to do the same. Some possible solutions:

- enable Toybox.FitContributor.Field.setData(null) also for non nullable DATA_TYPE_-s.

- add a new parameter to Toybox/WatchUi/DataField.createField to indicate that setData should accept null.

- add a new parameter to Toybox/WatchUi/DataField.createField to indicate what value should be treated as missing/invalid. So for example for HR related data we could set ActivityMonitor.INVALID_HR_SAMPLE as the invalid value and use that to indicate that for a certain period of time we didn't have valid data.

The problem is well documented in https://forums.garmin.com/developer/connect-iq/f/discussion/7509/fitcontributor-field-setdata-should-accept-null-as-a-value/

flocsy🤠
  • over 1 year ago in reply to FlowState

    If anyone will have time to look into the fit files and compare, then here's an idea: maybe the difference is not even in the fit file but the fitcontributor.xml? Maybe if we knew what to put in the xml then it would also display our fit files with gap?

  • over 1 year ago

    No, the website doesn't show the gap, see my screenshot in the last comment.

    You know what is sad? That I'm pretty sure that a few of us, who are commenting and reporting bugs on a weekly basis probably do remember way better about these bug reports than anyone in Garmin :(

  • over 1 year ago

    > I guess it's time we open another 2 bugreports: 1 for GCM and one for the connect web...

    IIRC, the Garmin Connect app and the website handle gaps in native data differently, too. The app connects the gap with a straight line while the website just shows the gap. I think I had a bug report for that, or I mentioned it in another bug report or forum post.

    There's so many bugs and idiosyncrasies that I just lose track.

  • over 1 year ago

    > The ANT standard states that there's 1 unsigned byte, where 0 means: invalid data, 1-255 (including!) are valid HR values. So in theory 255 is a valid HR

    Sure but according to the FIT specification, 255 is not a valid value for a UINT8 field. In this case I would expect to never see 0 or 255 as valid values in a FIT file for HR. If someone actually sees a value of 255 for their HR, I'm sure it wouldn't be a huge deal to record that as 254.

    Oh well, it was nice to fantasize about having a solution to a longstanding bug / limitation.

    Still have to wonder how native apps are able to write "no data". I haven't actually looked into the contents of a FIT file where a native field has gaps, so I have no idea whether it's literally no data for those time periods, or invalid values. (I always assumed it was no data.)

    I'll have to circle back to my original request and ask Garmin to allow us to call setValue(null), which means "when it's time to write the next value, don't write anything."

  • over 1 year ago

    Well, my datafield gets the HR from a chest strap (or anything that sends via ANT) The ANT standard states that there's 1 unsigned byte, where 0 means: invalid data, 1-255 (including!) are valid HR values. So in theory 255 is a valid HR (and what's the chance? I just saw a TED talk last week where someone told her story and she had a heart disease with HR over 290 sometimes...) However I'm willing to sacrifice 255 if that is what makes a gap in the fit graph :)

    I checked it now, and I don't think it really works. (there's no gap). Until now I recorded the HR I got from the strap, so when it disconnected because my partner was too far away I recorded 0. It doesn't create a gap, but it's not bad, because we're talking about a signed int and anyway the real values are much higher.

    Now I tried what happens when I record 0xFF for invalid data, and it's worse because there's no gap and it just connects the before and after points. I disconnected the strap at 0:52 and reconnected it at 1:56.

    web (this looks like it uses some "nice" curve):
    web
    GCM (this connects them with a straight line):

    GCM

    So for signed int (especially for HR) I'll continue to use 0 for invalid.

    I guess it's time we open another 2 bugreports: 1 for GCM and one for the connect web...