12

Average Lap pace (Read 150 times)

jpdeaux


     I think we'll find that the current behavior of using the "elapsed time" (aka calendar time) rather than the "activity time" ("moving time" in Garmin-speak) in the splits is not intended....it showed up in this release of the log.

    I believe this behavior (sometimes calculating on calendar time) has been hidden there for a while. It was accidentally "revealed" some time ago in a release, then fixed. You can see that it is still there by using the Manual Laps button on a View Workout page (which formerly showed as a gear icon at the top of the laps column in the old layout).

     

    Click View Workout, then Manual Laps (button on the right)

    Change Split Distances to .999.

    The Pace column now calculates on calendar time.

     

    If you stopped your watch any time during the run, then the pace will be significantly different within that split.

     

    Not sure this moves the line graphs discussion forward much. But wanted to clarify what I believe is behind the scenes with respect to the calendar time.

     

    Hey, speaking of seismographs, has anyone ever run during an earthquake? Did your elevation change? Did the earth move?

      Average lap pace is useful to see on your Garmin; I have it on my main screen. Seeing a graph of afterwards I'm not sure would be so useful. Why do you want to see all the numerical artifacts damping down from noisy to smooth? That's a reflection of sampling noise, not anything relevant to your running.

       

      I think want you want, to avoid the super-noisy instantaneous pace plot, is averaging of that data. And you can get that on RA. In your graph, see the box that says how many points to average? Play with that.

       

      Also if you do want to write your own software, there is an RA API; you can access your data that way and do whatever you want with it.

       

      The visual damping from noisy to smooth does indicate how far one needs to be into a lap before the average pace starts becoming meaningful.  That could be useful to know because it may differ in different environments, i.e. straight path vs  track vs overhead vegetation, etc.

      bhearn


        Well. That's pretty obscure. Also you're assuming that you can extract the value the Garmin displays from the raw data. Probably they use some proprietary heuristics.

           

          The visual damping from noisy to smooth does indicate how far one needs to be into a lap before the average pace starts becoming meaningful.  That could be useful to know because it may differ in different environments, i.e. straight path vs  track vs overhead vegetation, etc.

           

          But...you already know it differs in different environments. Why would seeing that in a graph be useful? Sounds like graph porn to me. Like, you live it, and then you go back and look at the graph, and you're like "oh, yeah, baby...graph me. Graph me again!"

          Come all you no-hopers, you jokers and rogues
          We're on the road to nowhere, let's find out where it goes
          eric :)


             

            Make any sense?

             

            Hi RVDowning,

            I can only assume that you bumped this thread because you wanted my response.

             

            I agree that the graphing the raw data is not too meaningful due to the noise in the GPS data.  This is why the data is smoothed out using a 15 point moving average. If that is still too "seismic", you can always increase the number of points.

             

            You have not explained why a convergent graph is superior to a moving average.  What does it mean to have the graph converge to the average lap pace 90 seconds into a 270 seconds lap?  Doesn't such a graph hide the fluctuation toward the end of the lap, which is just as important if not more so?

             

            You are assuming that all laps are run in a controlled environment such as on the track.  In reality, most runs occur in streets and trails, where the surface is rarely flat and the pace is a consequence of elevation changes, wind speeds, and surface conditions.  While your graph may make sense to you, you are in the minority.

             

            It is possible that I do not understand the value of your graph.  If I'm being obtuse, please explain it some other way.

             

            eric Smile

              ..

              Hey, speaking of seismographs, has anyone ever run during an earthquake? Did your elevation change? Did the earth move?

              Almost - today. I was putting shoes and socks on when a 5.8 about 95 miles west hit and gave the house a good shake. I did not run across the rock slide area today. (This is after major fires last week about 50mi from here. All we need now is a flood.)

               

              A number of years ago, we were digging potatoes when an earthquake hit - it was like being on a rolling water mattress and you could see the ground move.

               

              And of course, there was the 1964 earthquake where ground dropped a few feet, I believe. And a smaller one in 2003 dropped some roads.

               

              I think they said Everest moved, but didn't shrink during its last earthquake.

              "So many people get stuck in the routine of life that their dreams waste away. This is about living the dream." - Cave Dog

                 

                Hi RVDowning,

                I can only assume that you bumped this thread because you wanted my response.

                 

                I agree that the graphing the raw data is not too meaningful due to the noise in the GPS data.  This is why the data is smoothed out using a 15 point moving average. If that is still too "seismic", you can always increase the number of points.

                 

                You have not explained why a convergent graph is superior to a moving average.  What does it mean to have the graph converge to the average lap pace 90 seconds into a 270 seconds lap?  Doesn't such a graph hide the fluctuation toward the end of the lap, which is just as important if not more so?

                 

                You are assuming that all laps are run in a controlled environment such as on the track.  In reality, most runs occur in streets and trails, where the surface is rarely flat and the pace is a consequence of elevation changes, wind speeds, and surface conditions.  While your graph may make sense to you, you are in the minority.

                 

                It is possible that I do not understand the value of your graph.  If I'm being obtuse, please explain it some other way.

                 

                eric Smile

                Eric,

                 

                No, I wasn't really looking for a response.  Just replying to a previous post.  I didn't really expect it to be done in RunningAhead, but thought I'd at least present the idea to the forumites.  Looks like the developer at Final Surge might be interested.  I have to use that site anyway because that is where the Hansons' coaching service that I use puts its training schedules.  GarminConnect can automatically forward uploads to that site also.

                 

                Plus, I may write a small standalone to do the same thing.  Just as an exercise I could try to do it with VBA in Excel, although the thought of using VBA gives me hives.  I'll probably just use a Linux scripting methodology to create an output file suitable for spreadsheet graphing.

                 

                To answer questions of yours, a moving average approach doesn't work well for intervals.  It is fine for a steady state run, but when one is doing intervals or progression drills then there really isn't much differentiation between those lap segments.  Most people I know prefer to do intervals on a track.

                 

                When doing long runs or marathon pace runs they are usually run at the same/similar locations week after week, so graphs can be of interest for comparing one run against another under similar conditions.

                 

                I think the bottom line is that the "meaninglessness" of the instant pace graph has always annoyed me, and I think that better approaches may be available that could make lap segments more meaningful.

                 

                Anyway, we can consider this case closed.

                 

                Rich

                12