We are doing our own testing. Our data looks a bit different. To be honest, ours looks better, and thanks to Chung and Anhalt's work we know what specific abnormality to look for (although we are also looking for others, or course). Will be a little while before we feel comfortable publishing anything, though.
Rainmaker does truly excellent work, but in this case I think it would have been worth trying additional units, and maybe another set of legs. Quite the death sentence to pronounce based on a single unit. It's possible that either our unit is better (it has brand new firmware) or my legs are more even (previous testing has indicated I'm within about 1.5% left to right, even well into a LT test.)
I agree it's only one unit and perhaps it was screwy but we could only analyze the unit that was sent. Stages sent out new firmware last week and said that it was in response to something in our analysis, though I don't have any idea what that something is. We've looked at multiple heads on one PM and there are tricks to making sure you're comparing apples to apples. For example, one thing I've seen is that one Garmin model can be slower in registering a change in speed or power than another Garmin model, and one Garmin model may have an occasional data drop compared to another Garmin model. What this means is that you shouldn't do second-by-second comparisons -- and we didn't. Note, btw, that it's easier to check this kind of thing on speed and distance rather than power. That's why I generally synch up *not on time* but *on distance as calculated by the speed.* That is, take a look at the recorded speed from different head units on the same PM or even different head units on different PMs. The speed will turn out to be very, very consistently recorded. If you do this, you'll see that occasionally one or another head unit will hiccup, either skipping a signal or else skipping a time marker. Ever notice that even if you do your darnedest to mark intervals on two head units as closely together as possible, when you get to the end of a ride on head unit will be off by 4 or 5 seconds compared to the other? You know you didn't hit the buttons 4 or 5 seconds apart. That's what I'm talking about. In either of these two situations, integrating the speed up to distance will show as a misregistration between the head units. A side effect is that if you don't synch up on distance but instead try to synch up on time, you can find a growing difference in speed and a corresponding growing difference in power.
So one thing I've been doing is averaging over many seconds -- but if the problem is not only misregistration but also a data drop (where power or speed goes to zero for a second or two) then you can still get an artifactual difference in speed or power or cadence or anything else you're trying to track. So one way to get around it is to snip out parts around a data drop; another is to do a robust smooth (like an odd-span median smooth) over the data before doing something like a kernel smooth. I don't usually bother doing the latter thing because it's a pain in the butt but I toss it out there if you have more patience than I.
I'll be interested in seeing your analysis. BTW, if you (or anyone else) think we did a crappy job with the analysis, Ray put the raw data files up -- there's a link in one of his comment replies.