Why is Strava showing different times than my Garmin?

Hi!

I noticed for a few days, that the data like average speed is displayd wrong on Strava. My Edge shows 24 km/h for my ride. But Strava displays only 18 km/h average speed. If I upload my data to the Garmin Trainigcenter it shows me the correct data from my Edge 500, 24 km/h. 

Further on segments, my elevation is always zero. Before and after the segment, the elevation graph is fine. But on the segment, the elevation is turning into a flat line.

Is my Edge broken or is there a calculation problem?

Thanks in advance!

MZwei

Was this article helpful?
14 out of 15 found this helpful
Have more questions? Submit a request

Comments

125 comments
  • I have the same question.  Why the dirreence between the Garmin 500, Garmin Training Center and Strava.  My last ride the Garmin 500 stated the everage speed at 22.1 mph.  then when i upload the data to strava the avarage speed is stated at 21.0 mph.  WHen uplodaed to Garmin Training Center the evaerage speed is steted at 22.1 mph. 

     

  • Hi M and Kevin, I responded to your questions both in separate Support Tickets. If you have a question for us (and not simply a discussion topic) it is best to reach out to us directly by starting a new ticket!

    The reason Strava is different than Garmin Connect and Training Center is that we parse Garmin data and analyze the data independently of Garmin. Strava takes the same file off the Garmin, but we enter and parse the data in our own system. We enter all the numbers, then calculate out the time, moving time, average speed, segments, etc. with our own algorithms we developed.

    Hope that helps!

    -Elle, Strava Support

  • So in other words the Strava algorithms are complete crap then.....good to know.

  • My results are even more extreme...I did a stationary ride tonight at an avg of 17.3mph but after I uploaded it, Strava recorded it at an avg of  55.9mph. I can't figure out how to fix it. I've confirmed the data multiple times on my Garmin 500 and have deleted/reuploaded the file several times w/ identical results. The first problem I had was it only saying I was moving for 13 or so minutes...I fixed the by checking the Stationary box. So what it did was only record the time that the GPS thought I was moving instead of the mag/sensor time. Actually...seems like 13miles in just over 13 mins would be 55.9mph. How can I fix this?

  • Marc i had the same problem. Go to the gps option & select it select gps status, enter on yes scroll up to no then come back out. That sorts it to the correct avg. The next time you switch it on the gps atomatically goes back on.

  • I have the same issue - Strava is continually under-reading the speed from my Garmin Edge 800. The Edge is accurate and backed up by separate apps on iPhone and Nokia Lumia using GPS tracking. One example was a 0.9 mile segment completed in 0:2:28, for an everage speed of 21.6mph. The ride summary shows the segment speed average at 22.6mph, which is wrong, while the segment details shows the average speed for the segment at 17.1mph. This is really ridiculous as it is very basic mathematics and does not need any fancy 'processing' or massaging.

  • Well, my case is totally different.  My Garmin Edge 500 with GSC 10 always shows a slower average speed than Strava does on my iPhone.  The difference varies but on a 25 mile ride is about 0.5mph.  Might not seem much to many, but when  you are tracking your progress and working on getting you speed up as the season progress, 1/2 MPH is a lot.

  • Please fix your calculations. I understand that some of your averages will be different if you have different data, BUT as many riders have pointed out, there are some calculations that are just INCORRECTLY DONE. There are several errors that are NOT caused by data differences. YOUR MATH IS INCORRECT. 

    You have a great application. I cannot understand why you will not correct your math errors.

  • Please fix it!!!!!! 

    The avg speed is close to Garmin's one on short distances, but longer the ride the bigger the discrepancies. 

    When you are training every .1 of mph counts!

  • How does Strava calculate times from the Edge 500 file. In Garmin Connect, the Ride Details breaks down TIme as 2:22:28, Moving time is 2:20:46.

    In Strava, the ride Time is 2:24:46. That's a four minute swing, which is not insignificant. I think I have autostart/stop set to =>3 mph. I can't imagine I traveled at or less than 3 mph for four minutes. So that I can understand what's going on, can you tell me how you do your calcs? Thanks!

     

  • Thanks to everyone for chiming in here! There are a lot of different questions on this thread about averages. 

    1. Regarding Average Speed on your [outdoor, not stationary] Strava activity when recording with a Garmin device: See my initial response. Garmin devices run a calculation during recording to total up your moving time, or the time you are not resting/stationary. This moving time is divided by total distance to get average speed. When your data is uploaded to Strava, a separate calculation is run based on your GPS data to determine moving time. This can be different than what your Garmin reports. If you see differences in Average Speed between Garmin and Strava, first check your stats for moving time and total distance as that should explain the differences. 

    2. Regarding indoor/stationary activities: @John shared a good tip - if you use a speed sensor or power meter, turning the GPS signal off when recording indoors allows Strava to display the correct stats for speed during your session. @Marc there may also be an existing bug around Stationary speed readings, so I would recommend reaching out to our support team directly so that we can look into it. 

    3. Regarding Average Speed on Segments: We've seen skewed stats for your average speed on a particular segment if the original segment's distance is different than the distance you traveled. If you get an inaccurate match, or the data used to create the segment is not good, then there can be small differences in the distance of the segment compared to the distance you traveled. Strava computes your average speed for a segment based on the Segment's distance. To check the math, click through to view the segment page and see the distance listed. @Joe, if you have more questions about the math please feel free to reach out to us directly. 

    4. Regarding the comparison between a Garmin speed sensor and a Strava mobile app recording: This is a difficult comparison as the methods of data collection are different - the Garmin GSC 10 tracks speed/distance based on wheel revolutions, which when calibrated correctly is pretty accurate. The Strava mobile app calculates speed/distance from the GPS coordinates and the time between each coordinate. 

    Let me know if this helps clarify! 

  • Hi,

    Just wondering why Strava doesn't just use the "moving time" that's recorded by Garmin. The distance data always seem to be more or less identical when comparing my Garmin Edge Touring with Strava, but it's irritating when the moving time differs for no obvious reason, particularly when the beeping on my Garmin unit to signify when I'm stopped (autopause mode set to "when stopped") correlates with when I am actually stopped when I'm on my bike.

    Why do Strava use their own calculation for moving time?

    Thanks

     

  • This really sucks. Strava fixes this.

  • I can see the discrepencies within strava often - if you "analyze effort" for example you can see big differences in the graph views for speed.  For instance here is one that happened today - you can see that for 90% of the segment I was over 30mph, but the average shows 26mph, it makes no sense how this is so far off.  I have also seen the reverse, where someone's speed is low in the graph, and the avg speed shows much higher and they get a kom.  Don't get me wrong, I love this site and don't want to be a psycho about koms, but the accuracy should be better thatn this.  I have also ran garmin and iphone over the same segments simultaneously and seen up to 4 second advantage to iphone.  This is huge problem for competitive segments with ten people tied for second and the leader one second ahead after using an iphone, when he should be in like 20th place lol.

     

     

  • Hi Ivan,

    I believe you might find the explanation in this thread helpful:

    https://strava.zendesk.com/entries/40529030-Average-Speed-in-segment-ranking-is-different-from-speed-in-Analysis-tab-

    I think your observations with average speed have more to do with the Strava segment system and less to do with Garmin data.

    Hope that helps! 

  • Hi Elle, thanks for clarifying what's going on with that.  I suppose you can move my reply or delete it if you like.  Regarding the issue though, it really is sort of a big deal as far as leaderboard accuracy.  It's almost as if it was designed with an assumption that most users will continue along the same path and hit that next gps point beyond the segment end.  I'd argue that it's more likely they stop, as many segments end at crossroads or stop lights.  Why not use the last gps spot before the end of the segment?  Also, the segment creation tool seems to snap to some sort of points.  Can it not just snap to a known gps point or is that too difficult to integrate into the map/seg tool?

     

     

  • Hi Ivan,

    Thanks, I certainly see your perspective around average speed on Segment leaderboards. Regarding what Strava chooses as the appropriate endpoint, we actually do use the closest GPS coordinate to the segment's endpoints. This is typically either the point right before the end of the segment, or right after. 

    I don't know about a snap tool for segment creation. If you have further questions about this would it be possible for you to start a new forum topic or support ticket? 

    Thanks! 

  • Hi - picking up on @marmite's point, Strava is introducing an unwanted error / imprecision by recalculating a new moving time, rather than using one recorded directly.  It would be enormously preferable if Strava either gave an option for taking this properly measured value across or simply take this value by default.

    Steve Gosling

  • Whatever the case may be, it's pretty annoying when you work your ass off on the bike to achieve and keep a 20.3 or 20.4 mph average, only to upload it into Strava and see a 19.9 mph average. The laps times are relatively the same as the Garmin laps almost to the decimal, so it's pretty annoying. I love Strava and I'm glad there's a way to measure your progress through here, but it would be nice if Strava didn't have to recalculate everything when it has already been calculated by my Garmin. Otherwise, what's the point of recently introducing the ability to upload into your Garmin Connect and for rides to automatically show up on your Strava if you're gonna change up all the data anyway? 

    Whatevs. This issue won't make me a Strava hater but it'll certainly continue to annoy not just me but a whole bunch of riders, as I see already.

  • This annoys the hell out of me!

     

    GARMIN

    Average speed of 20.8 over 9.1 miles, top speed 27.6 and a moving time of 26.15

    STRAVA

    Average speed 20.7 over 9.1 miles, top speed of 27.5 and a moving time of 26.23 & a elapsed time the same (26.23)

     

     

  • I totally agree with the above comments.  Especially about why bother synching the Garmin with Strava when Strava is going to change the data anyway.  In most cases my average moving speed in Strava is less than on up uploaded Garmin data.  It's like we're working our butts off for nothing and it is demoralizing.  I add my voice to the others that plead STRAVA PLEASE FIX THIS!!!

  • I'm an empath, I can feel the pain of this incorrect average upload.... OK im not, I just wanna know will it be fixed?

    Actually, perhaps always let garmin rank higher (as mentioned its should be more accurate) than the Strava app too. Many are living the KOM life using their Strava app, but give them a Garmin and the story would end differently.

    All in all thanks for a great app Strava.

  • I have a good example of crazy difference in MAX speed.  Garmin 805 shows max speed 46.5  (wasn't watching the Garmin whole time, but never saw my speed exceed mid forties so I believe 46.5 is accurate)  Ride is here...

    http://connect.garmin.com/modern/activity/595091365

    Uploaded ride to STRAVA, and max speed is shown as 55.9, quite a whopper of a difference.  Ride is here....

    http://www.strava.com/activities/197224249#4644450113

    How can they be so different? 

  • My views only, My Strava reading for today's ride differs significantly from my Garmin 910 XT. Strava ride time almost 20min longer over 2+hrs, Strava distance approx 3KM longer & almost 3 KM slower avg speed vs my Garmin. Whats the point if Strava data differs that much from the industry standard Garmin. Disapointed user.

  • Whingers take note: My Garmin GSC-10 is acting up. Garmin recorded ride as 65km, Strava CORRECTLY calculates it as 76.  Thanks for nothing Garmin. Thanks for recovering the ride Strava.

  • @Mathew W. You outlier.

    I don't think people are whinging. Just helping to make Strava better.
    Was you searching out a thread just to say you're happy?

  • I'm getting huge difference also with my 810... I'm thinking that the auto pause has something to do with the discrepancies. It seems as simple as a difference in moving time... My garmin timer must pause with the auto pause and strava must keep ticking over when your idling at under the Auto pause speed. Seems logical... but then how does Strava work this out from the Garmin data that gets uploaded after the ride has finished??? Why does strava have to recalculate??

     

  • I'm not an outlier, I see the same behaviour you do and am definitely no Strava fanboy. Maybe I just have a more pragmatic perspective.

    I had a problem and noticed that Strava handled it quite well, whereas the other websites and software packages I use did not - so I came looking for a more detailed understanding. As it turned out my Garmin had randomly decided to autocalibrate my wheel to a ludicrously small circumference, and I now have to waste hours of my life manually processing the affected rides that I have stored outside Strava.

    Strava has hundreds of thousands of users, all using different kit that may or may not be working correctly. Say you and I both have Edge 800s. Do you have one-second recording enabled, or are you using smart recording? Do you have auto pause enabled? And at what speed does this kick in? How clean was your GPS track today? Do you have a speed/cadence sensor and if so is this calibrated correctly, with magnets correctly positioned and batteries working properly? Was there any interference/dropouts on your ANT+ signal(s)? It goes downhill from there. And I'm completely ignoring altitude.

    Strava is a segment comparison website, Garmin Connect is not. It follows that rides need to be processed by Strava in a consistent, but different, manner, which in turn means that summary stats for your ride will be processed in a different way to what your Edge determines.

    If you are looking at your own numbers, PBs etc, you can either stick with Strava and accept some variations from what the Garmin tells you, or use it alongside other tools that give you a more in-depth view (but which will generally expect you to do your own data correction and cleaning). If you are going for KOMs etc you need to accept Strava's judgement and understand that the shorter the segment, the more impact a small initial variation will have. You can always send them an email if you think a particular ride has been mishandled.

    In any case, people need to understand the inherent limitations and variability of their devices, the impact their config settings have, and the resultant data normalisation compromises required for Strava to work well.

    Hope this helps clarity.

  • Matthew W., yours is the first logical explanation I've ever read in the midst of this whole discussion. It makes total sense to me that everyone has different settings on their Garmin device. For example, I live in Orlando, Florida, I'm self employed and I ride primarily alone during the week on regular roads. The traffic here is generally consistent most of the day and so is the presence of traffic lights. Because of the incessant amount of coasting and shortage of bike lanes, I have auto-pause on my Garmin 500 set to pause the ride at 5 mph while I'm stuck behind buses and such. I see now why Strava has to recalculate my Garmin differently than the next rider who only does weekend group rides on Sunday mornings with very little traffic hindrance. It doesn't make me any happier to see what is sometimes vastly different data across platforms but it does shed some logical light on the situation.

    Thanks for clearing that up. 

  • @Mathew - I appreciate you adding your input to this thread as well! My apologies for not chiming in sooner. 

    Here are a few additional notes that may help those of you with questions regarding the differences in Garmin and Strava data: 

    • Most GPS data recorded by a Garmin will have some small errors present. These are often known as Stuck Points where for a period of time (usually only a few seconds), the Garmin does not receive a location update but time progresses. The Garmin will record the last known location until a new update is available. When the new location update is recorded, you can appear to "jump" forward to the new location update at an acceleration rate that is not humanly possible. The Strava servers work to detect these errors in your data. If such errors are detected, then Strava will run a recalculation of your GPS points for distance, essentially smoothing out the errors. This process will not happen all the time, but will happen most of the time. 

    • This is the process that "fixed" @Matthew's data. This is also the cause of the larger data discrepancies that @Tom Howell reported (I was able to fix Tom's data by reverting the changes Strava made to the GPS data, and recalculating the moving time).

    • It's well known on our support team that the above process is not favorable for all data or preferable for all our Strava users. Hopefully my response will help clarify that our goal here is to improve the data uploaded to Strava servers, and to make it uniform across all devices who upload to our platform. 

    • Most of the larger discrepancies reported by Strava users around Moving Time between Garmin and Strava originate in the above recalculation of GPS data. If you start a direct support ticket with us, we can revert your activity to the original/raw state. I think it would make a lot of sense to have this option available on the user-end, but for now it's only visible tot he support team. 

    • Auto-pause: Yes, auto-pause can affect Strava's algorithm for moving time. When Garmin's auto-pause is enabled (when you meet the speed threshold), the recording stops (neither time or GPS data are recorded when the Garmin is auto-paused). To Strava, this looks the same as if you were to manually stop and resume your Garmin - it is a gap in the data. Our algorithm for detecting moving time can sometimes get tripped up on the data gaps. For better results, we usually recommend setting your auto-pause to start at a lower speed threshold, or turning it off completely. 

    • I know a lot of you on this thread would like to know why we recalculate Garmin's moving time to begin with. There is no single reason, and I think @Matthew offers some good explanations. I would also add that Strava accepts data from a wide range of devices both dedicated GPS computers and mobile devices, and we wanted a way that all incoming data to Strava could go through the same data processing. It is indeed very true that each device has different settings and methods for recording the GPS and time data, so having a standard way to process all incoming data to Strava has it's benefits. However, we completely understand there are some frustrations associated with our processing as well.

    Please continue to add your feedback, and keep the discussion going! 

Please sign in to leave a comment.