Cycleops Pro400 distance/speed error (defined)

[J-V]

[SIZE= 14px]I finally had one response to my plea for a CSV file from a PowerTap hub other than my own, and a fellow CyclingForums user was kind enough to provide it. In regard to the distance/speed errors that have been well–but incompletely–documented here on CyclingForums.com, I thought I'd shed a little light on the issue for those who remain both confused and plagued by the issue. If you are unsure whether your PT hub has the problem, take a look below, and you can check a CSV file from PowerAgent and find out.[/SIZE]


[SIZE= 14px]First, the background on what led me down this path:[/SIZE]

[SIZE= 14px]I have a 'new' CycleOps 400Pro Indoor Cycle,which functions as an ergometer. I noticed that there was a problem on my second ride back in August 2010, as I did a Target Slope ride as a fitness test (my local climb is 4.5 miles at 5% gradient). I got up the climb nearly 7 minutes too fast, and the Saris engineers 'were sure' (even though I was quite dubious) that it was a 'read sensor' in the PowerTap hub, and it required replacement. I thought it was more likely software at the time, and it took months for me to finally get around to changing the hub. [/SIZE]


[SIZE= 14px]Fast forward to December 2010: the new hub showed the same problems, so I started digging into the data to determine the source of the error. Saris Tech Support got with the engineers and had me try a few things, to no avail. I sent them a detailed analysis of what you are seeing below, and they have since gone quiet. I have to assume they are in the background trying to fix it, but both PowerAgent and Joule/LYC firmware updates will apparently be necessary to fix what I now believe to be a widespread hardware problem (evidenced only by one random file from a person I do not know, eliciting the exact same errors). Oddly–and luckily–they apparently have redundant data from the PowerTap to be able get around what may be a hardware issue via software. I still cannot fathom why the PT hub outputs both speed and distance data discretely, but they may be lucky they designed it that way.[/SIZE]

[SIZE= 14px]Anyway, for some reason, the distance field is used by some programs to calculate speed, and would result in occasional speed spikes (pretty cyclically consistent through the data file). But, if you look at the CSV file, the speed spikes are not manifested in the speed column, the source of the error is the distance column. Without adding a column to show the difference in distance each second (i.e. sample, or row of data), the outlier data is hard to see. Make that calculation (Column F, in the screengrab below), and the error stands out like a sore thumb. Graph it, and then you can really see how cyclic the error is, and only the engineers can know why the error is semi-cyclic, and random at the same time.[/SIZE]

[SIZE= 14px]Anyway, here's a screenshot of the Excel file showing the substance of the above (the first error occurs at 3.28 minutes into this ride, bolded). I'd be curious to hear if any of you with this 'known' distance/speed discrepancy can confirm that the distance field is the source of the error.[/SIZE]

[SIZE= 14px]Apologies if this exact error has been well-documented elsewhere, but I searched, and could find mainly references to there being an average speed vs. distance discrepancy, but nowhere was the source defined.[/SIZE]

[SIZE= 14px]Best to all,[/SIZE]

[SIZE= 14px]JV[/SIZE]

PS: The impending version of PowerAgent (v2.18b)may fix the problem for most, but not for newer version of the Indoor Cycle that utilize the Joule, nor for people that use WKO+, where the error is still evident.



[SIZE= 14px][/SIZE]

 

[daveryanwyoming]

Good data sleuthing J/V.

It sure looks like classic aliasing which wouldn't be too surprising given the PT's time based sampling. Does the average across say two or three seconds match the results stored in the speed column or do the positive and negative spikes introduce a systematic bias? Either way this wouldn't be a good thing for aero Chung testing or other applications where instantaneous distance matters.

Nice job tracking that down.

-Dave

 

[J-V]

Originally Posted by daveryanwyoming .

Good data sleuthing J/V.

It sure looks like classic aliasing which wouldn't be too surprising given the PT's time based sampling. Does the average across say two or three seconds match the results stored in the speed column or do the positive and negative spikes introduce a systematic bias? Either way this wouldn't be a good thing for aero Chung testing or other applications where instantaneous distance matters.

Nice job tracking that down.

-Dave

Hi Dave,

To answer your questions, in order:

No, the average of any given set of errant data doesn't match anything in the data, regardless of how many samples are averaged (i.e. there really is not any sort of speed spike in the data when you can see that there is a 'distance spike'). However, looking at the data in different programs may yield different results, as other programs may treat the distance field in a different way than PowerAgent. I know that WKO+ interprets the data differently, and thus may require their own fix for these errors.

What you refer to as "positive and negative spikes" are actually positive spikes, and drops to 0.001, respectively. I plotted the data on a log scale just to quickly be able to see the trends, which become readily apparent on the chart.

You would think it was classic aliasing, but for how consistently the outliers appear (on the chart), they actually appear inconsistently both in timeframe (wheel revolutions?) and in trending (i.e magnitude of the error, how many samples are erroneous, etc.). I've read that Saris finally made a change from sampling at 1.26 second intervals to 1-second intervals, and the only thing I can think along these lines is that somewhere in the software they forgot to take into account that change, or did so in an erroneous way, or... ???

Either way, it would appear that this issue affects multiple (recent?) products across their line, and it sure seems like the oft-reported 'distance not matching average speed' issue is one and the same.

Best,

JV

PS: If anyone is having these 'average speed vs. distance' errors, if you feel so inclined please post here what product you are using, and roughly when it was bought or manufactured (I'd appreciate it).

 

[frenchyge]

Interesting.

There's definitely some weirdness in that excel file. For example, in rows 65 - 72 where distance change is 0 but there's a 20.2 km/h speed spike in the middle and then in row 73 where the speed starts up again the distance change "catches up" even though the speed for that second was only 6.1 km/h. IOW, it's hard to tell which of those data columns are being calculated and which are being recorded from the device. I'm curious along the same lines as Dave whether the distance change spikes and subsequent .001 downward spikes aren't the result of some calculations finally catching up and synching with independently recorded data.

Just so I understand the actual issue J/V, are you saying that over the course of a long ride the recorded time multiplied by the calculated avg speed was greatly different than the recorded distance for the ride? I've never noticed that myself, but I'd be happy to contribute data files if you PM me with an address.

 

[J-V]

Originally Posted by frenchyge .

Interesting.

There's definitely some weirdness in that excel file. For example, in rows 65 - 72 where distance change is 0 but there's a 20.2 km/h speed spike in the middle and then in row 73 where the speed starts up again the distance change "catches up" even though the speed for that second was only 6.1 km/h. IOW, it's hard to tell which of those data columns are being calculated and which are being recorded from the device. I'm curious along the same lines as Dave whether the distance change spikes and subsequent .001 downward spikes aren't the result of some calculations finally catching up and synching with independently recorded data.

Just so I understand the actual issue J/V, are you saying that over the course of a long ride the recorded time multiplied by the calculated avg speed was greatly different than the recorded distance for the ride? I've never noticed that myself, but I'd be happy to contribute data files if you PM me with an address.

There is indeed some weirdness. I can accept some amount weirdness in very frequently-collected data, as errors will typically average themselves out if they are small in magnitude and frequency. This error is neither.

Despite the 0.001 values being kicked in there occasionally, there are far too few of them (relatively) to offset the increases in distance caused by these 'distance spikes'. I've looked over a few files in depth, and there really aren't any statistically significant patterns, only 'general' patterns. i.e., there is often a 0.001 value kicked in during or after a 'distance spike', but not always, and not nearly enough to offset the increase in distance.

So yes, for any given ride, there is a discrepancy between distance and average speed; the distance is always too high (as reported elsewhere in various threads re: the LYC and Joule) in comparison to the average speed multiplied by ride time (even accounting for inconsistencies in ride time, as also reported elsewhere), but the magnitude is variable, i.e. the error is not consistent. I saw none of these errors on my former CycleOps PT300Pro, it appears to be associated mostly with newer PowerTap hubs, though I have only anecdotal data to rely on.

The other odd thing is that files output by PowerAgent in PWX and CSV formats differ, but I'm unclear whether the reason is on Saris' side or TrainingPeaks'. I think Training Peaks has tried to fix some of the known errors that Saris hasn't yet solved, but I can't really be sure what's going on without talking to one of Saris' engineers, as Saris' knowledge at the Customer Support level has long ago been tapped. Ahem.

I'll shoot you a PM, and please let me know what product the data is from, and the approximate date of purchase.

JV

 

[J-V]

So here is a 'typical' set of error values:




And here is a not-so-typical set of error values:



And this is just plain weird:




Keep in mind that this data is from a CycleOps Pro 400 Indoor Trainer, so it won't be your typical PowerTap data (i.e. it has a resistance unit that can constantly be changing parameters when in ergometer mode). But why the speed increase as noted by the PowerTap precedes the power increase by 5-7 seconds baffles me. This seems to occur only for larger-magnitude power surges.

In any event, the distance spikes in the data are primarily what concern me, and I've confirmed that they also exist in one other PowerTap user's data.

-JV

 

[J-V]

I received some files from a PT Pro wired and PT Pro+ (thanks frenchyge!), and neither show the aberrations described above (the other person's data that I saw the errors in were from a Pro400). Hopefully that means that this problem is unique to the Indoor Trainer product line (not sure about new Power Trainers), and can easily be fixed in software and firmware.

JV

 

[frenchyge]

I guess if you're going to have systemic distance reporting errors, an indoor, stationary product line would be the place to have them. /img/vbsmilies/smilies/wink.gif

 

[Kuttermax]

Resurrecting this thread to see if a solution to the problem was ever found. I'm looking at purchasing a new indoor training bike and the Cycleops 400 Pro is high on the list but still debating if it is worth the $$$ and also wondering if Cycleops has something new coming soon.