Run Power: Data Field

A single run field...with power.

Works with standard power meters, including running pods such as Stryd. [Garmin Running Power not supported.]

Supported devices
- All Garmin Connect IQ watches except Epix

Get Run Power from the app store: https://apps.garmin.com/en-US/apps/a054f515-576a-4a28-b8e5-87987ba737e1

Full Manual
Everything you need to know and all the latest info will always be here:
https://github.com/flowstatedev/ciq-runpower/wiki

Please use this thread for questions, comments and suggestions. I'd love to hear whether this field is useful and how it can be improved!

Features:

Power Zones
- All watches support 5 zones
- Most watches support up to 10 zones
- Customize zone names
Power Alerts
- Lap Power Alerts
- Structured Workout Power Alerts (not 735XT / VAHR / Approach S60)
- Custom Power Alerts (high/low)
- Zone-based Power Alerts
Color-coded Power/HR/Cadence (optional)
Custom colors for Power
6 fields
- Multiple layouts: https://github.com/flowstatedev/ciq-runpower/wiki/Data-Field-Layouts (Round watches, except Fenix 5S)
- By default, displays current Power, Normalized Power / Average Power, Time, Distance, Heart Rate and Power Zone
Literally 100s of metrics to choose from, especially variations on power (and normalized power)
- Easily select metrics by choosing phrases from 3 short lists. e.g. "Lap", "Maximum", "Power"
Define custom metrics with formula like "Power/HR"
Optionally records power to activity FIT file:
- Graph
- Lap Average and Maximum
- Activity Average and Maximum
Filters abnormally high power values [above 2000] to get around Garmin firmware bug which messes up your power stats

Feature support varies by device. For more information:
https://github.com/flowstatedev/ciq-runpower/wiki/Features

Available Metrics:

Any meaningful combo of:

Overall [current/total], Lap, Last Lap
Average, Minimum, Maximum, 3/10/30 second average, or none of the above
The following "base metrics":
- Time, Distance, Pace, Power, Power Zone, Efficiency Index, Efficiency Factor, Power/HR, Running Effectiveness, Speed, Cadence, Heart Rate
- Calories, Elevation, Ascent, Descent
- HR Zone, HR %Max, HRR%, %FTP
- Normalized Power, Normalized Power Zone, Intensity Factor

For example, if you're interested in power, you've got:
Current Power, Average Power, Minimum Power, Maximum Power, and 3s/10s/30s Power
Lap / Last Lap: Avg, Min, and Max Power

Full Change History: forums.garmin.com/.../51997

Top Replies

All Replies

cortizovizcaino over 5 years ago

Hello guys!

Whenever I start the running app using any average of the new metric "Running Effectiveness" (lap average, 3s average, 30 s average, etc), I get the IQ screen error in my Fenix 5x+. This error doesn't show if I just use RE with no average.

Am I doing some wrong? Does RE support being averaged?

Thanks for your feedback.

Happy new year! :)

FlowState over 5 years ago

Hello guys!

Am I doing some wrong? Does RE support being averaged?

I had a math bug, which is now fixed in the store with update 7.0.3. Thanks for the bug report.

In general, if a metric doesn't support being averaged, like Time, then Run Power just ignores what you asked for. For example "Average Time" becomes "Time".

TL;DR it's never supposed to crash. Especially the devices with large memory like Fenix 5X+. Fenix 5 and 935 shouldn't crash, but there's an outside chance if you have lots of lap alerts and lots of rolling-average metrics (even with the quota I put in.) Either way, please report any crashes. Thanks!

Also if you're curious, everything supports being averaged except:
Time,
Distance,
Calories,
Ascent,
Descent
Elevation (I guess this one is debatable),
Normalized Power / Intensity Factor (because this is already an average of a rolling average)

And everything supports min/max except:
Time,
Distance,
Calories,
Ascent,
Descent

FlowState over 5 years ago

JTH9 thanks for the info re: Stryd. Much appreciated! (Perhaps I was a tad too cynical earlier, but we'll see.)

cortizovizcaino over 5 years ago

FlowState , thanks for fix and info :)

FlowState over 5 years ago

One idea to test, with AppBuilder at this point, is to divide average, or lap average power, to uphill / downhill efforts. And see if this helps to better evaluate the difference in uphill / downhill effort.

I guess a really cool "stat modifier" would be "uphill / downhill / flat". (Similar to avg.). Imagine being able to see "uphill anything". Uphill time, uphill pace, uphill power.

This would require a reliable grade metric tho. Plus some fuzzy logic around the edges between flat, downhill and uphill. I guess it wouldn't be too complicated - flat could be defined as anything between +/- 0.5%, or something like that, but I just don't know what the threshold for "flat" should be. (Similar to the speed threshold for "moving" in Strava and Garmin.)

The great about AppBuilder is I don't have to take responsibility for the accuracy of the data :P.

But in a perfect world, "moving", "uphill", "downhill" and "flat" would all be stats modifiers. Probably won't happen tho, as the benefits would be really marginal. Sorta like "minimum" - there's very little use for that except for HR or perhaps "lap min" metrics, which is why Garmin doesn't even offer any "min" stats natively during activities..

OTOH, any of those could theoretically implemented today using the custom metrics....

alextran over 5 years ago

FlowState i think there's something off with the calculation of 3s RE. not sure if real-time RE is affected. didn't think to test that at the time. i saw values in the 150-185 range today when RE should be around 1.0. just as a recap, RE is calculated as follows:

speed / (power / weight) or speed * weight / power

also note the specific units required (m/s for speed, W for power, and kg for weight).

FlowState over 5 years ago

alextran gotcha. Thanks for the review BTW.

Sorry I had a bug with running effectiveness only for (***) watches, which is now fixed in the store. Side note: I really need a better way to talk about device/feature tiers >_>.

I understood the math formula, it's just a logic error that only affected certain watches, after I added Intensity Factor.

Just a little behind the scenes: in order to fit all of these features on all of the watches, I have to write some pretty hard to maintain code, with like 6 copies of the same thing in some cases. This is because Garmin dev tools don't allow you to write for multiple devices in the most efficient way possible. You can write for multiple devices in a way that's simple and easy to maintain, but uses too much memory. Or you can have like 6 copies of the same code and save memory.

This is obviously terrible practice, so I'm going to do a rewrite where I just have one copy of everything and use my own tools to generate the 6 copies in a way that this kind of manual error is much harder to make. But it'll take time to implement, and yes, test. I'll basically have to retest ALL the features on ALL the devices to make sure I didn't make a mistake in my rewrite.

I also have 6 device families to test, and TBH, they don't always all get tested. Not the best practice and something I'll have to get better at. No excuses there. (Well, there are issues with testing Garmin app settings that make simulated device testing of a full app very frustrating, but there are other ways to test....)

alextran over 5 years ago

alextran gotcha. Thanks for the review BTW.

Sorry I had a bug with running effectiveness only for (***) watches (and not (****) or (*****)), which is now fixed in the store. Side note: I really need a better way to talk about device/feature tiers >_>.

thanks for the fix! and np for the review. happy to give you one for all the work you've put into the data field. i originally heard about the field from someone posting in the stryd and palladino facebook groups. once i confirm RE is working on my 935, i'll post again in those groups since a lot of new features have been added since the original post i saw.

Just a little behind the scenes: in order to fit all of these features on all of the watches, I have to write some pretty hard to maintain code, with like 6 copies of the same thing in some cases. This is because Garmin dev tools don't allow you to write for multiple devices in the most efficient way possible. You can write for multiple devices in a way that's simple and easy to maintain, but uses too much memory. Or you can have like 6 copies of the same code and save memory.

it's surprising garmin doesn't provide a better framework for maintaining code on multiple devices.

FlowState over 5 years ago

it's surprising garmin doesn't provide a better framework for maintaining code on multiple devices.

What they provided is simple and elegant, unlike the solution I am going to use >_<. In fact, most languages don't let you do what I am going to do, which is to include/exclude code on a line-by-line basis, because it looks terrible, it's hard to understand and is therefore hard to maintain in its own way. But much more maintainable than what I am doing now, which is writing the same code six times, in slightly different ways.

Basically I am breaking a lot of the rules of good coding in order to pack as many features into watches like 935 and 230 as possible. If I could only develop for fenix 5+, then I could write the most beautiful, maintainable code in the world, but you'd have to spend a lot more for your watch to get any decent features from Run Power.

alextran over 5 years ago

alextranSide note: I really need a better way to talk about device/feature tiers >_>.

yeah, i'll admit using asterisks makes it a little difficult. for readability (so people don't have to count asterisks), what about something like Tier 1, 2, 3, etc.? then maybe you could put in your forum signature a legend defining them. in an ideal world though, it'd be nice having names that made it easy for people to know what watch family they're in without needing a legend.