Pacing for Trail/Mountain: PacePro unusable, VirtualPacer keeps resetting

The best pace metric for trail running with ups and downs, even with the limitations it has,  is running power

Sure, I can use running power (or heart rate) to pace my current effort, but that does not help me judge my situation against my goals. Am I on "PR-Split"? How many minutes before/behind my target am I if I want to reach a certain goal time? These questions are not answered by running power, these questions should be answered by VirtualPacer and PacePro, if either of them were usable.

If you could estimate what average watts you need to keep, to finish the race at a specific time, you could compare your current average watts to that number.

This is a decent idea, if you have a reliable source of running power AND some way to estimate the power needed for your desired finishing time.

But in all honesty, PacePro should be able to quantify the effect of elevation properly, this is just a matter of adjusting the formula...It is not rocket science, see here how it is done in plotaroute:

The same formula should also apply to the default "Virtual Pacer" added when you plot a course, making a pacer that actually slows down on uphills.

Here is some scientific literature about the way elevation effects speed in for hill runners:

https://repository.lboro.ac.uk/articles/journal_contribution/Pace_and_critical_gradient_for_hill_runners_an_analysis_of_race_records/9387719

I do not understand how Garmin has put out a "PacePro" feature that spits out humanly impossible (past world-record) suggestions on steep uphills, even when tweaked for "easy uphills" to the maximum of its setting range. The feature was introduced 2-3 years ago, so there was plenty of time to realize this issue.

Yes, it's really hard to understand why they haven't fixed the PacePro in this time as the fix seems pretty simple, allow more adjusting in the slider, that would itself do a lot already, then to be like PacePro v2 allow more tuning, eg. for uphills and downhills separate.

Exactly! More slider room would already make things usable! Putting a better formula would help even more, e.g. copy one from that paper I linked. Also this affects all kinds of Garmin Devices (not only the 955 has PacePro), so it would make a lot of sense to invest some developer time here, as the benefits are to a larger user base.

Same thing for VirtualPacer resetting when using Navigation: I can find complaints back 2 years from Edge users when they first broke this feature by adding the resets, but it was not fixed since - again not a hard or expensive fix...let that VirtualPacer continue on even when leaving the route. Funnily watches without Maps, such as the Forerunner 935, have superior VirtualPacer, since they do not reset when you leave the loaded breadcrumb route.

(1) This app is about showing a grade adjusted pace, which is not the same thing as showing my overall progress in relation to a time goal during a race

(2) The author of this app states that "so I use a Stryd instead and stopped working on this.", so this app is dead!

Another option regarding trail running pacing would be to use the power calculator below:

https://www.alancouzens.com/blog/Run_Power.html

I haven't use it yet due to my detrained/excess weight status, but i plan to test it in the future in the following way:

1 - i will run a known route with some elevation and record it, along with the power that garmin or my running power gadget, records

2 - i will put: weight, distance, elevation gain, time in the calculator and see what the estimated power is.

3 - i will compare my garmin/gadget power to the calculator power.

4 - i will decide the difference between the calculator power and my garmin/gadget power.

5 - i will put the data of a race or training route in the calculator along with the desired finish time and get the average watts i have to keep to meet the desired time

6 - i will adjust to estimated watts according to my previous test.

7  - i will run the race or new training route on the adjusted watts and see if my calculations are correct.

(I'm sorry for my English, Google Translator indeed)

Here are some ideas that may interest you:

First I establish the strategy of rhythms and step times with PlotaRoute. Also in PlotaRoute I include in the route several waypoints in strategic places. In the description of the point I include the scheduled time of arrival, something like "0h50 River" (including stops).

On the watch screen I place the "Elapsed Time" field; so when I reach the next waypoint I compare the scheduled time with the elapsed time.

In order to measure my performance I have programmed the following field with "Data Field: AppBuilder":

ETE AT NEXT | AHD/BHD = ((distanceToNextPoint/(lapdistance / laptime))+ElapsedTime) /60 + ' | ' + (ElapsedTime - (390*(Distance + 0.0107*TotalAscent + 0.0032*TotalDescent)))

where "ETE AT NEXT" shows the arrival time at the next waypoint based on the lap pace. In this way I can compare in real time the estimated time of arrival at the next waypoint (f.e. "0:43") with the scheduled time ("0h50 River")

where "AHD/BHD" shows the difference between the elapsed time and the theoretical time calculated with the same criteria that are entered in PlotaRoute, based on the distance traveled and the elevation gain, both positive and negative. If there were no differences with the planned ones in the route it should be "0:07"

At the moment there is no other better way to do it with "Data Field: AppBuilder"

Finally, to see the programmed pace you can create a workout based on the distance between waypoints and the pace of that interval (via excel sheet). The drawback is that when you stop the time at the watch does not stop and the current pace is calculated incorrectly.

I hope I have helped you

In any case, Garmin should allow users to define the intervals and the pace of each interval in PacePro; that way it would be more useful