NP & math question

SolarEnergy said:

I've seen some too. What did you do with them?

I exclude them. It's a bit complicated, but basically I create a new index excluding blank watts rows.

SolarEnergy said:

Of course you can. I'm very bad at math (I think I mentionned it earlier). But still, I want to do my best calculating NP related stuff. So I want to stick to the 30s rolling average.

Right now my approach is to process a datafile using a recursive function, creating nodes as I find them, to later return those nodes probably in a tree view. The logic I'm writing at this moment (while being aware that I might turn my back later on and start with something different), involves navigating from this second to the next, then to the next, and then back and forth...

I don't understand your question.

SE - just use a 24 sample rolling average instead of exactly 30-seconds. That's what the CP software does and a lot of spreadsheets I've seen and built myself.

rmur17 said:

SE - just use a 24 sample rolling average instead of exactly 30-seconds.

What's a 24 sample rolling average? (sorry :o )

RapDaddyo said:

I exclude them. It's a bit complicated, but basically I create a new index excluding blank watts rows.

Smart. That's exactly what database engines do with a record containing a null value. It doesn't get included in the calculation of an average for instance.

SolarEnergy said:

Smart. That's exactly what database engines do with a record containing a null value. It doesn't get included in the calculation of an average for instance.

Correct. And, a word to the wise: if you fail to exclude the blanks, your computations (AP, NP, IF, TSS, etc.) will be different from those in CP/WKO+ for the identical segment of a ride file (whether it's the entire ride file or a subset).

RapDaddyo said:

FWIW, one option I would not recommend is to export a PT ride file as an SRM .txt file. While conceptually appealing (it is converted to 1sec durations), I have recently been working with CP and WKO+ export files of various formats and I have found that if you export a ride file from power meter x in power meter y format that it (the export file) can have erroneous data.

Interesting (remember I'm still not trying to think too hard). How bad is it? I thought it was pretty cool way to compare files from different PMs.

This was the technique used by Andy earlier this year when he helped me analyse some pursuit files to estimate my maximum accumulated oxygen deficit (MAOD*) which is probably the best measure of Anaerobic Capacity**. Given the steady state nature of pursuit data (start aside), I don't think it showed up much in the way of erroneous data though I can see how highly variable rides may.

* Ha ha, tell Tyson I found another acronym!

** Actually - I should re-run using my latest pursuit effort and see what I come up with. I'll wait 'til the brain wants to go again. Hey - it's "find me another $2M of savings from your budget" time again.

RapDaddyo said:

Correct. And, a word to the wise: if you fail to exclude the blanks, your computations (AP, NP, IF, TSS, etc.) will be different from those in CP/WKO+ for the identical segment of a ride file (whether it's the entire ride file or a subset).

Has this been the only cause of discrepency so far?

BTW, the wise had replaced all those values by zeros, and therefore was indeed off ! Thanks 😉

Alex Simmons said:

Interesting (remember I'm still not trying to think too hard). How bad is it? I thought it was pretty cool way to compare files from different PMs.

It's disastrous!:eek: I only discovered it because Andy sent me a file on which he had run my parsing app and he was getting strange results. At that time (about a week ago), my app worked only with PT .csv files so (at my suggestion) Andy had exported a native SRM file as PT .csv and used it as the source file in my app. I couldn't understand the results so I asked Andy to send me the file in both export formats (PT .csv and SRM .txt). When I looked at the files side by side (after adjusting for the 1.26s vs. 1.00s time series), I couldn't believe my eyes. At four points in the PT .csv file, it put in the watts column about five zeros followed by a very large number (3900, 3770, 3510 & 655)! You might think the 655 looks reasonable, but the values immediately following the 655 were 95, 90 & 69, so obviously the 655 was an erroneous value. After this discovery, I moved SRM .txt files to the top of the list of planned enhancements and had a version running that could accept SRM .txt files within 48 hrs. I will not trust a PT .csv export format from a SRM raw file. I don't know if it is a problem going the other way (PT >> SRM .txt), but I would do extensive file validation (i.e., 100%) before using such a file for anything serious.

SolarEnergy said:

Has this been the only cause of discrepency so far?

I can't really say, since I was only interested in the watts column. So, I have not validated the other columns. But, for me the watts column is the column of interest and even when I am not exclusively interested in the watts column it is always the column of greatest interest. As soon as I determined that watts was unreliable, I immediately ditched the idea of using what I'll call "cross-conversion" export files (i.e., files from one native format exported into a different format). I will only use files exported in the native format even if it means that I have to build 10 file import functions.

SolarEnergy said:

What's a 24 sample rolling average? (sorry :o )

by 24 sample rolling average I mean .... literally if using Excel with the power data in column D and starting the rolling average after ~30seconds or 24 samples to be exact.

30RA(24)=average(d1:d24)
30RA(25)=average(d2:d25)
30RA(26)=average(d3:d26)
.....
30RA(n) = average(d[n-23]:d[n])

Strictly speaking that's a 30.24 seconds rolling average but that's the best can get with 1.26 sec sampling. IF you are using 2.52 second recording, then you'd use a 12-sample rolling average (again 30.24 seconds).

Yes I know the PT samples at a higher rate and what we're seeing is the average over the last 1.26 seconds. You can use the word 'record' if you want.

RapDaddyo said:

I will only use files exported in the native format even if it means that I have to build 10 file import functions.

What's the problem with the .wko format ?

amartinez said:

What's the problem with the .wko format ?

Open database connectivity, or any other type of datafile access, through com+ for instance is a concept that is wide spread in the world of database applications.

However it seems that this concept hasn't reach the world of "sport-related" applications.

This format is propriatory. At this time, there are no dll that we can call to have access to this data.

rmur17 said:

Strictly speaking that's a 30.24 seconds rolling average but that's the best can get with 1.26 sec sampling.

That's also how WKO+ computes NP, so if you attempt to get a strict 30s rolling average your numbers will be inconsistent with those of WKO+.