[PacePro] How broken is pace pro with elevation (e.g. Trailrunning)?

PacePro first flat kilometer: 8:47 min/km => Thinks route is roughly equivalent to 19.5 km flat.

Plot-a-route first flat kilometer: 6:24 min/km => Thinks route is roughly equivalent to 26 km flat.

Anybody who has ever done anything similar to 17 km with 1360m gain will attest to you that it is significantly more than a 19.5 km flat :D.

Hi Fredderic!

Even though PacePro is unrealistic with its paces in mountainous terrain, I'm not sure if that's its biggest issue. I'm also not sure if PacePro's programming is associated with our position on the track rather than distance covered; I believe it's more likely the latter.

In any case, I think pace and split time planning in trail running makes sense between aid stations or significant points, not kilometer by kilometer, or altitude changes. 

Based on the above, I suppose PacePro can be useful in a marathon, and it was probably created with that purpose in mind. 

I would be satisfied if Garmin's AHD/BHD field didn't reset every time we slightly deviate from the track...

On the other hand, I'm a bit surprised by the pace differences between PlotaRoute and your actual pace. In my case, I have it fairly well calibrated. If you could share the track of your route with me (for example, using the link to PlotaRoute), I can play around with the paces for a while.

Strong agree on not resetting the ahead/behind field for any "off-course" warning, it is almost impossible to never receive this off-course warning on a more complex trail run, and it negates the use of the virtual pacer.

Pace-Pro actually has a setting to go by climbs instead of every kilometer, which you point out correctly is probably more sensible for pacing in a trail race, but for simplicity I just posted the kilometer splits, as I want to highlight how badly wrong the assessment is for the very steep uphills and also for the flats in comparison.

I agree that plot-a-route could definitively be fine-tuned to show much better results for me for this course - much of the "too slow" kilometers on the end are because of the "steep downhill penalty" that plot-a-route has, but the ski-slope is simply too runnable even at 20% down-hill grade ;). I wanted to show a route where plot-a-route is not having a easy time either, to give the gamin predictions any benefit I can think of, and to show that even then they are wildly worse.

did you see that now It's possible to edit manualy the pace in every segment?

do you know what happen if you lost the track for a few meters with the programed pace? Are the programed pace change points geolocated on the track? or linked to the distance traveled?

Fredderic

What did you choose for Splits? If you chose Every Mile, can you change it to Elevation Based and test it out?

How are you doing, mates?

I've been doing some tests with PacePro, and here are my conclusions:

Field Test: I didn't encounter any issues with PacePro

• When you stop and the autopause kicks in, both the pace in the segment and the AHD/BHD stop as well. When you resume running, both fields start working again.
• If you ever lose the signal or the track, both fields will stop working. When you return to the track, PacePro updates AHD/BHD, remaining distance of the segment and programmed pace, based on your position relative to the original plan.
• So, at least in this test, it has worked correctly.

Design Test: At least for me, in my trail runs, it's not useful yet.

• I'm not sure why, but when converting an activity into a route, approximately 15% of the elevation gain is lost. The quality of the altitude profile is reduced, so the distribution of intervals based on changes in slope is not faithful to reality.
• The pace calculation for uphill sections is overly optimistic, even when selecting the minimum effort value. Conversely, the pace for downhill sections is too conservative.
• Being able to manually edit the pace of each interval is a great improvement, but it would be even more useful if we could also manually modify the length of each interval.

Here are some improvement suggestions:

• Personally, I prefer to plan my runs based on aid stations or specific points such as high points and low points. So it would be very helpful to be able to manually select the start and end points for each interval.
• For determining the pace of each interval, I find the method used in PlotaRoute more useful. It involves starting with the flat pace and penalizing it based on the incline for uphill sections and downhill sections separately.
• It would also be useful to integrate a waypoints view on the map and profile, as well as being able to dynamically see the time of passage for each waypoint as the parameters of PacePro are modified.
• I'm not entirely sure how the ETA at Next or Time to Next fields work when navigating a track with PacePro, but they should be consistent (fix: I have checked that the ETA at Next, Time to Next do not match the expected pace from PacePro)
• Regarding the effect of stops on AHD/BHD, I don't feel prepared at the moment to define a specific behavior.

And that's all for today! Hopefully, you will keep improving.

Yes, I did see this. The points in the thread opening post are every 1km of the loaded track, but see below my response to Sierra for a re-analysis using the elevation based splits. Even with "Uphill Effort" slider set all the way to easy (as far as it goes!) the uphill still gets *severely* underestimated and suggests a time that is almost 30% faster than reality.

That difference is like suggesting to me in the flat to go 4min/km (my 10km race pace) instead of 6min/km (easy jog pace)

Hey carglp,

I filed a bug-report asking to not reset "time ahead/behind" every time there is a "off-course" warning: https://forums.garmin.com/beta-program/forerunner-965/forerunner-965---public-beta-bug-reports/i/public-beta-version-4-12/do-not-reset-virtual-pacer-on-off-course-time-ahead-behind-gray-arrow-on-map Maybe if it gets some upvotes it will at least be discussed :)