and it sounds like the NP calcs have developed a bug See extracts below from the wattage forums 2009/12/18 Chris Cleeland <chris....@gmail.com>: > On Thu, Dec 17, 2009 at 5:00 PM, Nate <n.......@gmail.com> wrote: >> So what is the best way to handle data from a PT to use your NP >> algorithm. > > it's not data from the PT that's the problem--it's data from a PT when > the sampling rate is anything other than 1.26s (or whatever the most > frequent sampling rate is). Except, Nate's file is 1.26seconds, and should be producing the correct value, and it certainly looks to me like WKO 3.0 does get the calculation wrong. I suspect this due to new code which attempts to deal with irregular sampling rates, and is fooled by the non multiple of 1 second nature of the PowerTap into thinking some of the samples cover more than 1 second. ie: WKO 3.0 thinks there are these whole seconds: 1,2,3,4,6,7,8,9,11 and for the 6th second it considers that a sample for the 5th and 6th seconds, and the same with the 11th for the 10th and 11th seconds. Doing this for a range of the file and calculating myself, I get an NP value the same as WKO 3.0's. I would say this is a WKO 3.0 bug, and if you have a PowerTap recording at 1.26seconds, stick with 2.2. Jim. and ... My PT is recording at 1.26seconds - a 2hr:49min ride yesterday gives NP of 249 in 2.2 and 255 in 3.0. A 20 min interval within the ride is 297 in 2.2 and 300 in 3.0. and ... I have NP discrepancies with my SRM (set as 0.5 second sampling rate) as well. These are smaller in magnitude but cause concern none the less. ie 60 min period 2.2 - 261W 3.0 - 267W data handling or calculations do appear to be different between programs and Coggan explains ... On Dec 18, 8:43 am, Andy Coggan <acog...@earthlink.net> wrote: > As Hunter described when announcing release of the new version, there > are differences in how it handles gaps in the data. I suspect that is > what you are seeing, i.e., minor differences are to be expected if > your file isn't "perfect". How "should" gaps be handled? What if, as an off-hand example, the gap was long enough to eat a burrito and drink a beer? and then acknowledgement ... On Dec 18, 2:52 am, Jim Ley <jim....@gmail.com> wrote: > Except, Nate's file is 1.26seconds, and should be producing the > correct value, and it certainly looks to me like WKO 3.0 does get the > calculation wrong. I suspect this due to new code which attempts to > deal with irregular sampling rates, and is fooled by the non multiple > of 1 second nature of the PowerTap into thinking some of the samples > cover more than 1 second. > > ie: WKO 3.0 thinks there are these whole seconds: > 1,2,3,4,6,7,8,9,11 > and for the 6th second it considers that a sample for the 5th and 6th > seconds, and the same with the 11th for the 10th and 11th seconds. > Doing this for a range of the file and calculating myself, I get an NP > value the same as WKO 3.0's. > > I would say this is a WKO 3.0 bug, and if you have a PowerTap > recording at 1.26seconds, stick with 2.2. After digging into things a bit more, there does indeed appear to be a problem with the way that WKO+ 3.0 calculates normalized power from data recorded using a legacy (i.e., non-ANT/ANT+) PowerTap. This bug does *not* affect the calculation of normalized power from data collected using any other device. A fix has already been developed and a new build will be released as soon as it can be adequately tested. Andy Coggan Windbreaker2009-12-18 15:04:15