ANT Forum

Hi,

I'd like to ask a question about the fit file structure how it should be implemented in our use case:

We have two arrays containing gps location data and other array contains information such as heart rate, power. These two arrays of data have in common the timestamp.

If I wan't to create a fit activity file containing this type of information, would an approach to save first the gps data as records and after that heart rate, power information as records be good? In my tests with Garmin connected showed that the fit file worked just fine (I was able to see the route and heart rate from the posted activity) which was constructed with that approach, but I'd like to know is it right way to make a fit file.

The problem is that the gps location data stored in the first array can be saved depending on user settings and environment - the frequency when its saved can be say every 10 seconds. The heart rate, power information can be saved say every second. If the requirement of constructing the fit file is that the record would contain both arrays rather than record per array item it'd require interpolation of the gps location data - and I'd rather not implement that unless I have to.

Problem is that I used the fit file in Strava upload as well, and it didn't seem to work that well at all - for example the total length and time of the saved trip didn't show up at all, the route wasn't visible either. That said Strava upload accepted the file just fine. Also Javawa RWTool did show the route just fine in the fit file.
     

ARR - 09 April 2014 06:19 AM

Hi,

I'd like to ask a question about the fit file structure how it should be implemented in our use case:

We have two arrays containing gps location data and other array contains information such as heart rate, power. These two arrays of data have in common the timestamp.

If I wan't to create a fit activity file containing this type of information, would an approach to save first the gps data as records and after that heart rate, power information as records be good? In my tests with Garmin connected showed that the fit file worked just fine (I was able to see the route and heart rate from the posted activity) which was constructed with that approach, but I'd like to know is it right way to make a fit file.

The problem is that the gps location data stored in the first array can be saved depending on user settings and environment - the frequency when its saved can be say every 10 seconds. The heart rate, power information can be saved say every second. If the requirement of constructing the fit file is that the record would contain both arrays rather than record per array item it'd require interpolation of the gps location data - and I'd rather not implement that unless I have to.

Problem is that I used the fit file in Strava upload as well, and it didn't seem to work that well at all - for example the total length and time of the saved trip didn't show up at all, the route wasn't visible either. That said Strava upload accepted the file just fine. Also Javawa RWTool did show the route just fine in the fit file.

The specs are not overly precise, so I'd assume that your file structure is "legal". On the other hand, the primary implementation is Garmin's (with one record per time stamp, in increasing time order). So you can be sure that most applications that interpret .FIT files take this as the gold standard. Deviant file structures could cause them to stumble. You might then "complain" that your file structure is legal - but that won't help much.

If your primary concern is that GPS data might be available every 10 seconds, other data every second, the solution is simple: no record message has to contain ALL properties. So you can have 9 subsequent records without GPS data and a 10th one with GPS data. Perfectly legal and frequently used by e.g. Garmin devices.

Cheers,
OMB      

old_man_biking - 10 April 2014 05:50 AM

ARR - 09 April 2014 06:19 AM

Hi,

I'd like to ask a question about the fit file structure how it should be implemented in our use case:

We have two arrays containing gps location data and other array contains information such as heart rate, power. These two arrays of data have in common the timestamp.

If I wan't to create a fit activity file containing this type of information, would an approach to save first the gps data as records and after that heart rate, power information as records be good? In my tests with Garmin connected showed that the fit file worked just fine (I was able to see the route and heart rate from the posted activity) which was constructed with that approach, but I'd like to know is it right way to make a fit file.

The problem is that the gps location data stored in the first array can be saved depending on user settings and environment - the frequency when its saved can be say every 10 seconds. The heart rate, power information can be saved say every second. If the requirement of constructing the fit file is that the record would contain both arrays rather than record per array item it'd require interpolation of the gps location data - and I'd rather not implement that unless I have to.

Problem is that I used the fit file in Strava upload as well, and it didn't seem to work that well at all - for example the total length and time of the saved trip didn't show up at all, the route wasn't visible either. That said Strava upload accepted the file just fine. Also Javawa RWTool did show the route just fine in the fit file.

The specs are not overly precise, so I'd assume that your file structure is "legal". On the other hand, the primary implementation is Garmin's (with one record per time stamp, in increasing time order). So you can be sure that most applications that interpret .FIT files take this as the gold standard. Deviant file structures could cause them to stumble. You might then "complain" that your file structure is legal - but that won't help much.

If your primary concern is that GPS data might be available every 10 seconds, other data every second, the solution is simple: no record message has to contain ALL properties. So you can have 9 subsequent records without GPS data and a 10th one with GPS data. Perfectly legal and frequently used by e.g. Garmin devices.

Cheers,
OMB

Thanks for the reply. Ok, based on your comment I'll check my code related to the creation of the records. Instead of writing first gps records to the encoder (encoder.Write(...)) and after that writing records containing heart rate data (etc) to the encoder, do you think I should sort those arrays first in chronological order prior writing them to the encoder? If thats not done could it affect the fit activity file interpreter (whatever service or program I'm trying to offer my fit file) if thats not done?

PS I did try today the garmin connect upload feature, and I wasn't able to make it accept even my gpx files. And the aforementioned upload did worked fine yesterday. Makes me think if they're working on their upload feature currently.
     

Garmin Connect has been undergoing frequent changes in the past weeks. So I'd expect surprises from time to time.

Regarding record sorting: yes, I'd suggest that you sort your data by time stamp first and then output to .FIT file in ascending order.
I'm not sure if this is mandatory according to the spec, but for sure you're on the safe side and reduce the risk of .FIT parsing apps failing on your files.

Cheers,
OMB      

-Record, event and hrv must be in chronological order for Activity files so you will need to sort. OMB is correct you don't need to have the same fields for every record message. You could define two forms for record, (say local1=HRM/Pwr only and local2=HRM/Pwr/Location) and log them as they are available OR redefine record within the file and send a new definition messages each time you add or remove fields.

     

Let me recap, the fit file follows certain order of information how its presented - first comes records, then events and hrvs? but not necessarily if some of those information(s) are not available? and the chronological sorting based on timestamp is meant only for say records only - not mixing the ordering based on timestamp between records, events and hrv, they have to be in defined order no matter what they're timestamp is. Sorting is only related on the entity (for example records) itself?      

May I suggest that you simply read the spec. document "D00001309 FIT File Types Description Rev 1.5.pdf", which is part of the FIT SDK.
Section 9.1.1 explains the activity file.
I'm sure this answers 9x% of your questions. We can try and answer any remaining questions then.

Cheers,
OMB