In activity i16578330 many of the Coros length records “overlap” in time i.e. the start_time of length n+1 is before the end time (timestamp) of the previous length. And the total_timer_time or total_elapsed_time for each length added to the start_time is often past the start_time of the next length.
Also there are 23 duplicate records (for heart rate, cadence etc.) from approx 4915. Or maybe they aren’t dups and the time went backwards around about then.
I am not sure what I can do about this. The length data doesn’t look reliable and thats how Intervals.icu generates the activity streams.
Odd. The only discrepancies in actual length data I noticed myself is when we do leg drills with no or very little arm movement (evident when lengths are not a multiple of 50 or when the time is excessive, e.g. 3+ minutes for 50m). That does not seem to affect the overall pace average as much though on the Coros app or Evolabs. Too bad. Is this a Coros-specific thing or do other brands have this too?
I haven’t had any reports of pace being off for Garmin swims so I think those are ok. The overall average pace is available in the fit file. I could use that but then if you do any cropping etc. it will be re-computed from the bad streams data. I also suspect average pace for the intervals derived from laps is likely also too high.
I don’t really do any alterations to my data since I track my training mostly on trends and feel, and make sure I do the right variety and all that, so don’t need high accuracy. It’s just that sTSS is way off now on intervals while TP shows the same as Coros.
Simply using the average pace from Coros would probably work for me. Maybe TP is already doing that too, but I can’t see the laps on there since that’s a premium feature.
Keeping semi-accurate time in pace zones would be nice to have but may be similarly affected.
Actually, i noticed the swim pace being off for my garmin FR 245 swims.
Connect file: Garmin Connect
main set laps as being clocked and shown in Garmin Connect:
I am going to look at this some more on the weekend. I might be able to “stack” the lengths one after the other to keep the recorded durations instead of adjusting the start time to avoid starting during the previous length.
Bringing this one back to life again after reading this. Tried uploading the .fit file directly, but still getting discrepancies between Strava / HealthFit and intervals.icu. A bit more context:
This workout was recorded from my Apple Watch Ultra.
Data was extracted using HealthFit and synced to Strava and Intervals.icu.
I tried deleting the strava and intervals.icu activity entry and uploaded the fit file directly. Same Intervals.icu result.
@david, I’m noticing that ICU and Garmin swim interval times and paces don’t match. I discovered this when doing a TT test (500m WU, 5x 100m tempo, 1000m TT, CD)
@david Was hoping to bring this topic back to life - I’m experiecing the same problem using the native Apple watch workout feature to record a swim, then importing into healthfit before exporting to intervals.icu. Did you find a ‘fix’?
@Errolleesw Did you find a work around for the healthfit / intervals.icu set discrepancies?
I’ve also noticed that total distance is correct - 1.6km, however sum of intervals is off?
Hi David, any progress on this matter. The average pace is still off and I just noticed a weird thing in the Pace graph. The laps info shows a 36seconds duration, but the pace/100mts shows a 1:25 time, which is 13seconds off.
Sorry to bring up a zombie thread, but this was the first link when searching.
My swims have always been 2-3 seconds longer in intervals than other platforms.
After looking into the contents of a .fit file, I think I understand where the Garmin vs Intervals.icu discrepancies are coming from.
It appears that intervals is using the “start time” field from the lengths portion of the .fit file which has a resolution of 1s. It then creates a time based data stream at 1hz frequency to locate intervals in. This results rounding errors that that add up to 1-2 seconds. Then, for whatever reason, the the interval finding algorithm seems to add 1 second on top of that (possibly it includes the preceding or trailing data point where speed is 0).
Garmin shows lap data using the sum of the individual length “total elapsed timed” field, which are stored at 0.001s resolution.
Below is 1 example.
Intervals.icu identifies the first interval as starting at 11:03:34 and ending at 11:04:58. That’s or 84s/1:24. Add 1 more second and it matches. The same is true for every interval I looked at in this particular .fit file.
This is great work from you. thank you for your interest.The same thing is happening to me. Most intervals are 1-2 seconds longer. Sometimes the average for the session is wrong also, I do not know why.