Related
Recommended
Ben FIT
Oct 26, 2023

FIT Activity files support two message ordering schemes, “Summary First” and “Summary Last” as documented here https://developer.garmin.com/fit/file-types/activity/ Garmin devices have historically used the Summary Last method, leading many platforms to assume that this is the only method. As a result, some platforms may not properly handle FIT Activity files written in the Summary First method. ​

Please check that your current implementation follows the developer documentation. If it does not account for a “Summary First” method, your platform will be impacted by this change. The resolution for this is described below and should be implemented by December 1st, 2023. Garmin will not execute backfill requests for this data.​

The summary messages represent a time span defined by the Start Time and Total Elapsed Time properties of each message. Whereas the timestamp of each message represents the time it was written to the file. For files using the Summary Last method, the timestamp approximates the end time of the summary message. For files using the Summary First method, the timestamp approximates the file creation time. In either case, the timestamp should not be used to determine the start or end time of the summary message. ​

To properly decode FIT Activity Files created using either the “Summary First” or “Summary Last” method, the End Time for the summary messages should be calculate as: ​

end_time = start_time + total_elasped_time ​

This technique will allow platforms to process FIT Activity files using either message ordering scheme. ​

The attached FIT Activity files were created using the Summary First method and can be used to test your platforms. The activity is representative of a multisport event and includes multiple Session and Lap messages. The included screenshots show the expected GPS tracks for the time span represented by each Session message.


Example files are attached below.

Full Activity

Session 0, Swim.

Session 1, Transition

Session 2, Bike

Session 3, Transition

Session 4, Run

ExampleFiles.zip
Anonymous
  • 10 months ago

    I wonder if there's a reliable way to distinguish the two different variants at the start, before starting to process record messages. The best way I figured out so far is to look at the sequence of messages before the first

    Event: FIT_EVENT_TIMER; Type: FIT_EVENT_TYPE_START

    message. If there was an activity message followed by a bunch of session messages before that event, then the file apparently is in summary first format, otherwise it is processed as it was before.

    Is there a more reliable way to tell?

    Regards

    Herb

  • 11 months ago in reply to gie

    FIT Activity files are written in real-time by devices. The data is not saved to an intermediate format and then exported to a FIT Activity file later on the server. So, there is no configurable option that changes the order that the device writes out the summary messages. If you are not relying on the order that the messages are written to the file, and you are not using the timestamp of the summary messages then you should be able to test with summary first or summary last messages. But let me can check with our QA team to see if they have additional example files that can be shared for testing. 

  • 11 months ago

    wowee! this is going to be interesting. popcorn.gif

  • 12 months ago

    Is there a way to

    - Configure existing Fit files from summary last to summary first?

    - Configure some incoming fit file (before Dec 1st, 2023) to be summary first? (for some user)

    My goal is to test if our new implementation can resolve the summary first well enough

  • over 1 year ago in reply to Frederic

    The zip file with the example file has been updated to include a version of the file written in the summary last method. The five session messages and 7 lap messages are interleaved throughout the file.