Request Help Re: "Time Moving" Discrepancies

[Cyclingteetop]

Greetings all - 

I'm hoping someone can help with an issue I'm experiencing with GC v. 3.4. I am am using GC to track cycling, running, and swimming. Using a Garmin 920xt. 

I'm finding discrepancies between GC and other software programs in measuring "Time Moving" such that it's affecting the various metrics. For example:

• I recently did a run where I had a few starts and stops due to red lights (I would start and stop the watch at each time). The elapsed time on the watch for the entire run read 1:30:12.  Uploaded the file to TP online and Strava - both read 1:30:12 as the time of activity. Uploaded to GC and it gave me a Duration time of 1:40:25 and a Time Moving time of 1:32:01. As a result, the total pace (and subsequent GOVSS) is impacted slightly.
  
• I recently did a short open water swim where I swam the length of the beach, stopped the watch for a few seconds, then started again and swam back along the beach. The elapsed time on the watch for the entire swim read 12:51.  Uploaded the file to TP online and Strava - both read 12:51 as the time of activity. Uploaded to GC and it gave me a Duration time of 13:01 and a Time Moving time of :51. Distance was uploaded correctly in all programs.  As a result, my average speed was 20.2 MPH (sure which I could swim this fast), but no Swimscore calculated as I only had 51 seconds of swimming.
  

Can anyone explain these discrepancies to me? 

Thanks!

Mark

[Mark Liversedge]

If you have gaps in recording (where you started stopped) then use the fill gaps in recording tool to put them back.

When metrics are calculated they assume no gaps in recording, which was originally due to two reasons; data transparency and ease of coding. As a result gaps (where time jumps) are not handled - hence fix gaps tool.

If you look in the editor you will see lots of squiggly red lines and clicking on anomalies will list them all.

CHEERS

Mark

[JulianM]

Just to add to this as I'd been having the same problem in calculating a Swimscore from Open water swimming as the swim moving time was so short.

Just fixing the gaps in recording (although it did fix the gaps in recording!) didn't help generate a Swimscore. After doing that though I used the Fix speed from distance tool in the editor which did seem to work and produced a Swimscore similar to that in Raceday when the original file was imported.

Julian

[Ale Martinez]

The problem with Open Water swim files seems to be Garmin uses an extreme version of "Smart" recording where the gaps between samples can be more than a minute, so the typical settings for Smart Recording Threshold (on import) and the stop parameter (on Fix Gaps) are not enough and they need to be increased to a value higher than the longer gap.

Also beware Fix Gaps is a one-time-shot: gaps longer than the stop parameter are filled with zeroes (not moving time) so further runs of Fix Gaps do nothing since the file doesn't have gaps anymore, you need to undo the previous change or re-import the file to run Fix Gaps using longer stop.

If you can post the file I will give it a look.

[JulianM]

Thanks Ale. File attached.

You're not wrong about the long gaps between the data points. It was a 4.5k OW race so no breaks in the swim time and there were 105 data points in the editor!

The original file has a duration of 1hr17m53s and a moving time of 1m44s (average speed 154.9kph; average pace 2s/100)

If I use the Fix gaps in recording tool as you say the gaps are populated with zeros and none of the Summary data changes. However if I then use the FIx speed from distance tool the data is much more accurate giving the same duration but a moving time of 1h17m49s (average speed 3.5kph; average pace 1:42/100).

I didn't change any of the default values suggested when using the tools. 

This gives a Swimscore of 94 which compares to the Swimscore of 84 which the same file in Raceday gives without any manipulation - they both have the same Swim threshold/critical velocity of 1:37/100m.

Julian

[Ale Martinez]

El lunes, 29 de mayo de 2017, 11:15:50 (UTC-3), JulianM escribió:

Thanks Ale. File attached.

Thanks for your contribution, I will upload it to test folder for future reference. 

You're not wrong about the long gaps between the data points. It was a 4.5k OW race so no breaks in the swim time and there were 105 data points in the editor!

The average gap is 45", the longest 61", so you need to run Fix Gap with stop parameter longer than 61 to interpolate between samples since Fix Gaps fills with zeros gaps longer than stop parameter.

The original file has a duration of 1hr17m53s and a moving time of 1m44s (average speed 154.9kph; average pace 2s/100)

If I use the Fix gaps in recording tool as you say the gaps are populated with zeros and none of the Summary data changes. However if I then use the FIx speed from distance tool the data is much more accurate giving the same duration but a moving time of 1h17m49s (average speed 3.5kph; average pace 1:42/100).

Running Fix Gaps using Tolerance=1, Stop=90 gives:

Time Moving: 1:17:52

Distance (km): 4.476

Avg Speed (kph): 3.4

Avg Cadence (rpm): 37

Pace Swim (min/100m): 01:44

xPace Swim (min/100m): 01:40

I didn't change any of the default values suggested when using the tools. 

Default stop=1 for Fix Gaps is not very useful, you need to rise it to the longest gap which is not a beer-and-burrito pause. 

This gives a Swimscore of 94 which compares to the Swimscore of 84 which the same file in Raceday gives without any manipulation - they both have the same Swim threshold/critical velocity of 1:37/100m.

Running Fix Speed from distance with 45" average (after Fixing the gaps) gives SwimScore=86 in GC

To fix this automatically it would be necessary to look if there are pause/start events to distinguish true pauses from longer gaps in smart recording, I don't see this happening soon but I will to document the above at the wiki.

[Ale Martinez]

BTW, rising the Smart Recording Threshold in Options from 25 to 90 before importing this file fixes the gaps automatically.

[JulianM]

Thanks again Ale.

Advice gratefully received.

Julian