• Replies 14 replies
  • Subscribers 19 subscribers
  • Views 822 views
  • Users 0 members are here
Options
Related

FIT WRITE Solution: No Gaps for Invalid Data

DaveBrillhart

Discussed in another thread is the unfortunate issue in which we can't generate a GAP in line graphs for our FIT User Data... for data that is invalid or unavailable. I have a solution that works for me. I have a metric to display Heart Rate Stress. This is relative to nominal HR values for a given sustained and steady power (watt) level. I won't go into the math and research. The point is, the metric can be from about -10 to +20 or so depending on your stress, temp, hydration level, etc. A value of ZERO means your HR matches the model or expected.

But if your power isn't steady or one of several other criteria, I can't generate a meaningful stress value. I wait until conditions are right to generate a data point. Setting it to ZERO is misleading...

So what I now do it oscillate from -0.5 to +0.5 when I'm in an invalid condition state. The graph produces a thicker bar around ZERO which means: "no valid data" during this timeframe. In my case this was a MTB ride and there were times my power level was surging and therefore my HR wasn't steady, and any stress value would be unreliable, so those are times I dropped into the oscilation mode. Also my HR Stress was in the + range because it was hot out today (over 80F) and I wasn't drinking enough. Often my HR Stress starts out in the negative range.

  • in reply to flowstate

    I don't deny being passive aggressive sometimes, but it wasn't my intention this time. Maybe I should've wasted a bit more time and post a separate topic about this, but since we don't have the forum about forums anyways I didn't want to waste even more time, so I edited the finally finished comment and added the 2 markers to indicate where was the problem in order to show it to Brandon.

    I agree and I also thought about the disadvantage of having to change the type of the fit field i.e from uint8 to sint16.

    The post about the invalid values for each type is indeed useful, maybe for the 2030 devs you could also post it where it was actually asked for:  FIT Contributor Best Practice 

    However knowing the value representing invalid data doesn't solve the problem I was writing about: the way it is displayed in Garmin Connect (arguably the place where 99.9% of the users of CIQ apps will look at the graps). To that problem DaveBrillhart uses the -0.5, +0.5 "wide line", which itself is problematic because it needs the type to be changed to float which is 32 bits.

  • in reply to flocsy🤠
    flocsy🤠 said:
    The post about the invalid values for each type is indeed useful, maybe for the 2030 devs you could also post it where it was actually asked for:  FIT Contributor Best Practice 

    Invalid values for FIT writes was literally mentioned twice in this thread:

    - once by the OP (DaveBrillhart)

    - once by you

    And it's literally related to the topic of this thread (how to write FIT data with "gaps"). Both you and DaveBrillhart mentioned writing invalid values to try to accomplish this, without actually explaining where those invalid values come from.

    I simply provided the context of what these values are, for every FIT data type. Might be useful for someone who is reading this thread and wants to write invalid values themselves.

    It's far less ridiculous than resurrecting a thread which was last active in 2020 to answer that question directly.

    Will you also post the same reply every single thread from 2015 to 2026 which refers to gaps in FIT data?

    flocsy🤠 said:
    However knowing the value representing invalid data doesn't solve the problem I was writing about

    I didn't say it solves your problem -- I added the context for other readers, not for you.

  • in reply to flowstate

    Gave it a naive shot, but unfortunately it doesn't work, can't create an UINT16Z type field, though it would be useful for some data:

    _stepsPerHourField = session.createField("stepsPerHour", 4, 11 as
    FitContributor.DataType /*UINT16Z*/, { :mesgType => FitContributor.MESG_TYPE_RECORD, :units => "step/h" });
  • in reply to flowstate

    Ah, so for you it's ok to add comments for future devs to see it but for others it's not ok. Interestingly you haven't comment on the fact that this thread is also from 3 years ago. Where is the threshold? Up to how many years old can a thread be for me or you to be able to respond, and from which age you deem it to be too old?