PT Average torque vs Average Watts



jetnjeff

New Member
Mar 17, 2006
188
0
0
59
Andy or anybody else with some insight,

I was looking at some CPS files from a PT and noticed that the highest average Watts for an interval did not always have the highest torque even when multiplied by the Cadence.

Examples from three seperate days during a 20 minute FTP interval. The High torque was from an Uphill TT and the other two are on a trainer. 130 pound athelete:

Watts lb/in RPMs
219 87 X 104 =9,048.
221 167 X 68 =11,356.
232 89 X 96 =8,544
Am I missing a key variable or non-linear part of the equation?
 
PT torque is hub torque, so it's relationship to power and cadence depends on the gear ratio.
 
jws said:
PT torque is hub torque, so it's relationship to power and cadence depends on the gear ratio.
Thanks,

OK I figured out how to gear ratio from Speed and Cadence.

But how do you get the records from a CPS file into Excel.

I can copy the records and make a new CPS file, but I can not paste the records into any Microsoft products, Excel, Word, Note pad, Outlook or Access.
 
jetnjeff said:
Thanks,

OK I figured out how to gear ratio from Speed and Cadence.

But how do you get the records from a CPS file into Excel.

I can copy the records and make a new CPS file, but I can not paste the records into any Microsoft products, Excel, Word, Note pad, Outlook or Access.
got it Export Copy as .csv
 
jetnjeff said:
got it Export Copy as .csv

Glad you figured it out!

Now, just as an aside for others: in general, I recommend exporting data in the same format as used by the device that created it (assuming that format is readable by the program you want to use to manipulate it, e.g., Excel). IOW, if you imported data from a PowerTap, export it as .csv, if you imported data from an SRM, export is as .txt, etc. The reason I say this is that CyclingPeaks interpolates the data to the corresponding time base when exporting the file (e.g., 1.26 s for .csv), and on rare occassions this can introduce artifacts. Always exporting to the "native" time base should help prevent this from happening.