Feedback on Run Tags and Moving Time/Pace Calculation

Strava,

What is the difference in tagging a Run Activity as one of these Run Types?

1) Run

2) Race

3) Long Run

4) Workout

5) Treadmill

The one difference I see is that by tagging a Run as a Race, Strava modifies the Pace to be the actual Pace instead of the Moving Pace. On all other tagged Run Types, the Moving Pace is used for mile splits (but labeled as Pace). Also, the Elapsed Time is shown at the top of the overview in large vs small font and presumably calculates the pace from the Elapsed Time.

 

1) I don't see any KB Articles on Run Types, so please elaborate on them

2) Strava should not be using Moving Pace on Run mile splits - its misleading and not accurate. If Strava wishes to display the Moving Pace vs the actual Pace, then Strava should label it as such.

3) I should not have to switch my run to a Race just to see the actual Pace mile splits.

4) IMO Strava should not even use Moving Pace, its not useful. But if they wish to use it, it should be labeled so people are not confused if it is a Moving Pace or the regular Pace. By tagging a run as Race vs Run we are somehow suppose to know that the Pace has been changed from Moving Pace to Pace? Just label the Pace always and show both. For mile splits, GAP and Moving Pace (labeled as just Pace, misleadingly) are of no interest and the true Pace is not shown (unless the run is tagged as a Race)!

 

Strava - please straighten out your usage of Moving Pace. We need to see our real pace for mile splits - not a massaged # that looks great even if we stopped at every drinking fountain.

Also, on the Run overview page, the Moving Time shown is not the actual Moving Time, its the Time. Garmin defines the following times; Time, Moving Time and Elapsed Time. Strava is overloading the usage of Time and Moving Time. The label on the web page is Moving Time, but the value is Time. Change the label to Time. And in the mile splits, you do the opposite, label the pace as Pace when its really the Moving Pace. Both of these are misleading, and in the case of mile splits do not even have the actual Pace per mile. iPhone App displays Pace as Moving Pace with no option to see the actual Pace and does not label the Pace as Moving Pace either. This needs to be fixed too.

Quite simply - label the correct values - and show the real mile split Paces. Label Moving Time as Moving Time. Label Moving Pace as Moving Pace. Label Time as Time. Label Pace as Pace. And show the actual mile split Paces (not moving pace) despite how the Run is tagged.

 

connect.garmin.com labels these values correctly and includes both regular and moving times/paces.

 

 

 

96

Comentarios

217 comentarios
  • One more thing... Fix your Apple apps (please), you can mark a run as race and it makes bugger all difference anyway... Just tells the same old lies as if it were marked as run... Don't know why I'm bothering to write this though as clearly no one is listening.
    0
    Acciones de comentarios Permalink
  • Similar problems for me (Moving time is considerably less than Elapsed time despite not stopping on the run). Forerunner 110.

    I converted my .fit file to a tcx to take a look at the actual data.

    I see various points that have no position information in them (see middle trackpoint of attached image). Note that this missing position data is in the middle of a run (5km in) and not near any buildings that should interfere with GPS reception, so no idea why the watch is not recording a GPS position there.

     

    More importantly, if I remove the points with no Position tag and upload the resulting tcx file the moving time is correct (i.e. it matches the elapsed time) and all of the remaining bits (pace/etc) are correct. 

    I'll try adding positional information to the points (by interpolation of the previous/next points) so that I don't lose the HR information contained within these points.

     

    Annoying that I now have to pre-process my runs before I upload them to Strava to workaround their algorithms.

    0
    Acciones de comentarios Permalink
  • To further demonstrate the unreliability and inaccuracy of Stravas data processing on runs take a look at this recent fiasco. (A.k.a let's beat this dead horse a bit more)

    Garmin Connect activity recorded with Forerunner 220 http://connect.garmin.com/modern/activity/670936832
    Strava activity automatically synced http://www.strava.com/activities/239627931 (I manually paused the watch at the top for a few minutes to soak in the lovely view and the times match!)

    Now get this: a few days later I get the same activity automatically synced as a grouped run with MYSELF? If I delete the second one it just keeps coming back so I've flagged it.
    http://www.strava.com/activities/240745427

    The "moving time" and pace of the Strava activities are different. About 5 minutes off. 

    Quite a few discrepancies here.
    1. Supposed group activity but different moving times.
    2. Same data source but different results
    3. Supposed group activity but being assigned to the same person - me
    4. Manual pause on the first auto import honoured but not on the second 

    So as we can see Strava alters the data and then can't even recognize it as the same activity. 
    No bueno :(

    I wrote Premium Support. Can't wait for the response :P

    0
    Acciones de comentarios Permalink
  • Add me to the list of folks who would like to default to elapsed time instead of moving time. I have to believe that any runner who says they want the moving time must simply not understand this issue. As many others have experienced, I run without stopping, yet Strava insists that I wasn't moving for large chunks of time. My pace is artificially low EVERY TIME I RUN, even though I never stopped. No one who realizes this could possibly prefer to use the "moving time."

    0
    Acciones de comentarios Permalink
  • Interesting what Alex Greenbank said about the data points from the Forerunner 110 watch missing position data. Strava informed me during an email exchange that, inexplicably, the data from my watch (also a 110) had several points where the position data was identical to the previous point, and this is why Strava assumed I was stationary for a couple of minutes during my non-stop runs. This was coming up for two years ago, when the new run pages were introduced. They said they were working hard on this bug. Still here now... and Alex may have the explanation there. Suppose the data from the watch doesn't has missing position data, just as he found. Then Strava's initial interpretation of the data has a little code that leaves any data point that is missing position data, with the position data from the previous point. And that may be the explanation for the inexplicable duplicates of position.

    So now we have a possible explanation for the false resting time detection, please could that be fixed?

    And also, please could we have an option to not detect resting time - like a race run?  So easy to do.

    0
    Acciones de comentarios Permalink
  • Hi-
    Hoping I can find a way to use my authentic time in activity. Perhaps there is a "real" term for it, perhaps say: clock time? Say I start an activity and an hour and a half later I stop it. Well, it would be nice to trust the 1-1/2 hour elapsed time. Strava doesn't allow me to do this, and why I just don't know, but I wish I could override this setting.
    Yes, I realize there is a run and ride auto-pause function, but I don't see the value of it, if the server is going to delete non-moving time anyway.
    If I have to stop to tie my shoe, vomit, drink, pick up litter, etc I feel it would be nice to pay for the luxury by having my time docked for the rest. This is not the way Strava seems to record my runs.
    I've been using Strave, MotionX-GPS and Wahoo Fitness apps on my iPhone 5s for the last year and a half. Strava ALWAYS shows shorter times on the trail and thus a faster pace. I don't feel this is accurate. My race times do not take into account how many times I stop to rest, talk or take pictures or wait in line at the sani-can. I feel because Strava subtracts these idle minutes (that I don't have control of adding back in) that my times according to Strava are fictional, not real world, rather "feel-good" numbers that do not compare properly with race day times.
    Granted, I accept that I may have my settings set incorrectly. I seem to find only one place to adjust them: Setttings>Ride auto-pause button or the Run auto-pause button. Both of mine are turned off (showing only a white circle, not with the orange background and white circle).
    Might there be another place for me to set this to show my correct clock time in the event?
    Cheers,
    John

    0
    Acciones de comentarios Permalink
  • Why is this thread in "Suggest a new feature" section?  It should obviously be in the "Report a Strava Issue or Bug" section.

    https://strava.zendesk.com/forums/21769950-Report-a-Strava-Issue-or-Bug

    Strava developers could:

    1) Fix this issue in 10 minutes by adding an option to avoid removing stationary time, as they do for races.

    2) Also fix the bug (e.g. on Forerunner 110 watches).  The reason for it has been described here by Alex Greenbank.

    It would be great if they would do it, as it is quite frustrating to have to remember to randomly stop and start the watch at some point during the run.

    0
    Acciones de comentarios Permalink
  • Strava shaved off 2min 11sec on my last run. I also used Runkeeper to compare (with auto pause). I didn't stop once, so where/why did they cut 2.11 of my time????????? This is not good enough Strava!!!!

    0
    Acciones de comentarios Permalink
  • Hi.

    First, a little introduction. I'm free, not a premium user, I use different watches (Garmin 910XT, Garmin Fenix 2, Suunto Ambit 2). Recently I've been using 910xt. Activities are transferred to Strava automatically from Garmin Connect.

    I'm totally confused by the way that Strava shows data on the activity page.

    First of all I think Strava should be showing pace basing on activity time and not moving time counted by Strava (in the case of my recent activities with the Garmin 910xt the moving time is taken from Garmin's activity time so it's ok because Strava does not count it by itself).

    But what struck me yesterday was the table that shows laps.

    I have a recent activity marked as "run". It was a run consisting of three "laps" 3,2km + 21,1km + 3,6k. I had to stop quite a few times during the run (especially in the 2nd lap), so every time I stopped at the traffic lights I stopped my Garmin and I started it again when I started running again. The thing is that Strava takes ELAPSED TIME for this table! I do not understand why. If I wanted to know the elapsed time I wouldn't bother to stop the watch at every traffic lights. I did that so I can know the exact pace I did on that lap.

    I read most of the thread but I haven't seen anybody complaining about this. For me lap times and lap pace is way more important than the splits.

    I think the way the data is displayed on Strava is very misleading.

    And the solution is very simple. Strava should show all the times and the pace for all these times: "real" activity time, elapsed time and (if it's so important for so many users) the moving time calculated by Strava. And all of these three different times/paces should be showed everywhere: in the overview, in the splits table and what's important to me: THE LAPS TABLE!

    I started using Strava because I've got both Garmin and Suunto watches and wanted to have all the activities in one place, but I am very disappointed by Strava and now I rather analyse my activities in Garmin Connect.

     

    Best regards,

    Wojciech

    0
    Acciones de comentarios Permalink
  • Just another user adding my concern for this moving time used by Strava - I have always used Runkeeper and recently imported all my activities across.  Went for a run last night, tracked it with Runkeeper and synced it over to Strava and it removed 3:25 from my run (which was only 38:21).  Interestingly a ran with someone who used the exact same process (Runkeeper to track and sync over) and it matched out runs but with hers it is only 46s difference (again we only stopped once at a set of lights for 20s max but at least it is a bit more accurate!)

    Strava need to either remove this or give the user an option of changing it themselves...

    0
    Acciones de comentarios Permalink
  • One last little comment from me before I unsubscribe from this thread, hopefully this might be helpful for some...

    For the last 6 months I have been getting around the moving pace thing by doing a quick "stop-start", "stop-start", at some point in each run, which then forces Strava to show the elapsed time rather than moving time. Which has actually worked fine apart from the odd time when I forgot.

    So I guess that could also work for some of you as a fix (albeit a slightly annoying one).

    However, I now have a permanent fix for this issue and that was to buy a new watch... I have just upgraded from the Garmin Forerunner 110 to the Garmin Forerunner 220, and it has completely fixed the problem... Now my elapsed time is virtually identical to my moving time, every time I go out for a run :-)

    So I guess that this higher spec watch catches and records data in a different way to my old one; and whatever it is doing, is clearly more agreeable for Strava.

    Happy running people!

    0
    Acciones de comentarios Permalink
  • Quick question - I am considering purchasing a Garmin Forerunner 610 watch.  Will I still see this problem on my run activities uploaded to Strava?  Currently using an iphone to track just.

     

    Thanks!

    0
    Acciones de comentarios Permalink
  • @Gregg McKeown - The issue mostly disappeared for me when I moved from using my phone to track runs, to using a Garmin 910XT.  I can't comment on the 610, but I imagine being a dedicated GPS device it'll have a similar result.  Would be keen to see if others have had similar experiences when switching from phone to Garmin / other GPS sports watch though...

    0
    Acciones de comentarios Permalink
  • I'm a new member but as far as I can tell, the numbers are good. I just use my phone Android to track.

    However, if I set up the "auto-pause", it will pause randomly in very strange moments. This feature is not ok to use. When I do runs/jog/runs workouts, everytime I'm jogging, the app thinks I'm not moving, thus, auto-pause. Everytime I get my phone out of my pocket, this happens too.

    The solution so far was to disable the auto-pause. Now it works good...

    0
    Acciones de comentarios Permalink
  • I'm kinda tired of see 'moving time' for runs completely underestimated.  Anyone at Strava ever been for a gnarly trail run????  Clearly not......

    Oh for them to fix it

     

    0
    Acciones de comentarios Permalink
  • I'm sorry to say that "bug denial" seems to be an increasing problem among software developers. Basically, regardless of what we say, they have decided that this is working as intended. They won't take that minute or two to understand what we are telling them, because they prefer to think everything is OK and that we are basically a bunch of nutters. It's easier to believe that because then they don't have to spend a few minutes fixing the bug. Probably they have unsubscribed from this thread and it's something they have already dealt with, never to be looked at again. So for now I think our only option is to use the workaround. Just stop your watch at some point during the run and start it again.  Just when you go through a gate, over a stile or something. Strava does detect this when you upload and disables the faulty algorithm that detects stationary periods.

    0
    Acciones de comentarios Permalink
  • Or, do as I did - stop paying for something that doesn't work. They lost me 2014, seems like they won't get me back 2015 either.

    0
    Acciones de comentarios Permalink
  • It really is a disgrace and insult to Strava users running trails (or road for that matter) that you don't get to decide when you are actually running. Perhaps if it's such a big thing for them to change the default behavior why not add another run-type - "trail", or "real run" or something. And choosing that as a default will leave the decision about pausing your watch up to you, as it should be. 

    Sure moving time looks good - I'm running a 100-miler in August and I know according to Strava I'll be beating Kilian Jornet. Can't wait. Run less, perform better. The Strava way. 

    0
    Acciones de comentarios Permalink
  • > I'm sorry to say that "bug denial" seems to be an increasing problem among software developers

     

    It's not quite that simple, it's not all Strava's fault. Strava could do something to fix the problem but the problem is mostly due to incomplete data from the GPS and how they choose to interpret/handle this.

     

    I have a Garmin Forerunner 110 and it works very nicely, however sometimes it doesn't put GPS information on the trackpoints it logs, despite there being no reason why it shouldn't have a nice lock on the satellites as I'm running out in the open. Sure, I understand why I don't have GPS points on trackpoints where I run through an underpass or some particularly heavy woods but not all of the cases where I get missing positional data are scenarios like this.

    Here's an example from a recent run:-

    <Trackpoint><Time>2015-06-18T07:24:16Z</Time><Position><LatitudeDegrees>51.44610657</LatitudeDegrees><LongitudeDegrees>-0.2552643232</LongitudeDegrees></Position><AltitudeMeters>18.4</AltitudeMeters><DistanceMeters>3466.53</DistanceMeters><HeartRateBpm><Value>155</Value></HeartRateBpm><Extensions><TPX xmlns="http://www.garmin.com/xmlschemas/ActivityExtension/v2"><Speed>2.611</Speed></TPX></Extensions></Trackpoint>
    <Trackpoint><Time>2015-06-18T07:24:20Z</Time><AltitudeMeters>18.8</AltitudeMeters><DistanceMeters>3476.64</DistanceMeters><HeartRateBpm><Value>155</Value></HeartRateBpm><Extensions><TPX xmlns="http://www.garmin.com/xmlschemas/ActivityExtension/v2"><Speed>3.013</Speed></TPX></Extensions></Trackpoint>
    <Trackpoint><Time>2015-06-18T07:24:21Z</Time><AltitudeMeters>18.8</AltitudeMeters><DistanceMeters>3483.53</DistanceMeters><HeartRateBpm><Value>155</Value></HeartRateBpm><Extensions><TPX xmlns="http://www.garmin.com/xmlschemas/ActivityExtension/v2"><Speed>3.013</Speed></TPX></Extensions></Trackpoint>
    <Trackpoint><Time>2015-06-18T07:24:27Z</Time><Position><LatitudeDegrees>51.44584942</LatitudeDegrees><LongitudeDegrees>-0.2552864514</LongitudeDegrees></Position><AltitudeMeters>19</AltitudeMeters><DistanceMeters>3495.47</DistanceMeters><HeartRateBpm><Value>157</Value></HeartRateBpm><Extensions><TPX xmlns="http://www.garmin.com/xmlschemas/ActivityExtension/v2"><Speed>2.866</Speed></TPX></Extensions></Trackpoint>

     

    4 trackpoints, first and last have position data, middle two do not. There is some tree cover there in Richmond Park but hardly what I'd expect to be enough to disrupt the satellite reception. Even so, the "DistanceMeters" counter is increasing during this time (and the 'speed' value doesn't seem to be guesswork based on other examples). But the point is that I didn't stop running there, and analysis of the points before/after will show that I must have been moving during that time where it had no signal.


    Strava chooses to interpret trackpoints with no GPS information as stationary periods, even though the points immediately before and after the ones without GPS positional data are a reasonable (spatial) distance apart and consistent with continuous movement at whatever pace I've been running at.

     

    In the above example it assumes that I had stopped between 7:24:16 and 7:24:27, because there trackpoints between those times had no position information on them. So that's 11 seconds of time stopped right there. This file has a further 27 trackpoints with no position information, and so it slowly builds up more and more time where it thinks I was stopped. This depsite the distance between those points 11 seconds apart is ~29 meters, consistent with me plodding along during that time.

     

    On a more general level (and thinking about the algorithms they'll need to implement to fix this) it gets tricky. Take a gap of 10 seconds or so (happens quite frequently like the above):-

     

    The simple case (like the above) is that there's a period of 10 seconds where I move a further 30m down the road (consistent with running at ~11kph for 10 seconds). In this case it's quite easy for Strava to assume that I hadn't stopped at this point.

    But what there's a period of 10 seconds where I move 10m down the road. Did I run for 3 seconds and have to stop to wait to cross a road? Did I walk for those 10 seconds? Did I try and run for those 10 seconds but it's an evil steep hill and I was going at a third of the usual pace? With missing data Strava can't tell, and this is probably why it's not so easy to tackle this problem.

     

    There are a few points on my runs that I do have to stop but most of the time I don't get missing position data on the trackpoints at these points. With position information Strava's algorithms can correctly detect that I've stopped and the moving/elapsed times will be accurate.

     

    What I do to get around all of this is convert the .fit file to .tcx (using Fit2Tcx) then use some perl scripts to reformat the resulting xml and strip out the points that don't have positional information on them. I then upload the resulting file to Strava. Strava then uses it's algorithms to pick out the points where I've stopped (based on consecutive trackpoints being very close to each other) and I get accurate moving/elapsed times (and therefore pace).

     

    Strava could address this issue in a couple of ways:-

    * Ignore trackpoints that don't have positional information (which is what my filtering scripts do, to good effect).

    * Or, don't ignore the points without positional information but analyse the points before/after them and decide whether the bounding points mean that movement was continued during this time and effectively interpolate

     

    It also explains why some other devices don't suffer from this problem, as they may not log a trackpoint without position information, or they log frequently enough that one or it only affects one or two trackpoints and so stopped time is negligible.

     

    It's just a pain, for me, to have to clean up each of the files before I upload them, it would be much nicer if Strava was aware of this issue and wanted to address it.

     

    Of course, the problems seen by people in this bug report may be caused by some different issues, but removing trackpoints with no positional information completely solved the problem for me and, at the underlying technical level, I can guess that this is due to certain assumptions in Strava's algorithms.

    0
    Acciones de comentarios Permalink
  • Hi Alex, 

    The moving time vs elapsed time is different. From the Strava blog - " The moving time calculation on the server looks for portions of the activity where the athlete was moving below a certain speed threshold for more than 15 seconds and removes that time as “resting time”, leaving the remainder as moving time.

    That's the crux of the problem, and I suspect it also differs on where your data comes from, so actually no ways to compare two runs on the same stretch not set as race. (I use a Suunto). By just leaving the data as is and respecting the pauses initiated by the runner the times would be as you'd want them. Easy way to see this is just to switch your run to race, viola, Strava doesn't infer their own stops and the run reflects accurately on your profile. 

    0
    Acciones de comentarios Permalink
  • > The moving time vs elapsed time is different.

    If I upload the raw .fit file from my device Strava thinks I was stopped for more than 5 minutes over a typical 1 hour run (and it can be worse) despite me only stopping for 10 or 15 seconds at most during the run.

     

    If I do my stuff to remove trackpoints with no position information and upload that file (representing the same run) then the moving/elapsed times are exactly as I would have expected (given that I may have to stop to cross a few roads).

     

    No need to set it to 'Race', by cleaning the data I don't give Strava the chance to misinterpret it.

    0
    Acciones de comentarios Permalink
  • As a follow up to the question I asked at the end of May - I purchased a Garmin 610 and on the few runs I have done with it I am happy to say that the Elapsed Time and moving time are now pretty much the same (Some runs exactly the same, some others 10 seconds or so out) which I am happy with.

    Frustrating I had to spend +£100 to get it to work right but I had my other reasons for wanting a dedicated GPS tracker so the fixing of this issue was just an added bonus!

    0
    Acciones de comentarios Permalink
  • I use Strava on Android smartphone with Lollipop 5.1 and GPS set to high accuracy.

    So far so good. However, as I stated before, the auto-pause on the app was completely wrong. Oftentimes it would consider my logging or recovery pace as a pause. I just disabled. I can see that this issue here is more about dedicated low-cost GPS devices than on Strava. If you use on smartphone with original Strava app, no errors are shown, I have at least 15 friends that used in their smartphones, and no issue.

    Honestly people, those who are experiencing problems from where I can see, it's a DEVICE problem. Particularly the low-end ones. So I think it's more of a manufacturer issue than Strava.

    If you read all comments, you'll that people using Forerunner 110/210 or whatever are the ones with most problems.

    And I say that because the dedicated manufacturer website might be specifically designed to interpret those trackpoints differences automatically. MAYBE, just MAYBE, garmin detects you use FR210 and interpret the missing data with nothing and calculate the time between positions, and, with the high-end devices, it may not even record the data, or it interprets differently.
    Either way, you are benefitting someone in prejudice of others.

    0
    Acciones de comentarios Permalink
  • If I use a high-end GPS device (which I do) that for some reason struggles with GPS reception (dense tree cover or otherwise tough conditions), I expect my training software to cope with that accordingly. Most apps do that perfectly well, but Strava refuses to acknowledge this and recommends manual intervention to fool the software to calculate correctly (pressing pause during the run for example). I am not willing to pay for something so obviously inferior. And it makes the rest of the Strava goodies uninteresting too since it all will be based on false data. Comparability, anyone?

    The most obvious solution would be to let the device handle pauses _if I want it to_ and just show the data as-is, without trying to detect pauses that isn't there.

    0
    Acciones de comentarios Permalink
  • @Alex, we've seen this problem with the Forerunner 110 as well. Thanks for posting the information. 

    I've updated the title of this forum topic and moved it to a new section - please continue to add your feedback here.

    It would be particularly helpful if each of you could include the URL/link to the activity page in question, then describe the moving time displayed versus what you would expect to see. Thanks!

    Some helpful info: Curious about how we calculate Pace for your runs?  

    GPX and TCX files

    When you upload to Strava from a .TCX or .GPX file, there are no pause events contained in the file.  Most newer Garmin devices use .FIT files (more on that later), but some Garmins like the Forerunner 410, 110, etc., record activities in the .TCX format. This means that Strava calculates Moving time, Elapsed time, and consequently Resting time (which is not displayed) for your run based on the GPS data recorded by your device.  Keep in mind that as a result of this, any wayward GPS points or 'GPS Drift' can have an affect on the resulting statistics for your run.

    We base our detection of stops on your speed when you are running downhill (where grade is less than 0%), and we base it on GAP if you are running uphill (where grade is greater than 0%).  In order for Strava to recognize a stop, you have to be moving below a specific speed for a certain amount of time.  When both of those thresholds are triggered, Strava will recognize a stop; and the amount of time you spend below our speed threshold until you resume running will be removed from our pace calculations.

    Activities uploaded from .TCX or .GPX files will show Elapsed Time, which is the total time elapsed during your run; and Moving Time, which is the amount of time we detected that you were stopped subtracted from your Elapsed Time.  Since your run's Splits are based on moving time, if you add up each split, you should come up with your run's total Moving time.  Likewise, all of the other performance metrics displayed on your run's Overview page are based on Moving time - however, as always, segments themselves are based on Elapsed time.

    Laps, on the other hand, are based on Elapsed time, rather than Moving time.  This is to account for and accurately represent resting laps during your workouts that might include stops.  With Laps based on Elapsed time, they will show their true length regardless of whether you stopped to stretch between your Fartlek intervals.

    FIT files

    Uploads from .FIT files - which are the native format of most newer Garmin devices like the 910XT, Forerunner 620, etc. - do contain pause events.  There are two ways for those to be recorded; you can enable Auto-Pause on your Garmin, or you can manually pause and resume your run by pressing the button on your device.  If there are no recorded pauses detected in the file, Strava will process your activity for resting time just as described above for other file formats that do not contain pause events.

    If there are pause events in your .FIT file, we simply remove any time where your Garmin was paused from your Elapsed time to come up with your Moving time - which should be the same as what you saw on your Garmin when you finished your run.  Because of this, you can also refer to this as your device's Timer time - since it is created by treating your Garmin essentially as a stopwatch.  However, there is one potential use case that could cause some confusion. 

    Because we are treating your 'timer time' as your Moving time, if you only pause your run inconsistently over the course of the activity, you might see some confusing results.  For example, if you manually pause your run for most - but not all - of your stops, Strava will detect those pause events and treat your Garmin as a timer - effectively 'trusting' what your Garmin is telling us; that the only resting in your run took place when you paused your Garmin, and you were exclusively running when it was not paused.  Because that isn't truly the case, your Moving time - since it is based on 'timer' time - will actually include some stopped time; the stops where you didn't pause your Garmin.  As a result of this, the Pace information for your run will be based on what is effectively inaccurate data.

    In order to prevent this, it is crucial that you use the pause (or autopause) function on your Garmin device consistently - either pause it at every single stop; or at none.  In either of these cases, the 'timer' data read by Strava will result in an accurate calculation of Moving time.

    the iPhone and Android app

    Information on using auto-pause on the Strava app, or turning it off, below:

    iPhone - auto-pause

    Android - auto-pause

    Having issues with Auto-pause?

    0
    Acciones de comentarios Permalink
  • Hello,

     

    OK, here is an example of the problem.

     

    I've created a new Strava account to upload some files to: https://www.strava.com/athletes/10125186 as I didn't want to fill my own profile with duff information, you'll note the email address of the new profile is similar to my name.

     

    There are 4 main activities that I've uploaded:-

     

    17-JAN-2015: https://www.strava.com/activities/340781539

    Original source file: http://www.greenbank.org/strava/2015-01-17-09-10-42.fit

    Comments: This is the original .fit file from a 5k parkrun. During the run itself I did not stop, however I was in the middle of the pack at the start so the first few seconds I was walking/jogging as there was not much space amongst 300 other people, but after those first 5 seconds I was running throughout, no stops, no slowing down to walking pace, running at 10kph or more. My official Parkrun time for the run was 26:01 which matches the length of the .fit/.tcx file perfectly. At no point during the run do I hit start/stop/pause. I simply start it when the starter shouts "Go" and stop it as I cross the line.

     

    18-JAN-2015: https://www.strava.com/activities/340781542

    Original source file: http://www.greenbank.org/strava/2015-01-18-09-10-42.fit.tcx

    Comments: I converted the above .fit file to a .tcx file using the Fit2Tcx utility, and I changed each date within the file from 2015-01-17 to 2015-01-18 so that it would upload as a new activity. No other modifications were made.

     

    19-JAN-2015: https://www.strava.com/activities/340781540

    Original source file: http://www.greenbank.org/strava/2015-01-19-09-10-42.fit.reformat.tcx

    Comments: I reformatted the .tcx file to make each trackpoint on a line by itself (makes further manipulation easier). I also changed each date in the file to 2015-01-19 so that it could be uploaded as a new activity rather than being detected as a duplicate of another.

     

    20-JAN-2015: https://www.strava.com/activities/340781546

    Original source file: http://www.greenbank.org/strava/2015-01-20-09-10-42.fixed.tcx

    Comments: In this .tcx file I removed all trackpoints that did not have GPS positional data. There were 5 such points ("grep Time..Altitude 2015-01-19-09-10-42.fit.reformat.tcx" will show them). I also changed each date to 20-JAN-2015 so that it would be a unique activity.

     

    The first 3 files uploaded all have a "Moving Time" value of 25:50, and an "Elapsed Time" of 26:01. It's the "25:50" Moving Time that I believe is incorrect, because...

    The 4th file (with the points that don't contain positional information removed) has a "Moving Time" of "25:56" and an "Elapased Time" of 26:01. This is the "Moving Time" value I expected.

     

    So removing the points that no positional information makes the "Moving Time" value more accurate. It is this that makes me think that Strava assumes that points with no GPS information confuse the stop/rest algorithm into thinking that I was stopped, which is not true as I was running the entire time after the first 5 seconds of walk/jog (the points with no position information are not at the beginning of the run, the first is 1.2k in to the 5k).

     

    I tried removing positional information from more points (every 10th point, see the 21-JAN-2015 upload) but that didn't seem to make it any worse ("Moving Time" was still 25:50), so it must be something to do with the "stop/rest" algorithm and those original 5 points with no positional information, they must be just in the right place to tip it over to thinking I was stopped. I would continue to play around with it to see which points cause the problems, but I don't have the time to mess around with this right now.

     

    I'd also bet that if I performed some interpolation and filled in the missing GPS positional data on those 5 points that the stop/rest algorithm would not assume that I had stopped. I may give this a try with further uploads.

     

    But, to summarise, I would consider the algorithm flawed if the presence of trackpoints with no positional data makes it think I was stopped when removing those trackpoints fixes the problem.

     

    I'm sure it may be that the Forerunner 110 loses GPS lock at these times (the parkrun goes through some heavily wooded areas) and is logging points without GPS positional data but, again, I can show that by not giving these points to Strava it will do the right thing, but including them and it thinks I was stopped when I wasn't.

     

    Thanks, -Alex

    0
    Acciones de comentarios Permalink
  • Ok, further analysis (and uploads) shows that I only have to remove the 1st point that doesn't have positional data to correct the "Moving Time" to 25:56, removing any of the 4 others makes no difference (moving time remains as 25:50).

    So, what is special about the first point. Here it is, along with the point before/after it, in CSV:-

    #Time,latitude,longitude,altitude,distancemeters,hr,speed
    2015-01-19T09:17:00Z,51.44391244,-0.2233819943,60.4,1227.3,168,3.054
    2015-01-19T09:17:06Z,,,60.4,1232.44,168,3.567
    2015-01-19T09:17:09Z,51.44417689,-0.2233051322,60.4,1252.28,168,3.805

    Aha, the DistanceMeters attribute of the second point has only moved on 5.14m from the previous point in 6 seconds, and I guess Strava is using this in the absence of GPS position information and considering that as slow enough for a stop.

    The subsequent point (when it does get a lock again) shows it catches up:-

    speed=4.52 in 3 d=1227.3
    speed=0.86 in 6 d=1232.44 NOPOS
    speed=6.61 in 3 d=1252.28

    Note that 6.61m/s is quite a pace (23.796kph, or 2:31/km!). I wish!

    The other points where it loses GPS signal don't cause quite such an erroneous value:-

    speed=3.51 in 5 d=2160.16
    speed=1.42 in 6 d=2168.7 NOPOS
    speed=4.45 in 5 d=2190.96

    speed=3.46 in 6 d=2753.62
    speed=1.71 in 4 d=2760.46 NOPOS
    speed=5.35 in 4 d=2781.87

    speed=3.07 in 5 d=2950.05
    speed=1.09 in 5 d=2955.51 NOPOS
    speed=5.30 in 5 d=2982.03

    speed=3.76 in 1 d=3006.74
    speed=2.03 in 6 d=3018.89 NOPOS
    speed=4.70 in 4 d=3037.68

    So, 1.42m/s, 1.71m/s, 1.09m/s and 2.03m/s respectively, and I guess these aren't slow enough for Strava to think I've stopped.

    I can test this by taking my original .tcx file and modifying the DistanceMeters values for the other 4 points that don't have positional info so that it thinks I was travelling slowly at this time...

    OK, 2015-01-28 now has these 'speeds' for the other 4 points:-

    speed=3.51 in 5 d=2160.16
    speed=0.92 in 6 d=2165.7 NOPOS
    speed=5.05 in 5 d=2190.96

    speed=3.46 in 6 d=2753.62
    speed=0.71 in 4 d=2756.46 NOPOS
    speed=6.35 in 4 d=2781.87

    speed=3.07 in 5 d=2950.05
    speed=0.89 in 5 d=2954.51 NOPOS
    speed=5.50 in 5 d=2982.03

    speed=3.76 in 1 d=3006.74
    speed=0.69 in 6 d=3010.89 NOPOS
    speed=6.70 in 4 d=3037.68

    If all 4 of these represent slow enough distance gains (based on DistnaceMeters) then we should see a further 6+4+5+6 = 21 seconds knocked off the moving time.

    Uploading this file (http://www.greenbank.org/strava/2015-01-28-09-10-42.slownopos.tcx) I see:-
    https://www.strava.com/activities/340814980

    And the moving time is down to 25:35, so 15 seconds further off. So I'm guessing the 0.92m/s of the point at DistanceMeters=2165.7 wasn't slow enough as we're 6 seconds short and this was the point that represented the fastest intermediate speed (based on DistanceMeters change).

    Let's take 1 meter off that distance gain and see what happens, now that point is:-

    speed=3.51 in 5 d=2160.16
    speed=0.76 in 6 d=2164.7 NOPOS
    speed=5.25 in 5 d=2190.96

    Uploading this file (http://www.greenbank.org/strava/2015-01-29-09-10-42.slownopos.tcx) I see:-

    https://www.strava.com/activities/340816593

    Bingo. Moving time is now 25:29.

    So the "not moving" threshold is somewhere between 0.89m/s and 0.92m/s.

    And this is the crux of the problem. Strava is relying on inaccurate DistanceMeters data in the file (inaccurate because there is no solid GPS fix at the time because the GPS position data is not logged) and then running its moving/not-moving algorithm on these data.

    It should be possible (for the algorithm) to disregard occasional points where there are no positional data, and/or look ahead to the next point (with positional data) and see if the pace from the previous point is much higher (which would indicate the previous DistanceMeters value is likely inaccurate).

    Also, it's ignoring (possibly for other reasons) the "Speed" attribute values in the tcx file. They were consistently above 2m/s for each of the points that had no GPS position. I'd have to look at a file for a run where I did stop to see what happens at these points compared to speed computed from changes in DistanceMeters.

    So, yes, the device is logging inaccurate data, but it's doing so in a way that should be easily detected by Strava and corrected for.

    0
    Acciones de comentarios Permalink
  • The moving time algorithm is not working at all and making every single stat on the Strava pages all wrong. I do a lot of trail running and I don't stop at all on my runs, yet Strava thinks I did for four, five even ten minutes. It throws off every single functionality on the Strava pages. I can change the type to to Race but that only fixes the issue on the overview. All the other places, splits, comparisons and on and on all using the so called "moving time".

     

    I cannot in my wildest imagination think why anyone wants the "moving time" feature. If I did stop for a minute, that is a rest and changes the whole characteristics of the run. Now I can run for 100 feet, take a five minute break, run another 100 feet and so on and get amazing records after five miles of that. But I don't' stop at all and Strava insist I keep doing that minute and minutes of stops.

     

    Even worse, my run last week was 1:51 hours and today 1:50 hours. I shaved off a minute, yet Strava and all comparisons and calculation thinks my time was better last week as it decided I was moving less last week. I never stopped and ran the exact same route. How can I have been doing better last week when I came back a minute faster today!!!!???

     

    Please remove the moving time thingy all together or at least supply a way to disable it. It's making the whole usage of Strava completely utterly useless.

    0
    Acciones de comentarios Permalink
  • Yes... for one thing, it has bugs (saying we stopped while we are running at a good speed) on particular devices such as the Forerunner 110.  Strava 'engineers' simply cannot figure out how to fix this, although the issue has been documented in great detail by some technically able people on this thread.  And secondly, many of us do not want the feature, even if it could correctly detect that we stopped.  If I stop to open a gate or get over a stile, I do that as fast as possible and do not want to count it as stationary time.  Both of these problems would be solved if we could simply have the option in our user settings, or on the 'upload a run' page "Auto Stop Detection : YES / NO" so we can switch it off.  Is that really so hard to do?

    0
    Acciones de comentarios Permalink
  • Consider two runners that run the same route. One of them stops frequently and makes long stops but runs fast between stops. The second runners runs slower but without stops and finishes the route faster than the first runner. Guess which runner will look better on Strava?
    In all seriousness:
    1) I've seen this happen
    2) Strava makes me lazy. I can stop whenever I like to rest and lower my HR knowing that I'd still look pretty darn good to my followers in the report. After all, nobody ever looks at the elapsed time, right :-)
    0
    Acciones de comentarios Permalink

Iniciar sesión para dejar un comentario.

¿No encontró lo que buscaba?

Nueva publicación