SRM/Powertap output contrast

[AndROOb]

Given that both systems are set up accurately, calibrated properly, and the torque zero'd, what contrast should I expect in (displayed)power output when the SRM's are measuring torque at the cranks and the Powertap is measuring torque at the rear wheel?
Also will this contrast be linear throughout the power output range?

 

[acoggan]

Given that both systems are set up accurately, calibrated properly, and the torque zero'd, what contrast should I expect in (displayed)power output when the SRM's are measuring torque at the cranks and the Powertap is measuring torque at the rear wheel?
Also will this contrast be linear throughout the power output range?

I have consistently found a difference in both the slope and the intercept of the SRM power-PowerTap power relationship, even when both devices have been properly zeroed and carefully calibrated using static loading with the same masses. I assume that this reflects the fact that frictional losses in the drive train are partially dependent on, and partially independent of, the applied power (force). Despite this, I have chosen to correct my PowerTap data upwards by 2.5% across the board, just to keep life simpler.

 

[joemw]

I have consistently found a difference in both the slope and the intercept of the SRM power-PowerTap power relationship, even when both devices have been properly zeroed and carefully calibrated using static loading with the same masses. I assume that this reflects the fact that frictional losses in the drive train are partially dependent on, and partially independent of, the applied power (force). Despite this, I have chosen to correct my PowerTap data upwards by 2.5% across the board, just to keep life simpler.

Heck yes! I just picked up 9-10 watts at FT

 

[Alex Simmons]

Heck yes! I just picked up 9-10 watts at FT

Maybe - but it still ain't getting to the road though where it counts!

I'd say Andy would have chosen to increase his old PT data for season to season comparison purposes since he is an SRM user nowdays and that would have been a once off job (rather than being an SRM user who switched to PT or constantly modifying every new SRM file he generates to enable seasonal comparisons).

 

[joemw]

Maybe - but it still ain't getting to the road though where it counts!

Au contraire, what counts most is inflation of the ego

 

[AndROOb]

To clarify matters, I'm using the SRM's on my TT bike, and PT on my training bike.

This will mean that it will be easier to keep separate files for both devices as I do a fair bit of training work on my TT bike.

 

[RChung]

I have consistently found a difference in both the slope and the intercept of the SRM power-PowerTap power relationship, even when both devices have been properly zeroed and carefully calibrated using static loading with the same masses. I assume that this reflects the fact that frictional losses in the drive train are partially dependent on, and partially independent of, the applied power (force).

That's one possibility. Another might be that you're picking up the difference between averaging per unit time (like the PT) and averaging over a crank revolution (like the SRM), particularly at high and low power.

 

[acoggan]

That's one possibility. Another might be that you're picking up the difference between averaging per unit time (like the PT) and averaging over a crank revolution (like the SRM), particularly at high and low power.

Methinks you need to rethink that statement. The aliasing effect created by the PowerTap's approach results in a random, not a systematic, error.

 

[beerco]

That's one possibility. Another might be that you're picking up the difference between averaging per unit time (like the PT) and averaging over a crank revolution (like the SRM), particularly at high and low power.

Also don't forget that just like the PT, the SRM somehow crams those one rev values into an arbitrary time base.

 

[acoggan]

Also don't forget that just like the PT, the SRM somehow crams those one rev values into an arbitrary time base.

??

With the SRM, the power value recorded at time X is the average over all revolutions completed since time X-1. If no revolutions have been completed since time X-1, then the last value is used again. This makes it possible to capture data pedal stroke by pedal stroke if you set the recording frequency high enough relative to the pedaling frequency. However, this requires using a PCIV and not a PCV, as the latter is limited to 60 Hz (earlier versions) or 120 Hz (most recent versions).

(Note that at least the most recent version(s) of the SRM software do some additional processing of the data.)

 

[beerco]

??

With the SRM, the power value recorded at time X is the average over all revolutions completed since time X-1. If no revolutions have been completed since time X-1, then the last value is used again. This makes it possible to capture data pedal stroke by pedal stroke if you set the recording frequency high enough relative to the pedaling frequency. However, this requires using a PCIV and not a PCV, as the latter is limited to 60 Hz (earlier versions) or 120 Hz (most recent versions).

(Note that at least the most recent version(s) of the SRM software do some additional processing of the data.)

Possible yes, but what about in practice:

e.g. at 100 rpm, we're talking about .6s per revolution. To guarantee you capture the full pedal stroke, you've got a minimum sample rate of .3s (and even then it would be better to at least double it, typically you'd go 5x). How many people do you know of that keep their recording rate at .3s?

I think that with the algorithm you describe above most situations should be covered. However the "re-sampling" method SRM uses is not a standard method (e.g. taught in engineering school) so it's hard to say for sure how accurate it is. I can already think of some situations where it could over report power.

It seems to me that SRM has a much better grasp on the signal processing aspect of this whole thing than PT but there is still some voodoo being done when the recording rate is lower than cadence. I imagine most people set their SRMs to 1s recording interval and then pedal around 90rpm on average.

This is why I proposed that the best way to record power data is to not apply an arbitrary time base to the recordings, but to rather record the elapsed time since the last rev (timing mark) and the average torque during that rev. This way there is no data loss whatsoever.

 

[ahaile]

If no revolutions have been completed since time X-1, then the last value is used again.

Hmm, that will cause averaging problems. Say you're recording at 1s and pedaling at 40rpm, so every stroke takes 1.5s. Half will be recorded twice, half only once. Your overall average will only be good if the average of the even numbered strokes = the average of the odd strokes. That may seem a contrived situation, but here's one that's probably more real. Think of a track sprint, where in the first few seconds power is falling but cadence is increasing. The earlier strokes are of longer duration and so have a greater chance of being double-counted. Since they're also of higher power, the average will be skewed up.

This is why I proposed that the best way to record power data is to not apply an arbitrary time base to the recordings, but to rather record the elapsed time since the last rev (timing mark) and the average torque during that rev. This way there is no data loss whatsoever.

Just curious -- how would you deal with changes in pedal velocity *within* a single stroke? This was the problem discussed in the RMS thread recently. Is averaging over distance (every X degrees) rather than time (every X ms, like most PMs do) robust enough for "no data loss whatsoever"?

 

[acoggan]

Possible yes, but what about in practice:

e.g. at 100 rpm, we're talking about .6s per revolution. To guarantee you capture the full pedal stroke, you've got a minimum sample rate of .3s (and even then it would be better to at least double it, typically you'd go 5x). How many people do you know of that keep their recording rate at .3s?

Not very many, because 1) you fill up the memory too quickly, and 2) it's only possible if you own a PCIV, not a PCV. However, I bring it up simply as evidence of how the SRM works, not something that I recommend people routinely do (although it does have its uses, at least if you're a trackie).

I think that with the algorithm you describe above most situations should be covered. However the "re-sampling" method SRM uses is not a standard method (e.g. taught in engineering school) so it's hard to say for sure how accurate it is.

I'm not defending it, just pointing out that it doesn't involve "cramming data into time periods" (or however you phrased it).

 

[acoggan]

Hmm, that will cause averaging problems. Say you're recording at 1s and pedaling at 40rpm, so every stroke takes 1.5s. Half will be recorded twice, half only once. Your overall average will only be good if the average of the even numbered strokes = the average of the odd strokes.

Again, I'm not advocating the approach, just pointing out that beerco's assertion is incorrect.

That may seem a contrived situation, but here's one that's probably more real. Think of a track sprint, where in the first few seconds power is falling but cadence is increasing. The earlier strokes are of longer duration and so have a greater chance of being double-counted. Since they're also of higher power, the average will be skewed up.

Which is one reason why trackies "in the know" won't give up their PCIVs (maximum recording frequency = every 0.1 s) until they're pried from their cold, dead fingers.

 

[beerco]

Just curious -- how would you deal with changes in pedal velocity *within* a single stroke? This was the problem discussed in the RMS thread recently. Is averaging over distance (every X degrees) rather than time (every X ms, like most PMs do) robust enough for "no data loss whatsoever"?

If you only have one timing mark on the crank or hub like SRM & Powertap have, there is no way of dealing with it. The only way to truly deal with it would be to add a high data rate crank position sensor to the whole deally and calculate power for each fraction of a rotation.

 

[beerco]

I'm not defending it, just pointing out that it doesn't involve "cramming data into time periods" (or however you phrased it).

Let me re-phrase without using the word "cramming"

SRM's method will distort the true power signal.

I used the term "cramming" to point out that under normal operating conditions, the power signal is distorted or "forced" to fit into an arbitrary time scale of the user's selection. Under some circumstances this may work while in others it may not.

 

[rmur17]

I have consistently found a difference in both the slope and the intercept of the SRM power-PowerTap power relationship, even when both devices have been properly zeroed and carefully calibrated using static loading with the same masses. I assume that this reflects the fact that frictional losses in the drive train are partially dependent on, and partially independent of, the applied power (force). Despite this, I have chosen to correct my PowerTap data upwards by 2.5% across the board, just to keep life simpler.

As I have a CT, PT and SRM and use the PT and CT 90% of the time (SRM on the TT bike), I chose to slightly de-rate my SRM power to match my PT and CT. It was around 2% higher IIRC - in a non cross-over gear at 45 kph.

rmur

 

[Alex Simmons]

Au contraire, what counts most is inflation of the ego

Which comes from winning races presumably....

 

[AndROOb]

As I have a CT, PT and SRM and use the PT and CT 90% of the time (SRM on the TT bike), I chose to slightly de-rate my SRM power to match my PT and CT. It was around 2% higher IIRC - in a non cross-over gear at 45 kph.

rmur

This sounds like a good idea to me. Currently the SRM's are showing a 10% higher output than the PT. Is it just a matter of changing a number using the SRM s/ware?

 

[rmur17]

This sounds like a good idea to me. Currently the SRM's are showing a 10% higher output than the PT. Is it just a matter of changing a number using the SRM s/ware?

Short answer: YES - the SRM slope (only) is readily adjustable in s/w or from the PC setup itself. Increasing the slope will reduce the reported power.

Long answer: I'd recommend doing at least one 'stepped' power test ideally on an ergometer and checking your SRM versus PT power slope and zero-offset (simple linear regression in Excel) before adjusting anything.

Uhm - that assumes you're being quite careful about zeroing both meters of course! Aside from that, the SRM should definitely not read 10% above the PT.

There's a stomp test available to check your PT should there be reason to doubt the meter ... and a static weight check available for the SRM. It's best to be sure which one is off before making any adjustments.

Mine read pretty much as expected - some 2% high across my tempo to V02max training range so I increased my slope 2% to match the PT. Haven't needed to touch it in some time now.

rmur