Wrist-based running power for Garmin watches

RunPowerModel is a wrist-based running power meter for Garmin watches, in the form of a data field that integrates seamlessly into your existing activity profiles. And before you start wondering, it is for free!

RunPowerModel is recommended by Scott Johnston, author of Training for the New Alpinism and Training for the Uphill Athlete (the latter being co-authored by Kilian Jornet) and founder of Evoke Endurance. If you want to know more, have a look at episodes #28 and #30 of Evoke Cast, where Scott and I talk about running power and how to use it for training and racing, as well as this article from Scott about training metrics.  

Advantages of RunPowerModel

Appearance of RunPowerModel on the watch. It is shown as a data field, just as all the other key output.

Appearance of RunPowerModel on the watch

It was designed and tested to work under and automatically adapt to various conditions, including uphills and downhills of arbitrary inclination as well as technical trails. While many other solutions fail to provide reasonable results on uneven terrain, RunPowerModel is specifically designed to calculate meaningful power numbers also under these circumstances. 

For runners who also cycle and know their corresponding power output, the values calculated by RunPowerModel are directly comparable to those.

Of course, the Power is not only shown on the watch display. After finishing an activity, you get detailed power-related workout statistics:

Output of RunPowerModel after finishing an activity. You get the power and the trail score as graphical output, together with statistics such as the Normalized Power or your Equivalent Flat Pace of the run.

As already mentioned before, RunPowerModel is not only designed for those who like to run on the streets but especially also for trail runners. It even assesses how technical your trails were. This Trail Score is unique to RunPowerModel.

Illustration of the behaviour of the trail score. It yields higher values on technical trails.

Just as it should be, RunPowerModel is fully customizable via its app settings. You can

Download RunPowerModel today from the Connect IQ store!

The Physics Behind RunPowerModel

There is no common standard for calculating a runner's power. Different running power meters rely on different inputs for their calculations, which can only capture a small fraction of the overall rather diverse running process. There are several approaches on how to combine them into a power number, and different power meters can thus yield largely deviating results.

The algorithm behind RunPowerModel corresponds to a self-developed semi-analytical physical model. This means that the components behind the final power number are all physically motivated, but some of its parameters are adjusted to yield reasonable results. The calculated number is designed to correspond to the mechanical power output provided by the athlete's metabolism, which is directly correlated with the body's metabolic effort.

The total power as calculated by RunPowerModel consists of the following individual components:

The following diagram gives a few examples of what RunPowerModel's output looks like in various cases:

Total exerted Power for different running conditions and athletes as calculated by RunPowerModel's algorithm. It gives reasonable values for various conditions, including flat, uphill and downhill running, technical terrain as well as sprints.

Running vs. Cycling Power - How Should they Relate?

As mentioned above, there is up to now no agreed standard on how to calculate running power. This stands in contrast to cycling where the major fraction of mechanical power ends up in the pedals, which can be measured. Since running and cycling are generally biodynamically different sports, it is often said that the power output of these two sports at the same metabolic effort can be quite different. And while some discrepancy is surely natural (also varying from athlete to athlete), I'm actually convinced that a running power algorithm that's adapted to work under different conditions should provide numbers similar to those on the bike. Why?

The biomechanic discrepancies between running and cycling get smaller during uphill running, and speed-hiking (without poles) at larger inclinations is actually quite similar to it. Just like when going up stairs, the leg movement and involved muscles are not that different. Given this large overlap between the sports under these conditions, some difference (let's say at the 10% level) is probably reasonable, but not much more. 

Okay, so much for speed-hiking and uphill running, but what about the rest? The answer to that is consistency. A power meter should ideally give consistent results for the same metabolic effort under different conditions - if it does not, then it's automatically correspondingly less trustworthy.

RunPowerModel FAQ

Could you also offer a multi-field data screen in addition?

I'd love to offer this option, but at the moment this would make it necessary to have several versions of the app on the store (like some other developers do for their apps), which I'd like to avoid for many reasons. What I'm ultimately hoping for is that Garmin will at some point enable different apps to connect with each other. That way, one could have the main RunPowerModel app which does all the calculations and file writing, and then I could offer several additional "slimmer" fields (power gauge, multi-screen etc.) which simply access the results of RPM. This has been requested by 3rd-party developers long ago. Although there came a decline from Garmin's side, I haven't yet given up the hope on that.

It'd be great to see the power values displayed on a gauge scale, could you add an app for that?

Same as above for the multi-field data screen. I'd love to, but I don't want several instances of the app on the store.

What are the reasons for not offering different versions of the app on the store?

There are two main reasons for that:

Does RunPowerModel also work on treadmills?

In principle yes, but at the moment it will always assume a gradient of 0%. I'm working on solutions to improve that. Thanks for being patient!