easy-fit uses the following code to convert FIT time to unix epoch time:

case 'date_time': return new Date((data * 1000) + 631062000000);

When we read our FIT files, this turns out to be one hour wrong.

The constant 631065600000, as used in the following library, does work: https://github.com/dgaff/fitsdk/blob/master/java/com/garmin/fit/LocalDateTime.java

Hi there,

I get this strange data when importing a .fit file from movescount. Take a look:

As you can see all the points that do have a lat long have out of space values.

Do you have any clue for this ?

When reading a FIT file from a cycling ride without Powermeter connected, all powerdata show 65535 as value.

This includes avg_power, max_power and all other related values such as training_stress_score (which is 6553.5 in this case).

Thanks for having a look.

How can i use it without node. I would like to use it in an angularjs application.
So require didn t exists. How to transpil it ?
Thanks

Is it possible to modify easy-fit to be used client side (in the browser)?

Update: This has been discussed (and solved) in one of the closed issues.

The left_right balance is incorrect it seems.

in the fit.js file it states
left_right_balance: {
0: 0,
127: 'mask',
128: 'right'
},
left_right_balance_100: {
0: 0,
16383: 'mask',
32768: 'right'
},

I'm getting values of 178 for left_right and 37885 for left_right_balance_100. On top of this, the left right balance should be a balance percentage not a value "right" or "mask"

The offset value for altitudes should be -500, it appears to be configured as +500.

When encoding altitude fit will use
uint16 = 5 * (altM + 500)

So decoding should use
altM = uint16 / 5 - 500 // offset should be -500

avg_stance_time_percent seems to have incorrect value.
supposed to denote AVG Ground Contact Time Balance but seems to be off for some reason

Any chance of a version release to the registry that has the latest fit.js file? The mileage conversion in npm is way off but it's been fixed in source, just not pushed to the registry.

Can our converted json object be converted again to a valid fit file?

Hi there,

I get "Incorrect header size" when passing blob from Filereader. What is the expected input?

Parsing fails when record contains developer defined fields which are used by third party app developers and new in FIT 2.0 (?) spec.

The parsing itself does not crash but data after such a message becomes jibberish.

I created a fork with a fix, tests are passing but still early in the process, will create a PR to main repo once stable.

If anyone wants to have a look, here it is:

FrostDigital#1

👋Hi! Thanks so much for this awesome library. It makes working with .FIT files a breeze. ✨

I noticed that records fields have an elapsed_time field that tells us how many seconds have passed since the start of the activity. I think it would be great if records also included a timer_time field that tells us the time on the device when the record happened.

This would be useful because I'll often stop my watch when I stop at a red light, for example, and start it when I begin moving again. Platforms like Garmin Connect and Strava use the time on the device, not the total elapsed time including the time the device was stopped, to calculate splits, and I'd like to do the same.

Happy to take a stab at this one! Just wanted to open an issue in case anyone had already started thinking about this or working on it.

Thanks again! ❤️

Is it possible to load the .fit file clientside? as an array buffer or something like that.

http://www.javascripture.com/FileReader

I've tried to parse a fit file from a Wahoo GPS, but I always get 2 records in the resulting json while the file itself (verified in Basecamp) have thousands of track points in it.

Any idea what's wrong here?
I have no issues with the parsing of other fit files (from Garmin units), all of these are ok.
Wahoo.zip

Sorry - this was based on the Assumption that Suunto follows the API standard which it does not. According to the Standard 26 is indeed hang_gliding - even if that might only be the case because someone at Garmin messed up.

Original text:
Hi, based on a .fit file from Suunto 26 should be mapped to paragliding instead of hang_gliding.

For people not familiar with the sports:

• paragliding https://en.wikipedia.org/wiki/Paragliding
• hang gliding https://en.wikipedia.org/wiki/Hang_gliding

I'm getting some unusual data for locations and activity type after parsing attached FIT file (Generated by Garmin). Below are the activity and location records I get after parsing to JSON:

sport:
{ name: 67,
sport: 'generic',
sub_sport: 'bike_to_run_transition' },
zones_target: { max_heart_rate: 195, hr_calc_type: 'percent_max_hr' },
sessions: [],
laps: [],
records:
[ { timestamp: '2017-12-10T14:02:05.000Z',
position_lat: 49.8264604434371,
position_long: 262.8936153743416,
distance: 21.78,
altitude: 1231.6,
speed: 3.322,
heart_rate: 91,
cadence: 95,
fractional_cadence: 0,
elapsed_time: 0 },
{ timestamp: '1990-08-15T13:16:08.000Z',
position_lat: 350.1582593098283,
position_long: 98.81422287784517,
distance: 2392564.2,
altitude: 727,
speed: 13.456,
heart_rate: 109,
cadence: 35,
fractional_cadence: 196 } ],

I confirmed this activity is a genuine running activity and there are valid locations by uploading it back to Garmin.

2374117972.zip

I think this should be ..

force: options.force === false ? false : true

Hello,

I have realised that

activity -> sessions -> laps -> records -> [position_lat, position_long]

the coordinates are incorrect. I don't know the exact conversion, but at least negative values are represented as positive, and it needs some other conversion to place the record in the proper point.

Hi,
currently, the NPM offers version 0.0.7

However, this commit is not included when using 0.0.7

a4d6368

What am I missing ?