This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

PacePro could be so much more

So I did my first race following a PacePro strategy. Despite other threads in this forum it worked quite well, once you came to terms with how creating and uploading a strategy works.

I am now planning my next race and since PacePro has been a major selling point for me, I can not help but notice, that for the money involved I expected it to be more than something you can re-create with a spreadsheet.

Here is in a nutshell what PacePro does in preparation of a race:

  • Analyse a given course and calculate split times depending on your desired overall pace or race duration.
  • Split times will generally speaking reflect slower paces for uphill splits and faster paces downhill.
  • Calculations can be adjusted in two dimensions:
    1) estimated effort it takes to run uphill (will increase the min/max range of paces, making uphills slower and downhills faster),
    2) overall positive/negative split (positive split will calculate splits early in the race faster than similar splits late in the race, negative splits vice versa).
  • Splits can be set in three different ways,
    1) create a split every 1km,
    2) create a split every 1mi,
    3) create a split before every significant elevation change (personally I find #3 the most useful, since it is the "truest" reflection of the elevation profile, yet other people might not be comfortable with odd splits).
  • The strategy will than be stored as a split table and can be synced to your watch.

That surely sounds like a helpful addition, but it's 2019 and we're talking about a device probably more expensive than your average smartphone. Reading through the lines of a static pre-calculated table is a pretty low bar for a flagship device, proudly introduced in front of the UTMB community.

So here is what I hoped my fenix 6 could do, what I think it is able to do and what I would love to see Garmin add to PacePro with upcoming updates:

  1. (Re-)Calculate splits dynamically.
    Every strategy goes out of the window on first contact with reality (e.g. the weather). So if the initial goal had been set to finish a race in 4 hrs, I may be well ahead or behind that goal after a few splits. The watch already displays the time deviation and an estimated finishing time, but it would be much cooler, if it would adapt the strategy, lightly increasing/decreasing upcoming split times to compensate for the "error".
  2. Adapt to performance
    Similar to 1., recalculate the strategy on the fly, but from a different angle. PacePro currently requires you to determine your strategy (see above, those 2 dimensions) ahead of a race but you might feel different for better or worse once you're at it.
    So instead of sticking to the set strategy, a constantly occuring deviation in target split time and achieved split time could influence the remaining strategy. For instance, constantly going slower uphill and faster downhill could be an indicator for setting the uphill effort too low. Or, if you're increasingly running behind your targeted split time you probably set a too optimistic negative split strategy which should be corrected.
    You could even go as far as to allow for the finishing goal to be corrected, maybe allow a percentage or absolute number of minutes that the strategy may deviate from the original goal.
  3. Learn from activities
    This is probably the greatest misconception I had about Garmin, the level of prediction their devices offer based on the data they gather.
    Instead of letting me guess how the function curve of split and uphill strategy would look look like to achieve my goal, this could be learned from my past activities and improvements.
    I bought the fenix imagining that it could at least do the work that I already did tediously with Excel and a lot less data.

Maybe I aimed a bit too high, but even in its current form, PacePro seems to be too "simple" to serve the purpose it advertises.
Other runners had related issues with the strategies.

  • Strategies seem to be limited in the total duration or distance, which seems counterintuitive when especially mountain races may take longer than similar distances on flat roads.
  • The slider that controls the effect of uphill effort doesn't go far enough, so minimum uphill paces are too fast (or vice versa, downhills are too slow).
    Walking uphill to conserve energy is not uncommon even among strong athletes, plus highly technical trails will slow that down even further.
  • Runners tend to split their races not only in distances or changes in elevation but also between aid stations.
    Maybe allow for waypoints in a gpx file to serve another split indicator

Again, maybe I just fell for my imagination when I read about PacePro, but there is real potential for something that makes impressive use of the existing data and computing power we carry around our wrists.

Just for good measure, here are some other threads I dug up on PacePro.
PacePro strategies not suitable for slower runners
forums.garmin.com/.../pacepro-strategies-not-suitable-for-slower-runners

Pacepro post-activity analysis
forums.garmin.com/.../pacepro-post-activity-analysis

Pacepro for Ultras Longer than 24:06:59
forums.garmin.com/.../pacepro-for-ultras-longer-than-24-06-59

  • Former Member
    0 Former Member over 4 years ago

    I use power instead of pace when planning my ultras. It's far easier to stick to a power output plan, i.e. 300w for the first half and 200w for the second. It's a fairly simple physics calculation that is needed to determine the ETA for the power v total average gradient, and it's a hell of of a lot simply to glance down to make sure you're still producing 300w whether youre hiking up that hill or sprinting down one.

    Now, if Garmin would only bring out "PowerPro" to make that simple calculation even easier :)

  • Totally agree it'd be nice to add a bit of smarts, or more customization.  It is a first generation product so hopefully it will be enhanced over time.  Releasing it to coincide with UTMB is kind of interesting, as it really doesn't seem suited for that kind of technical terrain, and as you say, doesn't deal well with walking.  Most of my running is trail with some fairly technical sections.  Those have as much impact on pace as the gradient and they clearly can't deal with that.

    Taking past activities in to account would be really tough.  That is something that could easily be handled by computers before downloading, but still gets extremely tricky.  That are too many variables from run to run.  I think to get more accurate than what it currently does, you'd have to spend a lot of time categorizing your past runs.  Many of my training runs I'll push much harder on the climbs than I would during a race for example.

    Totally agree it'd be nice to have aid stations, or other custom way points, incorporated in to the plan.

  • i would also let the end user edit the split value (and automatically adjust the overall time) regardless of terrain and so on. i know it's meant to be for constant running, but for some of the marathons - say barcelona for example that is pretty hilly on some sections - i would rely on previous experience rather than the generated numbers

  • Yes, that was my very first thought what PacePro would do, before I bought the Fenix: that you would load a track you are about to run, and while you are running it would estimate a more accurate ETA, based on how fast you tackle inclines and how much elevation gain/loss is still in front of you.

    Added bonus of course, if you would bei able to set your typical uphill pace in advance, but I thought of it as an analysis of how I am actually doing in this very race.

  • I thought the whole point of PacePro was what you cover in point 1. ie. if you're off target on the first split, it would adjust the remaining splits accordingly to the updated pace to meet the desired finish time. 

    I'm a bit disappointed it doesn't do this. I'm not really sure how to use it now.

  • Although I agree with you I have also more evident problems with PacePro.

    Top line is the proposed pace for the split. Afai experienced the second line is the actual pace even if the third line is a text “split pace”. 

    My other problem is that Time Ahead worked when I tested Pacepro with a plan created within GC web.

    Today I created a pacepro plan on my watch using a course defined in the very same way as earlier, downloaded to my watch in the very same way as always, but starting Pacepro did not give me Time Ahead at all. It was displayed always as  - - : - - during my whole run which took for appr. 142 minutes. So Time Ahead could not be zero for the whole run I am not a perfect pacer. :-)

    Is there anyone who says Time Ahead should have shown a value in spite of the fact that the plan was defined on the watch?

    Sidenote: the course navigating which was running also worked perfectly, not just the turning alerts were ok, but the time remaining (to nect turn and to the end) datafields were quite accurate, so no data were missing from the course, pacepro itself was buggy

  • Although I am still unpleased with the lack of Actual (=achieved by the runner until now) Split Pace data, to be fair I must share my findings regarding the non-functional Time Ahead datafield of Pacepro.

    If one defines a gpx in Mapsource, sends it to GC web, defines a course there and either there or on a watch he defines a pacepro plan it works. Both course navi and pacepro.

    If one defines a gpx in another place like mapy.cz in my case, sends it to GC web, defines a course there and either there or on a watch he defines a pacepro plan, then course navi works, but pacepro is just partly.

    Do not ask why! If GC is pleased with a gpx file to create a properly working course, it is a mistery what can be the reason which causes the malfunction at the pacepro-level.

  • Afai experienced the second line is the actual pace even if the third line is a text “split pace”

    I observed that sometimed this 2nd row is avg. split pace indeed. I guess in case when it is fluctuating wildly and seems to be the current pace the course is mishandled by F6x, which thinks that all the neighboring (track)points of the course define splits. I mean the first row is always ok, the target is correct, because it is a non-dynamic data saved at the time of pacepro plan creation, but the second row is a sort of dynamic data and it can go mad.

    In other words running a pacepro plan is a kind of sensitive function and one has to define his courses always in the very same way to minimize the chance of malfunction.