FIT WRITE Solution: No Gaps for Invalid Data

I've just wanted to ask about it. So can you confirm that it's impossible to write in fit file NULL value?

I need some time to count metric so from beginning of activity I don't have anything to save so thought I save null.

But what does do system's data field if watch can't read e.g. HR during activity? What to do of in compute info.currentHeartRate is null?  

maybe system simple connects two valid points with line, no gap but line

Yes I can confirm. We've tried NULLS and we've tried the official INVALID values as defined by the FIT standard. Nothing works.

_psx_ said:

But what does do system's data field if watch can't read e.g. HR during activity? What to do of in compute info.currentHeartRate is null?  

maybe system simple connects two valid points with line, no gap but line

I think I've seen gaps from native data fields in the past, but it was a long time ago. I also never had a chance to look at what the data actually was in the FIT file. (i.e. Was it "no data" / gaps, or was it invalid values, or maybe something else?)

_psx_ said:

I need some time to count metric so from beginning of activity I don't have anything to save so thought I save null.

If your gap is at the start of the activity, you can simply avoid calling FitContributor.setData() until you have data to write. This is an exception to the problem because of course if you never called setData() even once, the system has no idea what you want to write, so it won't write anything (afaik).

If I recall correctly, I tried this in the past, and it works, although the specifics of how the "gap" is rendered may vary depending on whether you look at the activity in the Connect app or on the website.

This thread is more than 4 years old >_<

https://forums.garmin.com/developer/connect-iq/f/discussion/7509/fitcontributor-field-setdata-should-accept-null-as-a-value/1435857

Now consider the case of a Connect IQ field recording the exact same data.

If there's no HR data available at beginning of the run and the field hasn't called setData yet, no problem. The records for the 3rd-party field won't be present for that time period. But the first time the app calls setData, it's obligated to keep doing so every second, even if it has no data. If you don't call setData, the device just records the last value you set. And if you call setData with null, it crashes.

So I resign, I don't want to explain users why data in graph are bad especially the answer can be only one (again) bug in ciq/hw, platform limit etc.

I tested this now: from the average user's point of view using setData(INVALID_VALUE) - where INVALID_VALUE depends on the field's type, but it's something like 0xFF or 0xFFFF, etc) does the following:

- visually: line that connects the last valid datapoint with the next valid datapoint after the invalid values.

- when advanced user looks at the graph in Garmin Connect and moves the cursor over the graph then they can see that there's no data every second [opening parenthesis] even though in other places of the graph there is, even when the value doesn't change for multiple seconds [closing parenthesis]

In my app/activity I use every second recording, and in my code I call setData every second. So where the value is valid I see a data point on the graph. Even when I set it to the same value for 60 seconds, you can see (but only when moving the cursor) that there IS a value for every second.

However when I call setData(0xFFFF) (got a DATA_TYPE_UINT16 field) every seconds for 60 seconds, then there's a (non visual) 60 second gap. The line looks like it has a value for every second, but when moving left-right it jumps between the two valid datapoints.

So I'm thinking that maybe I'll do something like: detect when the data becomes invalid, set a valid (from the fit data type's point of view) value that makes no sense for the graph (i.e negative HR) for the 1st second, and then the INVALID_VALUE for the rest of the time it keeps being invalid. Of course the same thing will have to be done every time the data switches from valid to invalid.

Brandon.ConnectIQ Since there's no more forum about the forum I'll spam here. In the above comment of mine I struggled posting the text. At the end I edited and added it sentence by sentence, until it turned out that I can't have parenthesises in the 3rd sentence, where I indicated with: [opening parenthesis] and [closing parenthesis]. In later sentences it allowed me to use them.

I have no idea what causes this, but this is so frustrating. Maybe I'll start to invest my time in making a new developer forum (maybe together with a few other developers) instead of wasting my time in refactoring comments or posting code as images (unless the forum blocks the image as well of course) or just posting code as unreadable text...

flocsy🤠 said:

that makes no sense for the graph (i.e negative HR)

I see a few practical problems with writing a literal negative HR value as some sort of "marker" to indicate when bad data starts:

- it could mess up the graph scale

- it might confuse users

- it might change the FIT data type that you use and waste space. e.g. To record HR, you could normally use a UINT8, I think, but if negative values are required, then you'd have to use INT16.

- it could cause issues if people want to do their own analysis of the data that is written to the FIT file (e.g. take the average of the data)

Ofc all of these things could apply (and even more so) if you wrote 0 for all invalid data (which I think some 3rd party apps do).

But maybe the compromise is to write 0 for the first invalid data point and the invalid value for the rest. I think everyone knows that it's impossible for their heart rate to be literally 0.

flocsy🤠 said:

[opening parenthesis] even though in other places of the graph there is, even when the value doesn't change for multiple seconds [closing parenthesis]

I know you think this passive-aggressive way of circumventing forum bugs is meant to annoy Garmin employees and prove a point, but it really only makes it harder for the actual audience of your content.

You realize you could have easily typed something like this and nobody would've cared:

"[even though in other places of the graph there is, even when the value doesn't change for multiple seconds]"

Garmin isn't gonna be motivated to fix forum issues because you made it harder for other people to read your posts.

Also, for context, the invalid values for various FIT data types are documented here:

https://developer.garmin.com/fit/protocol/ 

Search "invalid values".

(click to enlarge)