Any interest in a PR for a Power Match feature

[MattCost]

Hello,

My trainer is annoyingly off by anywhere from 10-20% compared to my power meter while using ERG mode. I could do all my workouts in Sim/grade mode, but I love the ability to zone out during base rides without having to keep an eye on my output. I know I could change the FTP on the settings page before workouts, but I prefer a set-and-forget approach. I'm also not sure if my trainer is off by a set amount, or if it varies based on temperature.

I created a rough outline of how we could implement a power match feature for erg mode steps. This code is not DONE, the watch:lapTime in particular needs to be worked on. I just wanted to share this approach before I get too far in case you already have an implementation in mind or suggestions for a better way to do it.

Here is a comparison

• Added 10second power.
• Added an Adjusted Power Target.
• Added a setting to enable/disable Power Match
• Added various vars to db for state tracking of power match.
• Updated the watch:stepIndex callback to deal with enable/disable of power match based on workout targets
• Added a watch:lapTime callback to implement PID adjustment of power target to reduce error
• Power Target is now all "internal" and Power Target Adjusted is sent to a connected device. If power match is not active, then power target is copied to power target adjusted. If power match is active, then PID control is used to adjust the actual power cmd sent to the trainer.

Open to any and all suggestions on how/where to place the logic for the power match function, or deal with any of the basic plumbing of vars. I'm not sure I fully understand how xf.sub and xf.ref work.

[dvmarinoff]

Sure, most definitely there is an interest! I am very short on time this winter, but will try to review it as soon as I can get the opportunity. Thanks for your work!

[MattCost]

I came across someone else's attempt at a power matcher, and I like their approach to the "plumbing" a bit better. They created a new class and sub'ed to the power and powerTarget vars to react at the appropriate times, instead of reacting every second.
I'm going to re-structure this a bit cus I feel like it would be cleaner, testable, and easier to expand in the future.

I was able to test for 1 ride so far and it worked great. I learned my trainer reads ~34 watts high when actual power is in the 50-160 watt range. Plan to test with some higher level intervals in the coming weeks.

Let me get the code changed a bit before you spend anytime looking at it. I will let you when I've done that.

[MattCost]

@dvmarinoff
Okay, first an embarrassing confession. I spent a few days working on this because I was frustrated with my trainer reading 30-35 watts off. It turns out my trainer is good enough, and I had forgotten to offset/calibrate my power meter via my garmin head unit in quite some time.
After calibrating my PM, the trainer and PM agree within 10 watts, which is close enough for indoor training. My last round of testing did show that with PowerMatch enabled, the power appeared to be right on target via the graph, and slightly under target with it turned off. It's harder to tell looking at average power after the fact. So I don't even know if I need this feature now.

I have an updated approach in a branch called add-power-match. Comparison here

• Added 10s power avg to GUI
• Added target power line to graph
• Added enable bit for Power Match to settings.
• Added powerTargetTrainer to the db.
• ANT and BLE devices now subscribe to changes to powerTargetTrainer. The existing powerTarget is now in-app only
• Added a PowerMatch class which subscribes to power1s, powerTarget, and various watch events.
  • Calculates internal 10s averge (we want to update pid loop every 5 seconds, and can't wait for apps 10s reading to come in every 10s)
  • When disabled, sends powerTarget unchanged to powerTargetTrainer
  • When enabled + active, adjusted the powerTarget before sending to powerTargetTrainer
  • Updates powerTargetTrainer every 5 seconds based on PID loop.
  • Has ability to apply constant offset and scale for trainers with known static errors
  • Updated mock trainer to add errors to reported power for simulation testing.

Outstanding items:

• Expose PowerMatch Offset and Scale to user in settings
• Decide if PID is useful, or a simple ramp to target might be smoother (requires more testing)
• Expose PowerMatch PID or Ramp settings to user in settings (if PID is the way to go)
• More testing with higher power levels, and shorter intervals to see if it can reach target quick enough without oscillation
• Ensure power match is always active when starting a workout. Might have an issue where it doesn't start up active until the first step change. (more testing needed)

I'm not sure how much more good testing I can do, seeing as my trainer is within 10 watts to my power meter, I think just about any pid settings I use will work fine.

If you know of anyone asking for this, we could have them test, but without being able to really test it myself, I can't vouch for how well it will work with larger trainer errors.