The FIT SDK defines a set of data storage templates, referred to as FIT messages, that can be used to store information such as sensor data, course points, workout instructions, device settings, etc. These messages and their fields define the structure of the data, and the FIT SDK provides the tools to serialize and deserialize messages to create FIT files.
As designed, the FIT SDK allows for any combination of messages to be written to a FIT file. In practice, different applications of FIT files lead to a natural grouping of messages based on specific purposes. The FIT Profile defines a list of common file types but does not explicitly define which messages are to be used with each file type. The following sections of this guide describes the most common FIT file types, the common messages associated with each type, and best practices across all types.
The file types described in this guide are ordinary FIT files that follow the FIT protocol. FIT files may contain additional messages beyond the minimum or recommended messages described in this guide. Over time, additional messages may be added to the FIT Profile, and additional message fields may be added to existing messages. Always refer to the FIT Profile for the most recent content.
Unless otherwise specified, messages without timestamps are permitted in any order in the file while messages with timestamps must occur in ascending chronological order. Refer to individual file definitions for further details.
All FIT files have the same binary structure which consists of a File Header, Message Definitions, Messages, and a 2-byte CRC. The FIT SDK is responsible for the creation, serialization, and deserialization of the file header, CRC, and message definitions; and resolving native endianness between the file and the client platform. The FIT SDK also handles the serialization and deserialization of messages.
Applications that create FIT files only need to be concerned with creating messages of the appropriate type, populating the message fields with data, and passing the message to the SDK to be serialized.
For applications that read FIT files, the SDK handles deserializing the binary file data and reconstructing messages. The messages are then passed to the client application. In most instances the client application does not need to know how the messages are serialized or deserialized.
More information on the FIT protocol, message definitions, and how messages are serialized and deserialized can be found in the FIT File Protocol section of this guide.
All FIT files must contain a single File Id message. The File Id message identifies the intent of the FIT file through the Type field. The File Id message should be the first message in the file.
| File Id Field | Required | Type | Description |
|---|---|---|---|
| type | Y | file (enum) | File type id |
| manufacturer | Y | manufacturer (enum) | Managed by ANT+. Contact antalliance@thisisant.com for details |
| product | N | UINT16 | Managed by manufacturer |
| product name | N | String | Managed by manufacturer |
| serial number | N | UINT32z | Device serial number, managed by manufacturer. The ‘z’ indicates that the invalid value for the type is 0 and not 0xFFFFFFFF. |
| time created | Y | date_time | File creation time |
| number | N | UINT16 | File identifier |
The FIT protocol defines a list of common file types and the purpose of each type. Each SDK will define the File Id types either with an enum or as a group of constants.
| Type | Name | Description |
|---|---|---|
| 4 | Activity | Records sensor data and events from active sessions |
| 5 | Workout | Describes a structured activity that can be designed on a computer and transferred to a display device to guide a user through the activity |
| 6 | Course | Uses data from an activity to recreate a course |
The complete list of File Types is defined in File enum.