Plotting Error When Using Powermatch [Feature Request]

It would be great to be able to plot the (LP filtered) error when using Powermatch - just as a deviation above and below zero. Maybe as a toggle in the Powermatch section of the trainer device?
The only way I can see to do this at the moment is to record power via 2 different devices, then compare them in 3rd party software - it would be fantastic to just see it right there on the workout.
We could then more easily judge if Powermatch is right for our individual setup, or whether we’d benefit from the improved response/control of trainer-only.
For example: I have left sided power and don’t know what my L/R balance is like. If it’s large enough to throw out the numbers, then I should be using Powermatch. If it’s not large enough to noticeably affect the workout, then I could benefit from the shortened response time and smoother control of trainer-only mode and still be working at the same power as I would be outside.

You could set it so TrainerRoad could assess and recommend whether or not you’d benefit from Powermatch.
You could even set a trigger to tell you when something has drifted and needs zeroing.

2 Likes

Thanks for the feature request! I’ve passed this along to our development team that you’d like TrainerRoad to track and display the offset between a trainer and power meter. :raised_hands:

1 Like

That’s almost right, except what you’re seeing when you do that is the set point (what the system is asking for), not the power measured at the trainer. Ideally they will be exactly the same, but in practice they’re not (if they were then you’d have a perfect system). That’s not really the point of my request though, this is:
Even if the set point was exactly the same as the power measured at the trainer, you’d still need to export both that trainer power data and the separately recorded power meter data, then subtract one from the other to work out the error. You’d want a low pass filter to smooth out the power meter data to more closely resemble the resolution of the trainer data, which has been mechanically filtered by the flywheel (this is why PM data looks so much rougher than trainer data - because it hasn’t been filtered).
I know it seems like a simple case of just looking at where the yellow line is and comparing it to the blue one, but it’s a bit more complicated than that - not much though!

What I’m asking for is for that all to be done when the workout data is processed, so you’re just presented with a nice straight “zero” line and a plot of error floating around that zero. There’s no need to account for the roughness of the PM data, and there’s no jeed to workout the difference in your head or plot best fit lines or anything like that - the line just shows you the difference.

Imagine if, in a DC Rainmaker review, rather than looking at a graph with a few different colours on it and saying “it looks like its about 5W high here and sort of maybe 11W low there”, there was just a single solitary line that went up to +5W here and down to -11W there. It’d be a lot easier to interpret, right? And t wouldn’t require any manual data processing. You could even set TrainerRoad to alert you if your error went over a certain threshold, which would be an indication that either your PM or your trainer had drifted since the last calibration.

Got it! Thanks for clarifying, it definitely makes more sense as to what you’re asking for.

Ultimately, since the offset is changing so frequently between power meters and trainer power, we think it’d be best to use PowerMatch even if the discrepancy between devices is small. The extra few moments it takes for PowerMatch to adjust resistance (in comparison to just the trainer alone) is just a few seconds of time where you’re not perfectly at target power while the trainer is adjusting, which won’t equate to any significant loss in training benefit.

That being said, while getting those extra few seconds perfectly at target power isn’t going to be the game-changer in making you a faster cyclist, we definitely hear you that this is an area where power data is not optimized and could be improved upon!
I’ve passed this along to our development team for consideration!