ANT Forum

We have updated the SDK, and beta-2 is now available at the same link above. It cleans up deprecated and obsolete methods in Java, C++ and C#. It also provides significant speed improvements in the C++ SDK.

Any feedback on the integration of the betas is appreciated.

Thanks,

-Evan      

Evan - 07 April 2016 04:48 PM

We have an exciting announcement, a new FIT Beta SDK!

This Beta SDK contains a new FIT feature that allows developers to create custom data that is self-describing. The development of this new feature required a breaking change in the FIT SDK so we incremented the FIT Protocol version to 2.0. In order to integrate the SDK, just follow your normal upgrade path for any other FIT update. If you wish to decode the new custom data then follow the code examples provided in all languages, if you do not wish to decode the custom data it is still strongly recommended to update, as FIT 1.0 decoders cannot decode FIT 2.0 files.

The FIT Protocol document has been updated to describe the new feature, and there are examples of how to encode and decode using the new feature for all languages.

The new SDK still allows developers to write 1.0 compliant FIT files as long as the developer is not trying to use the new incompatible features. (It is strongly recommended to only write 2.0 files if you are using 2.0 features).

2.0 Features:
new 64-bit types
Developer Data (self-describing fields)

Coming soon:
We also have some C++ speed improvements coming in a beta-2 next week, stay tuned.

See here: https://www.thisisant.com/resources/fit-sdk-2.0-beta

How are you
I'm iOS developer.
I use Fit SDK.
But always error
Do you have sample code in iOS? Please      

Hello,

I previously stated:
"The FITSDK includes a Mac Static library which you should be able to use directly in your iOS sample code. It will be no different than including any other C++ library."

This is incorrect, I double checked and thought we were building the library as universal for arm64 and i386/x86_64 this is not true. The current mac library will only work on OS X. We will investigate the work required to make the .a library universal to work on iOS and Mac.

In the meantime you can use the C-sdk for basic decoding.

-Evan      

Which feature will have the new version, in addition to the already announced?

Could a FIT file be more fault-tolerant?
There are many questions about corrupt FIT-files in other forums. Why? What are the causes for the error? The user or broken hardware or bad firmware or bad accessory sensors? I don't know.
But I know: The reading of a corrupt file is very problematic (see thread “Boston Marathon FIT file corrupt”).

A fault-tolerant FIT profile - that would be a good feature for version 2!
The memory capacity of the sport computer is constantly increasing.
Therefore, a signature at the beginning of each record would be conceivable.
("Hi, I am the beginning of the new record.") eg: F99FF99F
Or another solution!

If I'm wrong with my thoughts and the fault tolerance of the FIT profile is already now well enough, then I wonder why there are no simple freely available apps to easily repair corrupt FIT files. Even the website of the well known global player accepts no corrupt FIT files.

{English is not my native language}
     

edge-python - 22 April 2016 03:56 PM

Which feature will have the new version, in addition to the already announced?

And yet another consideration:

In FIT PROTOCOL 1 is defined: LOCAL MESSAGE TYPE value 0 – 15
In the NORMAL HEADER, the bits 0 - 3 are used for the value.

Why the limitation to 16 messages? Not enough memory? Was there no more than 16 messages at the beginning?

FIT PROTOCOL 1 allows: Local Message Types can be redefined within a single FIT file.
And that is the problem, in my view!

Here's my feature request: Increase the value range for LOCAL MESSAGE TYPE.

How could this be achieved?
In PROTOCOL 1 bit 4 and 5 of the record header defined as reserved. For what? You could use the reserve for the LOCAL MESSAGE TYPE.

minimum: bit 0 - 4: LOCAL MESSAGE TYPE value 0 - 31
ideal: bit 0 - 5: LOCAL MESSAGE TYPE value 0 – 63

I see a great advantage when messages are no longer overwritten.

(I know: COMPRESSED TIMESTAMP HEADER uses its bit 5 – 6 for serial number of the LOCAL MESSAGE
There is a special case: LOCAL MESSAGE TYPE value 0 – 3
But: Is COMPRESSED TIMESTAMP still used today?)

If all this is not enough, because more and more gimmicks must provide data, then enlarge the header from 1 byte to 2 byte?!
(Then would also be possible: COMPRESSED TIMESTAMP -> LOCAL MESSAGE TYPE value 0 – 63)

A new version will have a future!


P.S.:
I remind you of my old thread: Sequence Reference Field and Dynamic Field https://www.thisisant.com/forum/viewthread/4619/

It makes no sense that dynamic fields may be stored before the reference field.

It should be defined in FIT PROFILE 2:
Sequence to store:
1. reference field
2. dynamic field
     

edge-python - 22 April 2016 03:56 PM

Which feature will have the new version, in addition to the already announced?

Could a FIT file be more fault-tolerant?
There are many questions about corrupt FIT-files in other forums. Why? What are the causes for the error? The user or broken hardware or bad firmware or bad accessory sensors? I don't know.
But I know: The reading of a corrupt file is very problematic (see thread “Boston Marathon FIT file corrupt”).

A fault-tolerant FIT profile - that would be a good feature for version 2!
The memory capacity of the sport computer is constantly increasing.
Therefore, a signature at the beginning of each record would be conceivable.
("Hi, I am the beginning of the new record.") eg: F99FF99F
Or another solution!

If I'm wrong with my thoughts and the fault tolerance of the FIT profile is already now well enough, then I wonder why there are no simple freely available apps to easily repair corrupt FIT files. Even the website of the well known global player accepts no corrupt FIT files.

{English is not my native language}

Thanks for your input on the above. Currently the big thing and the reason we had to update to FIT 2.0 was the developer-defined custom fields. This required a fundamental change to how the decoders worked and warranted the need to increment the version number.

In terms of corrupt FIT files, the SDK provides mechanisms for checking if the File is valid or not. If it isn't valid don't expect that you will be able to successfully decode the entire file. Most of the reasons we see bad files is either due to corruption (perhaps dying batteries mid-activity), or firmware is logging it incorrectly in the first place. If you look at the C-SDK (which most devices probably use to encode FIT files) you will see it is very simple compared to the rest, and really just provides structures for messages and defines for fields.

There are two checksums in each FIT file (header checksum and file checksum). This was a good use of space as it doesn't take up too many bytes and gives us some confidence that the file is good. If a device logs bytes (even if they are not valid) they could still presumably log a valid checksum (so that is a downside).

I am hesitant to introduce a formal signature (as suggested above) before each message as it is wasteful of space (FIT is supposed to be tiny), and although memory is becoming more available it may limit the use of FIT in use cases where FIT is perhaps the best way to log messages (low-cost sensors, etc.).

I hope that helps answer some of your questions.

-Evan      

edge-python - 24 April 2016 05:22 AM

edge-python - 22 April 2016 03:56 PM

Which feature will have the new version, in addition to the already announced?

And yet another consideration:

In FIT PROTOCOL 1 is defined: LOCAL MESSAGE TYPE value 0 – 15
In the NORMAL HEADER, the bits 0 - 3 are used for the value.

Why the limitation to 16 messages? Not enough memory? Was there no more than 16 messages at the beginning?

FIT PROTOCOL 1 allows: Local Message Types can be redefined within a single FIT file.
And that is the problem, in my view!

Here's my feature request: Increase the value range for LOCAL MESSAGE TYPE.

How could this be achieved?
In PROTOCOL 1 bit 4 and 5 of the record header defined as reserved. For what? You could use the reserve for the LOCAL MESSAGE TYPE.

minimum: bit 0 - 4: LOCAL MESSAGE TYPE value 0 - 31
ideal: bit 0 - 5: LOCAL MESSAGE TYPE value 0 – 63

I see a great advantage when messages are no longer overwritten.

(I know: COMPRESSED TIMESTAMP HEADER uses its bit 5 – 6 for serial number of the LOCAL MESSAGE
There is a special case: LOCAL MESSAGE TYPE value 0 – 3
But: Is COMPRESSED TIMESTAMP still used today?)

If all this is not enough, because more and more gimmicks must provide data, then enlarge the header from 1 byte to 2 byte?!
(Then would also be possible: COMPRESSED TIMESTAMP -> LOCAL MESSAGE TYPE value 0 – 63)

A new version will have a future!


P.S.:
I remind you of my old thread: Sequence Reference Field and Dynamic Field https://www.thisisant.com/forum/viewthread/4619/

It makes no sense that dynamic fields may be stored before the reference field.

It should be defined in FIT PROFILE 2:
Sequence to store:
1. reference field
2. dynamic field

Unfortunately if you look at the latest documentation in the betas we have made use of the bit 5 for Normal timestamps to indicate that Developer Data is used (so this is not available). This is another fundamental breaking change (would likely have to be done in a future major revision).

Compressed timestamp is also still used by a number of smaller low-power devices with less space than big bike computers, etc.

-Evan      

We have updated the FITSDK to beta 3 which has performance fixes for the C# SDK.

Please continue to let us know if you have any issues.

Thanks,

-Evan      

Evan - 25 April 2016 03:55 PM

Please continue to let us know if you have any issues.
-Evan

Thanks for your answer.

I have read: D00001275 Flexible & Interoperable Data Transfer (FIT) Protocol Rev 1.9

Please see in my File Attachment. Perhaps that might be a little adjusted?

Thank you

UPDATE 29.04.2016
Change Attachment      

UPDATE 29.04.2016      

edge-python - 27 April 2016 11:04 AM

I have read: D00001275 Flexible & Interoperable Data Transfer (FIT) Protocol Rev 1.9
Please see in my File Attachment. Perhaps that might be a little adjusted?

Here is another note.
I have read the SDK example: DeveloperData.fit

In Record 8, 9, 10 the Dev_Data_Flag is set, but not in the example FIT Profile 1.9 Page 25.

Thank you

UPDATE 30.04.2016
Change Attachment      

The FIT 2.0 SDK beta period is now closed and the official release is available on our downloads page.

Please feel free to post any questions relating to the SDK on our developer forum.

Thank you for your feedback and comments.