Tech FAQ

It was intended as a demo app only and was not being maintained in parallel with the Java CSVTool.  It was removed from the SDK package as of version 6.00 to avoid confusion from differing behaviour from the Java tool.  The C++ encode and decode demos remain unchanged.  Contact support if you need access to this demo.

Previously the CSVTool automatically produced specialized output when converting FIT files containing lap, session or record messages such as activity files.  This output was not flexible and has been replaced with a more general filter feature allowing users to generate .csv files containing arbitrary combinations of messages found in the binary source file.  If the previous behaviour is still desired, batch files have been provided with the CSVTool (FitToCSV-lap.bat, FitToCSV-record.bat and FitToCSV-session.bat) that may be used to generate similar output.  

Timestamp fields are deliberately defined as UTC time so that they may be conveniently displayed in the local time if so desired.  In some instances it is useful to know the UTC offset when the file was generated (possibly different from when it is decoded).  This can be accomplished by logging a single message containing both a local_timestamp and a timestamp field.  This will establish the UTC offset of the file.  Presently these fields are predefined for activity and monitoring messages.

Presently C, C++ and Java versions of the SDK are supported.  C# will be publicly available soon.  Demo apps for Encode and Decode are provided as a starting point for using the SDK.  Sample .FIT files and a Fit  CSV conversion tool are also provided.

Yes, although new versions may define new information, the FIT format is self describing.  Existing FIT compliant decoders will be able to decode future data.

Yes, all required messages and fields must be included in your implementation to be compliant.  Please refer to the Fit File Types Document  for further details on required and optional messages and fields.

The SDK will interpret data files using the endianness defined in the file header.  Data is then automatically converted to the endianness of the decoding runtime system.

By choosing to include the header CRC it is possible to calculate the file CRC as data is stored to the FIT file.  At the end, when the data size is known it is possible to insert this value into the header and recompute the header CRC only resulting in a correctly formatted file.  If the header CRC is not used it is necessary to compute the CRC of the entire file and update the footer CRC.  For larger files this could be computationally significant.

FIT is a compact binary format designed for storing and sharing data from sport, fitness and health  devices.  Many useful standard formats are provided or it may be customized for a specific application.   Even though it is customizable it remains highly interoperable, FIT data may be interpreted by any other FIT compliant system.