Welcome Guest,Register Now
Log In

ANT Forum

Welcome guest, please Login or Register

   

SDK 20.27.00 Released

RankRankRank

Total Posts: 68

Joined 0

PM

We have released a new version of the FIT SDK.

It can be accessed via our downloads page.

Release notes are available here.
     
Rank

Total Posts: 1

Joined 2016-12-22

PM

Hi. Is it possible to upload java sdk (without examples of course) to maven central?      
Rank

Total Posts: 4

Joined 2014-11-04

PM

May I ask why GetxxxSpeed functions of various Mesg classes return actually integer values instead of float in C# code?
I noticed this in SessionMesg.GetAvgSpeed and GetMaxSpeed, RecordMesg.GetSpeed. This provides 1 m/s resolution of speed only.

Have upgraded from v15.1, and a couple of my tests failed.

Another issue I'm experiencing is simply recoding an activity using Encode and Decode produces corrupt file. Simply catching messages and message definitions of Decode and write them with Encode. Skipping DeviceInfoMesg messages seems resolve the problem.
I can attach a simple repro code with a sample FIT file.      
RankRankRank

Total Posts: 68

Joined 0

PM

We discovered an issue in our templating code that introduced an issue where the casting in the Mesg helper methods are throwing away the fractional component by casting to the integer type as you have highlighted. The next SDK is planned to be released on April 12th and will include a fix for the issue.

If you could send the corrupt FIT file and the reproduction code that would be helpful.      
Rank

Total Posts: 4

Joined 2014-11-04

PM

Thank you for your reply. Glad to hear it has been fixed. Until release, I simply fixed the methods causing problems for me.

I attach a sample C# project for reproducing the recoding issue. Sample file is included as an embedded resource, so you can just open the project with Visual Studio 2015 and run it.
I'm experiencing this problem with all files from my Garmin Edge 800.      

File Attachments

RankRankRank

Total Posts: 68

Joined 0

PM

Looks like the issue you're running into is with manufacturer specific fields. There is a bug in the SDK Encode logic when there is a compatible Definition in the file, but the SDK encounters a field that it does not recognise.

The fix is fairly simple, I've attached a diff so you can work around the issue you are seeing until we can get the fix included in the next Release.

diff --git a/Dynastream/Fit/Field.cs b/Dynastream/Fit/Field.cs
index 22515f9
..2fad2f3 100644
--- a/Dynastream/Fit/Field.cs
+++ b/Dynastream/Fit/Field.cs
@@ -145,+145,11 @@ namespace Dynastream.Fit
             this
.isAccumulated accumulated;
             
this.profileType profileType;
         
}
+
+        
internal Field(byte numbyte type)
+            : 
this("unknown"numtype1.0d0.0d""falseProfile.Type.NumTypes)
+        
{
+        }
         
#endregion
 
         #region Methods
diff --git a/Dynastream/Fit/Mesg.cs b/Dynastream/Fit/Mesg.cs
index 1b32f42
..0be4526 100644
--- a/Dynastream/Fit/Mesg.cs
+++ b/Dynastream/Fit/Mesg.cs
@@ -392,+392,@@ namespace Dynastream.Fit
                     }
                     
else
                     
{
-                        //Field does not exist in profile, continue to next field
-                        continue;
+                        
field = new Field(fieldDef.NumfieldDef.Type);
                     
}
                 } 


Another option would be to not bridge the Message Definitions, and to let the SDK automate writing the definitions as required.

Thanks!
     

File Attachments

  • diff.txt (File Size: 1KB - Downloads: 665)