FIT Session Writes

DaveBrillhart said:

It seems (unless I'm doing something wrong), that a Data Field can only write a single FIT_SESSION instance. If I try to set up two different "createField" instances with MESG_TYPE_SESSION, I get an error. So, each Data Field can only write a single line (max, 32 bytes) that shows up in the Garmin Connect activity. Right?

I don't think that's true.

The Moxy field sample in the Connect IQ SDK has two MESG_TYPE_SESSION fields and I have more than one for a couple of my apps.

https://github.com/bsx-opensource/insight-app/blob/master/BSXField/source/MO2FitContributions.mc

Are you trying to write more than 32 bytes total for MESG_TYPE_SESSION?

developer.garmin.com/.../Session.html

"Data fields are limited to 32 bytes per message "

Are you using a unique fieldID for each field?

Are you calling createField() in DataField.initialize()? createField() has to be called as early as possible. You can't call it after the activity has started, for example.

What device are you trying this with?

DaveBrillhart said:

I write this SESSION string at the onTimerStop() interrupt (using the FIT setData call), since there doesn't appear to be an onSave() trigger.

But, I can stop/resume an activity multiple times. So, I could write the SESSION data several times, at every STOP event. Does that write the SESSION string to the FIT file each time? Or does it save this SESSION string somehow and only actually write it if/when the Activity is SAVED? Meaning only the final SESSION setData string is actually saved?

setData() doesn't write data when you call it. It's admittedly a little counter-intuitive, but I think that's why it's called setData() and not writeData().

https://developer.garmin.com/connect-iq/api-docs/Toybox/FitContributor/Field.html#setData-instance_function

"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."

I think the situation with MESG_TYPE_SESSION is the same as the situation with MESG_TYPE_LAP. You have to call setData() *before* the lap or end of session, and the data gets written at the appropriate time.

For example, see the Moxy field example linked above -- you'll note that setData() is called for the lap and session fields once per second, although they'll surely be written much less frequently.

That's how I use setData(), too. I just call it whenever data is available, regardless of whether the field is a record, lap or session type.

---

The big downside with this implementation (IMO) is that it's not possible to write nothing (for a record) once you've written the first value, because there will always be a next value provided by the last setData() call, and setData(null) is not allowed. This means that if you're writing HR or power data, for example, there's no good way to model the fact that you've lost connection with the sensor and that you have no data. You can only do one of two incorrect things, which is to either write 0 or the last known good value. (I guess you could also write some way-too-large value that's obviously incorrect, but that would be confusing.)

Besides, Garmin Connect Web and the Garmin Connect app have inconsistent behavior when it comes to gaps in native graph data (e.g. when sensor data is missing), so this use case is handled incorrectly in more than one way.