On Save and FIT Write Bug?

For anyone else reading this thread, I think you're referring to DataField.onTimerStop() and onTimerReset().

DaveBrillhart said:

I write a FIT Summary string at the end of an activity in my Data Field.

To be absolutely clear, calling FitContributor.Field.setData() sets the next value to be written, it doesn't actually write anything. The key distinction is that it's the firmware which determines when/whether data will be written

developer.garmin.com/.../Field.html

Once a Field is created with the createField() method, you can submit the next Field value with setData(), which will get written to the FIT file at the next opportunity.

DaveBrillhart said:

Anyway, this is at least a simulator bug since it doesn't emulate a real device behavior

I agree it would be nice for the simulator's behavior to match the real device behavior.

DaveBrillhart said:

And/or a H/W bug (it should complete the write following the onReset() interrupt.

Not sure why you would assume this is necessarily a bug. The documentation doesn't say anything about whether the FIT file is writable at this point or not (it would be nice if it did, but it doesn't)
https://developer.garmin.com/connect-iq/api-docs/Toybox/WatchUi/DataField.html#onTimerReset-instance_function

onTimerReset() as Void

Thanks for the detailed response. The SUMMARY string is intended to be an overall summary of the activity, so the intuitive behavior is to write this when the activity is declared OVER, which is when the user hits SAVE. Writing it any other time is not summarizing the activity but rather a point in time prior to the end. STOP is not an indication of the end of the activity. SAVE is, which causes the onTimerReset() to be called.

Surely every time you call the setData for the Summary string, it writes to the FIT file. Why would it not? It doesn't know if that is the last time you intend to write the string you want to be shown in Garmin Connect as the summary data string. So, yes, my desire is just to reduce the writes to the FIT file to the one time I actually want to save an activity summary string when I know the user is ending the activity.

But in this case, I think the STOP button is only used infrequently other than just before a SAVE. So again, I'm ok with all the superfluous FIT writes that don't count.

DaveBrillhart said:

Surely every time you call the setData for the Summary string, it writes to the FIT file. Why would it not?

As I explained above, that's not necessarily the case.

If you call setData() for summary or lap fields every second (as in the MoxyField demo and as in some of my own data field apps), it's surely not writing those fields every second. setData() sets the data to be written, it doesn't write data. It says so right in the documentation. Once again:

developer.garmin.com/.../Field.html

Once a Field is created with the createField() method, you can submit the next Field value with setData(), which will get written to the FIT file at the next opportunity.

If setData() is called before the previous data is written out, the previous value will be lost and replaced by the current data.

For example, if the firmware only decides to write the summary fields when the activity is actually saved, then I could call setData() on a summary field 50,000 times, and only the last value would be written.

Do you see the analogy here between the lap and summary behavior?

- Calling setData() for lap fields at onTimerLap() is too late

- Calling setData() for summary fields at onTimerReset() is too late

In both cases, you have to call setData() *before* the associated event, even if it's counter-intuitive

DaveBrillhart said:

The SUMMARY string is intended to be an overall summary of the activity, so the intuitive behavior is to write this when the activity is declared OVER, which is when the user hits SAVE.

Yes but my point is that I'm not sure what makes you think onTimerReset() is necessarily called *before* the FIT file is finalized, rather than *after*. It's called onTimerReset(), not beforeFitFinalize() or something like that.

DaveBrillhart said:

But in this case, I think the STOP button is only used infrequently other than just before a SAVE. So again, I'm ok with all the superfluous FIT writes that don't count.

Why not just open the FIT file and see if you actually have superfluous writes? I'm curious, so I'm going to do a test.

Thanks!! So say your activity is 1 hour long and you hit STOP at minutes 15, 30, 45, and finally at 60 mins just before you then hit SAVE. I know you aren't privy to the actual firmware... but your findings suggest they store the setData for SESSION writes internally. Each setData string OVERWRITES the prior one. And only on a SAVE action does it finally FLUSH the last setData string to the FIT file. That would make sense I guess to prevent useless FIT writes. I would have allowed onTimerReset() to successfully write that final setData to FIT, but now we know. THANKS AGAIN!

Like I said, it's analogous to lap data. If you try to call setData in onTimerLap(), it's too late, so there's literally no way to set lap data except to call setData() every second, as far as I know.

There's nothing stopping you from testing this stuff in the simulator and on your device, and looking at the resulting FIT data yourself. If I were you I wouldn't just take my word for it, I could be mistaken. That's why I went to trouble of testing this.

DaveBrillhart said:

Each setData string OVERWRITES the prior one. And only on a SAVE action does it finally FLUSH the last setData string to the FIT file.

It's right in the documentation that setData doesn't write anything, but only sets the next value to be written. The documentation also says that calling setData multiple times before the value is written will cause previous (unwritten) values to be lost.

It should be very clear from the documentation that setData() absolutely does not write data every time you call it.

developer.garmin.com/.../Field.html

Once a Field is created with the createField() method, you can submit the next Field value with setData(), which will get written to the FIT file at the next opportunity.

If setData() is called before the previous data is written out, the previous value will be lost and replaced by the current data.

The behavior pertaining to exactly when stuff gets written isn't clear from the documentation, but like I said, the MoxyField sample is pretty clear and it works:

1) It calls setData() for activity fields every second

2) It calls setData() for lap and session fields every second, while the timer is running

Looking at 2), you might infer that there's no other time when it's safe/appropriate to set data for lap and session fields. But even if you don't infer that, it's easy enough to try setting data in onTimerLap() and onTimerReset(), and discover that it doesn't work, as you did.

DaveBrillhart said:

I would have allowed onTimerReset() to successfully write that final setData to FIT,

You can file a bug report / feature request. I doubt they'll change it, and even if they do, it's probably 100% likely that older devices won't be changed in any case.

setData simply caches what you pass until the next time the FW writes that type of data  It itself NEVER causes a write.  Imaging if a device app wanted to set and write to the fit every 75ms.

setData just "sets the data" for the next FW write.

exactly. I would just expect the FW to flush write buffering before closing the FIT file upon a SAVE action (which does trigger the onTimerReset() interrupt). But they don't and that's ok. We have ways around that.

forget about the onTimer* stuff in relation to this.  By the time those are called, the data should already be written of it's the proper type.

DaveBrillhart said:

I would just expect the FW to flush write buffering before closing the FIT file upon a SAVE action (which does trigger the onTimerReset() interrupt).

It's ok for you to expect that, but it's also ok for us to point out that Garmin doesn't give you any reason to expect that at all. Yes, the way it actually works is unintuitive, but if anything, I expect Garmin to be unintuitive.

DaveBrillhart said:

We have ways around that.

It's not really a workaround when everything seems to be working as designed. If you don't agree with that design, that's a different issue.