Saturday, June 28, 2014

Packing Ritchey Breakaway with Powertap wheel: S&S method

I've never taken my Powertap wheel with me when traveling with the Ritchey Breakaway because of the bulge in the hub.

When packing with the Ritchey-recommended method (see Oleg's blog post), in which the rear wheel goes in first with the cassette in the bulge in the case, the front wheel goes in immediately after, each hub fitting in gaps of the spokes of the opposite wheel.


Wheels go first in Ritchey packing method. Note hubs extend between spokes. (Oleg's Cycling Adventures)

The Powertap wheel, however, has a bulbous extension on the non-drive side of the hub which prevents them from extending between gaps in the spokes. Without that, the stack height of the wheels is too large. So for years I would just do without the Powertap when traveling.

image

But then I saw Oleg's post on packing the Ritchey using the S&S case method. I was skeptical at first, but sure enough, it all fit without problem. I'm spatially challenged, so needed check, double check, and triple check to make sure the orientation of each piece is correct. But while it took me considerably longer than Oleg's 12 minutes to pack my bike, it worked.

image
packed, S&S method

The key with the Ritchey case is to don't leave the case lying on its side when packing, but lift it up to allow the sides to extend slightly beyond the boundary of the hard sides. Then it will zip shut.

One piece of advice I picked up off BikeForums is to carry water bottles in my carry-on bag instead of in the case. Apparently the bottles may be a magnet for TSA inspection. I've had TSA inspect my Bike Friday way back, several times, but I've had better luck with the Ritchey. In any case, you absolutely don't want that to occur, especially with the Ritchey, because it's a puzzle getting it back together, and small errors can lead to a damaged frame, wheels, or components.

So we'll see how it goes during my upcoming trip.

Thursday, June 26, 2014

Diablo Hill Climb Time Trial (NCNCA championships)

The plan: after running my 50 km race in April, the plan was that I'd do some climb workouts to find my cycling legs again, ride the Memorial Day Ride (MDR), a 4-day supported tour from San Jose to Santa Barbara, to provide the base, then top it off with some hard climbing to get my top end. Running to cycling transitions are easier than cycling to running, in my experience. And running prepares you for the sustained effort of climbing in many ways better than riding does. I'd been able to run essentially continuously for 5+ hours at the Woodside Ramble 50 km. All I needed to do was to push out my top end and I'd be in for a strong Diablo.

The truth: I had some solid climb workouts, albeit slow, before MDR. MDR left me tired, compounded by other life pressures like work, looking for a new place to live, and finally dealing with the process of organizing my life to move. My weekends were essentially dead, and my Caltrain commute is crippling to my weekdays, leaving SF2G and lunch rides as my only training opportunities.

My post-MDR preparation boiled down to 3 successive Wednesday Noon Rides, including the Old La Honda climb. These started okay, riding a decent but disappointing 19:08. I hoped for a big improvement on my next try, but only managed an 18:56 on a day with unusually strong winds on the climb. But while time was tepid, power had increased a respectable 9 watts. I hoped a more favorable wind as well as further progress on power would give me closer to my 18:30 target on week 3, but instead power dropped back to the mid-range between my first two efforts. At least the winds at diminished, and so my time was at least marginally better, 18:51.

So this wasn't nearly where I wanted to be for ripping fitness at the Diablo climb. My goal went from possible age group podium to not reverse-podiuming -- bottom 3.

Despite the pressures of moving and of flying to Santa Barbara that afternoon for a conference at which I was giving a short course the next day, I got to the start area in one piece with legs feeling pretty good. I certainly hoped to match my time from two years before, when I was at least 1 kg heavier. That would have been 2 kg heavier but my weight was up from where it had been going into MDR. Despite apparently eating considerably less than other riders I observed on the trip, I'd certainly gotten no leaner, and indeed, I came out feeling bloated. Stress can do that. But bloated or not, the truth was I was simply over race weight. This required a reassessment of foods I'd leaked into my diet, like perhaps too much hummus on my lunch salad. But at least I had the advantage on 2012.

I had time for a partial pre-ride of the 10 km climb. I was discouraged to find there was a considerable headwind on the bottom of the course, but fortunately it abated once the serious climbing began. Of course the wind was there for everyone, but since I race without a power meter, it complicated comparisons with 2012, when there was a headwind on the bottom of the course.

Then I realized I had forgotten to cover the vents on my new Poc Octal helmet. They make an aero version where the vents are pre-covered, but it's easy enough to do it on my own with tape. Actually, it's fairly easy to make one with plastic: something for my to-do list after I move.

Ah, well, I decided. Most other riders also had vented road helmets. But I didn't completely ignore aerodynamics. I put my jersey inside my bib shorts in an effort to get more of a skin suit effect.

I decided to do the climb bottleless. I was hoping for a time close to 27 minutes, for no good reason, and in the cool temperatures I could handle that without a bottle. This left an empty bottle cage on my frame. I didn't have a wrench, so I left the cage on. Honestly I didn't think marginal gains were going to be critical today, given my Old La Honda results.

When my time came, I clomped up the short stairs to the start platform, as usual just hoping I didn't biff coming down the ramp. "Relax" the starter said, and I tried to comply. The countdown went to zero, and I was off.

I tried to keep as aero as possible while riding a steady effort for the opening 1.5 km. There's a gradual climb, then a descent, then a gradual climb before the road truly begins climbing enough to reduce the emphasis on aerodynamics against the considerable headwind. I didn't have a quantitative assessment of my effort here. I'm better at judging power when climbing then when riding against the wind.

To my dismay, remarkably soon I was overtaken by my 30-second man, Joseph Foster. I glanced at my timer: 8 minutes in. That was sobering, but it wasn't as bad as I'd thought before he'd caught me. The time had flown by.

On the positive side, the guy who started 30 seconds ahead of me, Jeff Rogers, appeared up the road not long after. I decided to focus on Jeff and not on Joseph. To my goal of not finishing bottom 3, catching Jeff would leave only two more riders I needed to beat. But it turned out Jeff was in the younger age group, and so was irrelevant to my placing.

As the climb went I fatigued somewhat, but felt I was doing okay. I never felt in major distress. That feeling snapped when Kevin Metcalf quickly overtook and passed me. Kevin's number was 6 larger than mine: he'd shut a 3 minute gap! Kevin is multi-time national master's champion, so it's no shame in having him beat me, but I was discouraged by the huge gap with more climbing yet to come.

I ramped up my effort towards the finish though, never feeling I'd overdone it. When I hit the 200 meter sign I ramped it up more. The final 200 meters of hill climbs are often way longer than expected, but I finished strongly.

After slowly riding the remaining 500 meters to the junction, enough to feel somewhat human again, I descended back to the finish. After chatting with Kevin, Keiran (who had his helmet vents covered), Greg, and Chris, it was time to descend. But as I was leaving Tom Simonson, NCNCA's best hill climb timer, asked me to take the results sheets back to the S/F for posting. I was happy to help, but the look of horror on his face when I folded the sheets before putting them in the envelope which would then go in my jersey pocket was impressive. He's such a pro -- even a crease on a results sheet, something which would never occur to me to be an issue, was unthinkable to him. But I assured him nobody would mind, thanked him for his incredible work, and down I went.

Ah, the results. So I was neither in the top 3 (my original super-stretch goal) nor in the bottom 3 (the complement of my revised goal). I was smack in the middle: 7 out of 13. I was around 2.5 minutes slower. That's huge.

Here's a comparison of the two rides, showing time to a given distance traveled.

image

I started losing time immediately, losing a remarkable 90 seconds in the first 3.2 km. No doubt the headwind played a major role here. The time losses continued through 5.0 km, at 2 minutes down, but then the losses were more controlled. But I still lost time, losing 25 seconds over the next 4.0 km, recovering slightly from there to the finish, which appears to be at approximately 9.8 km on this plot.

As I rode BART to Pleasant Hill station for the short ride from there to the start of the time trial, I sat across from 3 guys on their way to the Best of the Bay ride: 200 km point-to-point with some amazing roads, the highlight the difficult climb of Sierra Road. Here I was riding the same train for 10 km of pain. These guys considered their ride a success just by virtue of finishing, while for me, my race was effectively an exercise in managing the degree of failure. It caused me to evaluate whether these events are worth the time and focus they demand. Maybe I should focus more on longer, more epic rides, for which the reward is so much greater.



Friday, June 20, 2014

more Vector - Powertap power comparisons

After the last comparison, which was a ride with some steep hills in San Francisco, I did a few more rides comparing Vector to Powertap.

On that previous ride, my maximal power curve had been somewhat depressed on the Vector. Further investigation showed it appeared to be due to two points where cadence anomalously dropped on the Vector (but not the Powertap). Since Vector multiplied force by cadence by crank length to get power, if any of the three is off, the power is off.

The first of these two rides was a spin around Mountain View at lunch, stopping along the way to drop a package at the post office, then pick up some cherries at the local market (Ava's), then after a bit of a loop, a stop at Trader Joe's for figs and apricots. I made good use of my handlebar bag, combing some solid power efforts with fresh summer fruit for the afternoon.

Here's the maximal power curve from that ride:

image

The next day I rode into work with SF2G, the Dawn of the Dead variant of Bayway. This involved some decent tempo riding, but no maximal efforts. It really was a gorgeous morning and the ride was quite enjoyable.

The maximal power curve follows, although to make this I removed a single time point from the Vector since it had an anomalous power spike. The Vector seems slightly prone to these. If you're looking at best power over the last 6 weeks, for example, it seems there's a good chance the 1 second power will be contaminated. But

image

In both of these cases the result is basically what I'd expect: the Vector reporting slightly more power than Powertap. No signs of any funny cadence signals.

One comment on these results: you need to be really careful when comparing data from two meters on two Garmin units, especially with auto-pause set, because the two units don't report powers for every time point. Vector, in particular, will report no power when it's idle, presumably to save precious battery capacity. So you need to make sure any sort of analysis you do is robust against missing data. A nice thing about the maximal power curves for efforts up to the longest continuous efforts in a ride is they tend to focus on periods of continuous pedaling rather than periods with a lot of idleness, such as waiting at traffic lights. I've been bitten by this when looking at time-smoothed data and seeing strange differences which turn out to be due to one unit or the other having missing data.

Returning from work, I took the train, but still had to climb Potrero Hill with its peak 24% grade. Here's the power versus time for that ride, where I smoothed the power by 3 seconds (Powertap needs it more than Vector, since Powertap power tends to be spiky since it doesn't average over pedalstrokes like Vector, SRM, Quarq, etc):

image

Again everything looks good. There's some minor differences. The match isn't as good if I multiply Vector power by 97% in an attempt to adjust for drivetrain losses the Powertap doesn't see. But with the two units claiming only around 2% accuracy, that standard is too strict.

So in summary, the agreement is generally quite good. I think one potential source of variability is when you do the back-pedaling calibration. I think there you want a light touch on the pedals: try to float the feet. It seems a blocky back-pedal here could result in a power zeroing. Additionally, the power might not be as good the first ride after re-installation. Vector recommends doing a few sprints. Also there is an occasional one-second power spike which can wreck Strava's peak 1-second peak power. Since the best 3+ second sprints likely don't contain that power spike, though, they are likely good. Additionally I observed a strange cadence drop during one uphill effort on two brief occasions (1-2 seconds). This affected my power metrics for this effort.

I think Garmin could address the power spike issue with post-processing. For example, consider the case where I have 5 data points, and the power on points 1, 2, 4, and 5 represents a relatively tight distribution, but 3 is substantially higher. It may be plausible that the transition from points 2 to 3 would be a dramatic increase in power, but then points 4 and 5 would likely either also be a high power or would likely be close to zero power. It would be highly unlikely that power would spike for one pedal stroke then by the following pedal stroke return to a previous range, then stay there for an additional stroke.

Another approach for power spikes would be to consider the more detailed power through the pedal stroke. If the spike comes from an anomalous blip from a sensor, then it's unlikely that pedal stroke will exhibit a realistic force-versus-time pattern. The software could check for anomalous force-versus-time during the pedal stroke and isolate the anomalous portion.

Fortunately such intelligence is in the pods, not the pedals, and so it could be addressed with firmware, rather than hardware. I fully expect that the pedals will only continue to improve with additional updates.

Then there's that cadence blip. There again it's the domain of the pods. The pods have the accelerometers used to determine cadence. For some reason a pedal stroke may have been undetected. Why? I'm not sure. I don't know their algorithm. They watch gravity rotate relative to the noninertial frame of reference of the pedal pod. Perhaps there's an algorithm tweak which could make this more robust. Or perhaps future pedal pods will have improved hardware for cadence detection. It would be fun to dig into the firmware and try some stuff. Maybe if Garmin goes open source, alas.

So overall I'm certainly willing to use these pedals for power tracking. I recognize 1-second power becomes unreliable, but it's not reliable (to a lesser degree) with Powertap either, due to the fractional-pedal-stroke issue.

Thursday, June 19, 2014

balanced alternative to least-square linear fit

Last time I showed a comparison of Powertap to Vector power with a least-square line through the points. I noted this was "hard to interpret". Here's why.

A traditional least-square fit begins by assuming that the x-values are perfectly known, the y-values are uncertain. It additionally assumes that the y-values are normally distributed, with a Gaussian probability distribution, with the error distribution the same for all points, or with variances inversely proportional to the weighting factors for a weighted least-square fit.

This seems like a lot of technicality, but it introduces subtle biases in the result when comparing two values whcih contribute relatively equally to the error. For example, consider my power comparison for the Garmin Vector to the Powertap:

image

The slope was 0.97. Therefore, if I flip the axis the slope should be 1.03%. If the Vector is 3% lower than Powertap than the Powertap is 3% more than Vector, on average. But that's not what I get. I get 99%:

image

How can that be? The Vector is 3% lower than Powertap and Powertap is 1% lower than Vector?

The answer is in assumptions of the least square fit. Consider fitting the following,where PV is Vector power and PP is Powertap power:

PV = kVP × PP

Here kVP is a coefficient relating the PP power to the PV power.

The error associated with this estimate is thus as follows:

EVP = ∑ ( kVP × PP - PV )2

To set the value kVP to minimize this error, I differentiate with respect to that coefficient:

∂ EVP / ∂ kVP = ∑ 2 PP ( kVP × PP - PV )
= 2 kVP ∑ PP2 − 2 ∑ PP PV

I then set this derivative to zero (the usual minimization or maximization strategy for analytic functions). This yields the following solution:

kVP = (∑ PP PV) / ∑ PP2

Note this is most strongly influenced by points with larger values of PP. In this fitting algorithm, the errors are assumed to be in PV, which is on the "y-axis". PP values are considered "reliable" and are used to weight the sums. However, I had no reason to assume PP were more or less reliable than PV.

If I instead go through the same exercise assuming the Vector powers are reliable and the Powertap values are not, I get:

kPV = (∑ PP PV) / ∑ PV2

The product of these ratios will be 1, as expected, if the data are truly proportional, but if not, the ratio will no longer be one. That means the result depends on which power I assert is the more reliable. If I pick one at random, my conclusion about the ratio of Vector to Powertap power differs. This obviously isn't so good.

Note the culprit is the factor which appears both in the numerator and the denominator. In the kVP formula that is PP while in the kPV formula that is PV. To "balance" the fit between the two powers I should pick a common value for the two formulas. For example, I can choose the sum of the two powers (equivalent in this context to using the average). Thus I get a new pair of coefficients:

kVP' = (∑(PP + PV) PV) / ∑ (PP + PV) PP
kPV' = (∑(PP + PV) PP) / ∑ (PP + PV) PV

It's trivially obvious that PVP' PPV = 1, as I'd expect.

Here's the result of applying this formula to fitting the Vector power versus the Powertap power, comparing to the traditional least-square fit:

image

A summary of the slopes is as follows:

weighting termVector/Powertapcomment
PP0.9696least-square PV vs PP
PV1.00571 / L.S. PP vs P>V
PV+PP0.98741 / L.S. PP vs PV
10.9838<PV> / <PP>

Note the first line is the traditional least-square fit. The second line is fitting Powertap versus Vector, but then taking the reciprical to get the opposite. The third is the proposed balanced weighting scheme. Here it gives the same result to listed precision (but not exactly) as the average of the first two results, which is also clearly balanced. The fourth line is a simple ratio of averages. This places equal emphasis on the lower power points. It is also clearly balanced, and gives a result closest to the proposed scheme.

These fits have been to a one-parameter curve: a line of adjustable slope and zero intercept. A more flexible least square fit has an additional intercept term yielding two fitted coefficients. But the same approach can be applied there. The key indicator is that fitting y versus x should yield a slope equal to the reciprical of the slope yielded by fitting x versus y. The formulas described here still apply. First shift the points so the average values of x and y are zero. Then the formulas listed here apply to the slope. Slope is translation-invariant. You can then shift the points back and trivially calculate the intercept.

If the two axes have different units or if the uncertainty in the points is estimated to be different, then the following can be used:

kVP' = ∑(PP / σP + PV / σV) PV / ∑ (PP / σP + PV / σV) PP

where σP is the uncertainty in PP and σV is the uncertainty in PV. If σP = σV then this the new terms obviously cancel.

Wednesday, June 18, 2014

Old La Honda: 3rd week in a row

Today was my third consecutive week of Old La Honda. So I moved the Powertap wheel to the Ritchey Breakaway and took that to work.

At the start, my legs felt fairly good. I'd ridden into work Tue morning (75 km) with some moderate intensity. On Monday I'd ridden a short ride with some brief efforts, mostly on the flats, partly to compare Vector to Powertap on the Winter Allaban. Sunday I'd done nothing. Saturday I'd done some steep hills, again to compare Vector to Powertap. So there'd been no really depleting rides in the bunch. If I had one thing against me my calories the previous day had been on the low side, considering I'd ridden in.

It was nice seeing my old friend Randy at the start. He'd been traveling and it was good hearing about that. Also there was Chris & Greg, two very fast climbers. Kieran wasn't there, nor was Mark.

This was to be the last Wed noon ride before the NCNCA championship race on Saturday, up the north face of Mount Diablo, approximately half-way to the junction. Still, despite being only half the total, it's a legitimate climb: 10 km and 530 meters vertical. It starts with a short climb, then a very brief descent, then after a brief climb out of that hole there's some gradual climbing until the real climbing begins at 2.2 km from the star. There's two brief recovery sections, one at 4.4 km, the next at 6 km, but the last 3.8 km holds a solid 6.7%. There's some undulation in there including two brief steep sections.

Anyway, the fast guys were feeling frisky and Chris and Greg went out at a full sprint. Randy briefly followed, but deja-vu with last week with Mark, he relatively quickly gave that up and was dangling in front of me. My start had been measured almost to the point of distress. My Powertap was telling me I was doing the right thing, but my legs didn't have that "this is so easy; surely I'm going too slow" feeling I have early in a climb when I ride it at an even pace.

Sure enough, I transitioned too soon from the "gotta keep the power down" mode to the "gotta keep the power up". Not good.

As I climbed, I watched my lap-average power in desparation as it ticked down from 278, 276.... taking an unfortunate dive down to 270 at one point where the grade levels out. I try to shift upshift at these points, but when I'm fading, it's tough.

I slowly closed the gap to Randy, finally reaching him at around 75%. I led for a bit, he stuck to my wheel, but then when we reached end game he went to the front and I followed as best I could. He slowed toward the finish and I pulled next to him so we finished very close in time, fortunately on the correct side of 19 minutes (18:51.6). But this was substantially slower than my 18:30 target.

Here's running average of power:

image

Final power was 270.7 watts. I'd hoped for 275 last week and got 274. This week I'd hoped for 278 and went the wrong way. Despite the inferior power I still managed to reduce my time. Apparently the headwinds from last week had subsided.

From the plot, it's clear, however, that my pacing was much better than last week, even if it didn't help. I managed to almost catch my fading schedule from last week at km 3, but then instead of sealing the deal, I faded even faster this week and fell 3+ watts short.

Here's watts versus distance for the 3 weeks, smoothed by 20 seconds:

image

This plot adds some context to the running average plot. Part of the issue was a slow start. Indeed, I started further back then I'd been doing, in part due to chatting with Randy leading into the climb, and that dug me into an immediate hole on average power. Once I got going, my power wasn't all that lower than it had been the previous two rides, and indeed I put in a rather high surge from kilometers 2 to 3 this time. There can be no advantage to "resting" at the beginning of the climb: a start at or even just below a final average is one thing, but more than 10% down and you're just digging yourself into a deficit from which you won't recover since rest at that point does absolutely no good. I need to be more wary about hitting the bridge close to threshold. In any case, I did not sustain the power as well as I would have liked.

Ah, well. It's a stacked field at Diablo. My goal: don't reverse podium. Finish ahead of the last 3. I will have the advantage of not having ridden as hard the two days before. But I can only do what I can do and given all of the other things going on right now I should just be happy to be doing the race.

On the plus side, after stopping for a Naked Juice at the store at the top of 84, I felt better the rest of the ride than I had the past two weeks (when I also stopped for juice at the store). So perhaps my endurance is improving, if not my power.

Sunday, June 15, 2014

Vector - Powertap data comparison: crank length fixed in Edge 800

Last time I compared Powertap to Vector on my Winter Allaban, I had failed to properly set the crank length on the Garmin 800. I'd set it on the Vector, but the menu item on the Garmin is a bit tricky to find, as it only appears when it is in communication with a Vector, so if you scan the menus without activating the Vector and pairing the Edge to the Vector you'll never see it, as I did not. I actually first confirmed my Edge was asserting the wrong cranklength by running the settings.fit file through fitdump. But this is a digression.

I basically repeated my first calibration ride, heading steep 14th Street to Buena Vista in San Francisco and doing one-legged climbing on a more gradual grade, then riding home and doing a sprint.

I previously did three comparisons where the maximal power curves of the Powertap and Vector were remarkably coincident after I scaled one of the powers by an empirically determined factor close to the 85% value which I later discovered was the ratio of the programmed (144.5 mm) to actual (170 mm) crank lengths. These ratios were 84% (first ride, no washers), 91% (after adding one washer), and 86% (2nd ride with one washer). Since Vector measures power upstream from the Powertap I'd have expected a number of around 87%, considering drivetrain losses, so to me this seems consistent with the washer improving things slightly but requiring a settling in period following re-insallation. So I fully expected on this fourth test, with no crank length adjustment, to be as impressive except without any power scaling.

image

It was still good, but maybe my expectations were unreasonably high. Here's the maximal power curve. One expects the Vector to Powertap ratio to be higher at lower powers, since drivetrain losses fail to scale fully proportionally with power, and so the fractional losses are greater at low power, less at high power. But I wouldn't expect, except perhaps in sprints (<10 seconds), for the Vector to actually measure less than the Powertap. I plot two curves here for the Vector: one the power measured by Vector, the other the power which I'd expect to reach the Powertap, around 97% of the total (although the actual fraction would depend on power).

The ride was divided into parts. First I rode to Buena Vista, which included several blocks of steep climbing. These data I time-synchronized (despite hitting "start" at the same time on the Edge 800 and Edge 500, the data in the two are time-shifted, perhaps by auto-pause which I was too lazy to shut off). The main reference in time shifting is the cadence, since the Powertap and Vector both generally agree closely on cadernce. Then I take only time points for which both meters register at least 10 watts. This filters out marginal time points, for example where I might be freewheeling and registering power on the Vector but not the Powertap. Then I plot the Vector power versus the Powertap power.

image

The scatter in points don't mean much. The reason is that the two aren't measuring power at the same time interval. The Vector measues it once per pedal stroke, the Powertap once per wheel revolution. Even without this difference, they're not synchonized. So a lot of the power difference is actually time difference. If I take the average value of the Vector divided by the average value of the Powertap I get 98.4%. If I take the root-mean-squared, which puts a higher weight on high values, I get 98.7%. The slope in the plot is 97.0%, but that's a bit harder to interpret. In any case, the Vector is reading lower than the Powertap, slightly.

Then I did one-legged sprints. First I did right leg, then left leg, then on the same climb I did both legs. Here's right leg:

image

Then left leg:

image

So far so good: the Vector is reading a bit higher than the Powertap, as I'd expect for drivetrain losses. But then I plot both legs.

image

This isn't so good. What was up with that?

Here's some quick plots I did with xgraph, looking at cadence. First, the cadence on the steep climbs up to Buena Vista. Vector is green, Powertap in red. The two agree very well:

image

The Powertap drops cadence for a few samples here, but generally the two are in close agreement.

The following is the right and then the left leg pedaling. The Powertap is choppy. It gets confused by the blocky pedal stroke of a single leg. The Vector, however, uses the accelerometer, and produces nice smooth cadence. The Vector needs cadence to determine power, while the Powertap does not, so the Powertap power estimate is not affected by this choppy cadence estimate.

image


image

Now comes the 2-legged sprint. Here the Powertap is smooth cadence again. For some reason the Vector cadence estimate drops a bit on two occasions, at just before 2180 seconds on the time axis, and another time a bit after.

image

If I look at power during this bit, the Powertap and the Vector agree fairly closely, except at these dips where the Vector produces power dips. Since it uses cadence to determine power from force, this dip in power was inevitable.

image

The dips are dragging down the averages from the maximal power curve.

Why did this happen here? I'm not sure. The cadence is determined from the accelerometers tracking the direction of gravity's pull (or so I assume). Could the fact I'd recently clipped in affect this? I can see it affecting the torque measurement, but not the cadence. So I'm slightly puzzled. Was it something about my pedal stroke? If so, I might expect some anomaly in L-R power, but L-R is spot on 50%:

image

Overall, the test confirmed that I'd fixed the problem with the crank length. Additionally, the two power meters were in very respectable agreement, well within the stated accuracies of the units until you factor in the drivetrain losses. I definitely want to do another run.

Friday, June 13, 2014

A Tale of Two Sprint Workouts

Thursday of both last week and this week I did a sprint workout. This involved cruising over the Sunnyvale Trader Joes, buying some rice tortillas, goat chedder, and organic blueberries, stuffing them in my pocket, then cruising residential Sunnyvale streets to the Steven's Creek trail. Along the way, on roads of relatively smooth pavement and with enough length between intersections, I do some sprints (4 each of the weeks). Then I cruise the Steven's Creek trail back across the freeway mess and do a few more (2 the first week, an extra the 2nd week when I sprinted for a green light).

I'm not sure how much these help the sort of riding I do. But I think improving the top end potentially offers benefits at lower powers, as well as if I need to put in hard efforts to close gaps. I've not been a position where I was sprinting to win races in quite a long time. But sprint repeats challenge multiple aspects of riding: muscle strength, neuoromuscular coordination, pedal smoothness. Plus, they're fun.

Last year I set a Strava goal of 700 watts for 5 seconds. This year I increased that to 705 watts. The best results come when the road is slightly downhill and transitions directly to a slight uphill. Then I can build up speed without working hard, transition to the uphill, and immediately punch it not to increase speed but just to hold the speed I have. Doing this I can apply my maximum power at a relatively optimal, unvarying cadence without shifting. For 5-second power, shifting is death. Consider pedaling 2 strokes per second, where a shift takes 1/8th of a pedal stroke. Then that's 1/8 of 10 pedal strokes in 5 seconds, or a 1.25% loss of power, around 10 watts. Indeed, I hit my 700 watt target last year on exactly this sort of terrain. From my present job good sprint spots are hard enough to find, sprints with the down-up transition are substantially rarer. So most of the time I just sprint on flat roads. My sprints discussed here were on flat roads.

After rides the first thing I typically do is check my maximal power curve. In this case my obvious interest is in 5 second power. 1 second power isn't very reliable, especially with a Powertap (I'm discussing Powertap power here: Vector power would be higher). Power numbers get more reliable the longer the time interval. 5 seconds is a good duration for sprint power.

So in this case the first week my maximum 5-second power was 691.4 watts on my 4th sprint. My 2nd week my maximum 5 second power was 688.2 watts on my 6th sprint. So based on this I was stronger the first week, right?

Well, no. Strava will calculate a maximal power curve for the whole ride but I'm nore interested in looking at each sprint separately. So I did this myself, using Perl scripts. Here's the result for the first week:

image

The 4th sprint was by far the best. The 5th was aborted when a Google employee, riding his Google bike toward me, decided to veer from the right side of the road to the left, directly in front of me, and I had to brake. My 6th sprint was then truncated by workers on the road. But I had no such excuse on 1-3. It had been a long time since my previous sprint workout and clearly my legs took a few attempts to remember how to do it.

Here's the result for the second week:

image

Here my sprints were much more consistent. The final, 7th sprint was just to catch a green light. It came relatively soon after the 6th and I only sprinted hard enough to catch the green, so it barely counts. The weakest sprints were 1 and 5. #1 was my first of the day and that's never my best. #5 came after the long gap from riding the Steven's Creek Trail, which is unsuitable for sprinting. #6 was my best.

These observations are reinforced in the following plot, which is the maximum 5-second power for each sprint workout:

image

Wednesday, June 11, 2014

Old La Honda, take 2

After last week's disappointment on Old La Honda, I did a sprint workout the following day (Thursday), then rode in at tempo on Friday with Jason. But there was no riding through it. I was cooked. I needed some days off.

Saturday & Sunday were total "rest" (actually doing home stuff which absolutely needed doing). Monday and Tuesday I was still feeling fatigued, so I took the train to work, riding only to-from the train. Finally, today, I felt energetic again, ready for another try at Old La Honda.

Like last week, Greg and Kieran set a ferocious pace from the start, with Mark in tow. I let them go. But unlike last week, I wasn't in a chase pack, but rather solo. But also unlike last week, Mark didn't try to hang with the leaders too long. He dropped off and paced himself very nicely the rest of the way.

And the whole rest of the way I chased him. I focused on trying to maintain a steadier pace this time: keep a cap on it at the beginning when I felt good, then as it felt progressively less good, try to keep the power from dropping too much. I was successful at this, even if I was unsuccessful at catching Mark, who dangled in front of me the whole way.

Running average power tells the story. Despite feeling I was holding back at the start, I was actually doing about the same power I'd done the week before. But from there, while I did fade, I faded much less.

image

Here's the power itself, smoothed by 20 seconds. Up to 2 km I was holding it fairly well in the 285 range. From there I dropped back into the high-260's. I ended up with an average of 274.0 watts for the 18:56 it took me to reach the top. This was 1 watt shy of my 275 watt goal I'd set.

image

An interesting thing is my power was 3% higher but speed was only 1% higher, and I don't think I'm any heavier. This suggested wind was a factor, and indeed, looking at the wind map, it was a direct headwind. Old La Honda is substantially shielded from headwinds, but it's not completely immune. It doesn't take much for a 2% speed hit.

Here's the time advantage to the same altitude:

image

This shows a finishing 16 second gap instead of the actual 12 second gap because of differences in measured total altitude change (4 seconds of today's ride got truncated in this experiment). Consistent with my power data, my advantage this week was more towards the end. Note the advantage plateaus toward the finish, but that's partially an artifact of the altitudes not being synchronized (my rate of climbing increases towards the finish).

Anyway, not so bad, although the time reduction wasn't what I wanted. I'd love to be over 280 watts, but that doesn't come out of nowhere, and I've simply not been doing the miles necessary nor the intensity long enough to get there yet. But hopefully I'll improve some more by next week. Then comes the race.

Monday, June 9, 2014

comparing Powertap to Speed-Power model

I typically use my Powertap on training rides, but when racing, I've not done so since I placed third Ross's Epic Hillclimb up Pine Flat Road in Sonoma back around 2008 or so, At the climb, I'd decided the added weight of my Powertap wheel was worth it for the pacing advantage of power. Unfortunately, my battery died on the start line, so I carried the substantial extra mass of the Powertap up the hill for no advantage. Despite the lack of power, though, I had arguably the best climb of my life, staying with a critical surge I might well have not gone with had I been pacing off the meter. That surge led into a flat/slightly descending part where being with the group was a critical advantage. When the climbing began again, steeply, I felt as if I was going to crack, but then most of the others cracked more. Without the weight of that wheel I may well have been one place better.

But power is also useful for post-ride analysis. But for that, I rely on the standard power model. For climbs it requires reasonable estimates of rolling resistance coefficient, total mass, wind resistance coefficient, and air density. Air density is predictable from altitude, or if you look at nearby meterological data (which I rarely do), adding in barometric pressure and maybe, if especially fanatical, relative humidity. For modeling power meters which work ahead of the drivetrain you also need drivetrain efficiency, but not for Powertap data, which measures downstream of the drivetrain.

I decided to compare the model to my Powertap data from Old La Honda this past week. For CdA I used 0.45 m2 which is likely suitable given I climb on the hoods or tops (Tour magazine measured 0.32 m2 for a dummy in the wind tunnel, and this number has been found to work well for pro cyclists when analyzing race data). For air density I used 1.226 kg/m3 but then adjusted it for measured altitude, exponentially with a reference altitude of 8150 meters (this has relatively small but observable effect on Old La Honda). The rolling resistance coefficient I set to 0.4% which would apply to inflated tires on smooth pavement. This may be optimistic for parts of Old La Honda but the pavement is presently in very good condition by historical standards, as it has been for several years. For mass I used an estimate of my own (58 kg) with additional estimates of my bike (8 kg) and of "other stuff" (2 kg). This estimate is likely slightly low, in particular the "other stuff" which includes clothing, helmet, tool bag, Garmin, bell, pump, and water bottle (around half-full).

Anyway, without any specific calibration, the model fits fairly well. Here's the result:

image

Any conclusions I might gain from the power meter data would also be gained by the model, with the possible exception of that anomalous spike in modeled power at 2.2 km. There's also a significant underestimate in measured power from 3.2 km to 3.8 km.

So what causes that spike? To answer that I set the inertial mass to zero in the model, and presto, the spike was gone. Of course inertia is an important part of cycling kinetics. Acceleration requires power, and decelleration returns it. But the issue with inertia is it amplifies errors in bike speed. In this case I was calculating speed from GPS position, and GPS position is subject to noise.

But the Garmin reports speed directly as well as position. It gets speed from the Powertap wheel, which measures it directly. So I used this speed instead of calculating it. That solved the problem.

Here's the result:

image

So the model works quite well. Sometimes power appears a bit shifted relative to the Powertap, but the overall trend is clear: I was running out of gas. Had this been a record attempt, having left my Powertap wheel at the bottom, I likely would have had a valid analysis of my effort.

Thursday, June 5, 2014

Old La Honda: Meh

I did the Noon Ride again on Wednesday, up Old La Honda, and I had high hopes. I'd had a recent block of training since the last time I'd done it 6 weeks prior, including the 4-day Memorial Day Tour, always good for a fitness boost. But I'd been feeling fatigued in the 1.5 weeks since the tour. Wednesday, riding out to the Noon Ride start, was the first time I felt legitimately good. Not frisky, race-ready good, but "I can climb Old La Honda" good.

At the start, Maciek from SF2G asked what my goal was. "I've got to do 18:30", I told him. I figured just lay it on the line there. 18:30 is a decent time on the Ritchey Breakaway, which I was riding. With Powertap wheel, no bottle, no GPS, no toolbag, but with pump and two cages it's 18.32 lb. That probably made it the heaviest bike on the ride by a decent margin, but still, not too bad.

Hitting the base of the climb I was near the front, but got pushed toward the back when we had to wait for oncoming traffic. A group including Keiran Sherlock, Greg McQuaid, Mark Johnson, and one other separated itself immediately. I was seeing 300 watts on my Powertap (returned to my Ritchey from the Winter Allaban, on which I'd been doing comparisons with the Garmin Vector), so there was no way I was going to try to bridge up to them. I figured Keiran and Greg were gone. The other two I wasn't sure.

So I bided my time in the second group. We motored along at a good pace, and every time I looked at my power it was over 280 watts. If I could sustain that, it would be amazing, like peak-fitness amazing.

Eventually the predicted group-fade occurred, as I never believed the group was going to stay this pace to the top. So I moved to the front and kept the same speed as before. One rider followed for a bit, but then he, too dropped back.

Maciek, however, was hovering behind. I didn't realize this until I looked at the replay on Strava Labs. Then when I faded a bit, he did not, and came past on the inside of a steep switchback while I went wide. This is a good move if you have the anaerobic oomph in your legs. I rarely do.

He got a gap quickly, but I was focusing on the long-term, and hoped to first contain the gap then to bring him back. But I was in too much discomfort. The rest of the way was an exercise in suffering through. I reasoned with my running base and the volume from the tour, I could push myself through more than usual.

And I did, but it wasn't fun. 18 minutes came and I wasn't particularly close to the finish. 18:30 passed and Maciek was finishing ahead, but I still had a painful distance remaining. I crossed the stop sign at 19:08.355 (note: I use fitdump to read this directly from the FIT file, since I marked my time with a lap, and the lap time is stored there).

Ugh.

On the plus side, I was clearly not 100%. I felt trashed at the summit, and had to stop for a Naked juice in the summit store. The whole ride home I was running on empty. Just the day before I was feeling sluggish, yet had tone a hard steep hill workout in San Francisco. This helped awaken my legs, but it simultaneously added a dose of muscular fatigue. Hopefully in a week I can improve substantially on this.

So this makes my last three times up Old La Honda 19:03, 19:14, and 19:08, going back to last November a remarkably tight cluster. Here's a plot of the running average of watts on the three efforts:

image

Despite the closeness of times, the powers substantially differ, perhaps due to body mass differences. Curiously the ranking of final average powers are perfectly predicted by the average powers 10% through: more power after 530 meters = less power after 5.3 km. I didn't plan to fade so badly, of course. I thought I was being restrained sticking with the second group. But clearly even this was more than I could sustain.

Hopefully I can do better next time. I need to do better, much better, if I'm going to do anything at the race on Diablo on 21 June. So I boldly set an 18:20 target for myself on Strava. It's possible. I had "excuses" the first two (first OLH post-injury, first OLH after switching back to cycling focus from running) but the third my only "excuse" was feeling crappy post-MDR. But maybe the fitness from all that work will break through.

Wednesday, June 4, 2014

Vector vs Powertap ride #3: crank length problem solved?

The plot thickens...

Another day, another ride. This time I made sure to do a static zero test before the ride. I further checked that I had the latest firmware in my Edge units (Mac WebUpdater says I did). I was full of hope that the crank length fix had corrected things. So I set off on a ride to fetch new contact lenses, but where I took "scenic detours" up five significantly steep, significantly painful climbs in San Francisco. For the record: 17th from Market to Twin Peaks (and on to Twin Peaks summit), Sanchez from 17th to 18th, Church from 18th to 21st, 21st from Church to Sanchez (these two are contiguous, but I took a break in between, not initially planning to ride 21st, which is daunting), and finally, just because I felt like I could, the ever-painful 22nd from Vermont to Carolina.

No luck. My suspicion now is that the head unit is overriding the crank length setting. Issue is I don't know how to change the crank length in the head units. In the 510 or 810: no problem. There's a menu for that. But I can't find it for my 800 or 500.

image

Here's the data. First I show the maximal power curve. Note this time I get a decent match with an 86% scale factor. This is back to the first of my three rides, the one without the spacer, where I used a ratio of 84%. The second ride had a ratio of 91%. That one may have been an anomaly. It was my first ride after reinstalling the pedals. There seems to be a settling in time with Vector, which has been observed before.

I check my LR balance for sanity. This ride was a bit different than the previous two, but same general pattern.

image

I then added a new plot: with the maximal power curve comparison, instead of plotting power versus duration, I plot the ratio of Vector to Powertap powers for each duration versus Powertap power (duration hidden). This is a remarkable plot: the scatter in data is within 1%. Of course the units claim that this should be the case, but I don't trust such claims, which I expect are based on riding in a controlled environment at fixed cadence on a stationary trainer. There's two trends of note. One is the ratio initially decreases with increasing Powertap power. This makes sense considering the expected trend in drivetrain efficiency, which increases with increasing power. But then there's a precipitous drop. I suspect this is due to the way Powertap calculates power over an integral number of wheel rotations rather than over an integral number of pedal rotations. Integral pedal rotations, used by pedal and crank-based power meters, is preferred. But this plots my "by eye" determination of 86%, which applies over much of the power range.

image

So what's the problem? By far the most likely explanation to why I've tried twice to set the crank length to 170 mm and failed twice is that the head unit is overriding my selection. The philosophy is if a user sets a crank length for his different bikes, transferring the Vector from one to the other, he will select different profiles on his head unit, and shouldn't need to reprogram his Vector. This makes sense.

But why have I seen no crank length option on my Edge 800? Apparently the options only show up when the Vector is "detected and active" (according to support). I probably checked only when this wasn't the case. But there's another way: the file Garmin/Settings/settings.fit on the Vector has the length encoded within. I can check this with the Perl module Garmin::FIT which comes included with a very useful "fitdump" utility. I ran this on the Edge 500 and I get 0xfe, which corresponds to "auto". On the Edge 800, on the other hand, I get:

> fitdump /Volumes/GARMIN/Garmin/Settings/Settings.fit | grep -i length
crank_length (19-1-UINT8): 144.5mm (69)
crank_length (19-1-UINT8): 144.5mm (69)
crank_length (19-1-UINT8): 144.5mm (69)
crank_length (19-1-UINT8): 144.5mm (69)
crank_length (19-1-UINT8): 144.5mm (69)

144.5 mm! On one hand, this seems silly for a default. On the other hand, had it been 172.5 mm, the problem would have been much tougher to identify since the error would have been only 1.5%, consistent with drive train losses. But I'm not sure why it wasn't "auto". Note it's 144.5 mm for all of my bike profiles, not just the "Vector" one. So this wasn't a problem of me mis-setting it.

I then paired the 800 again with the Vector then went through the menus to my bike entry for Vector power. I initially looked for crank length under the "ANT+ Power" submenu and didn't find it. But then there it was under the main list of bike parameters. Indeed, it was 144.5 mm, overriding the value I set with the Vector Updater. I set it back up to 170 mm. I should now be ready to go.

Monday, June 2, 2014

Vector vs Powertap Comparison Pt 2: adding one spacer

Last time I did a comparison of my Powertap versus Vector. I'd had strong reason to believe the Vector was reporting low, and the test confirmed it. The maximal power curves lined up fairly nicely when I multiplied the Vector power by 0.84 (emphasis on fit to high powers). Since the Vector should measure more power than the Powertap, this indicated an error somewhat greater than this.

You'd expect the Vector to measure more power, because the Vector power includes power which doesn't make it to the rear hub and is instead lost in the drivetrain. This power loss includes losses which are proportional to load (like bending the chain under a high-tension state at the top of the run) and losses which are independent of load (like spinning the pulleys). The result is that drive train losses, as a fraction of total power, are higher at lower powers than higher powers. What I saw was consistent with this, which was a good sign.

The obvious candidate was that I'd not inserted any washers under the spindles. The Vectors rely upon the pedal spindle bending a predictable amount under a given applied moment. This requires that the interface between the spindle and the crank arm be nice and constant: contact along a single ring, independent of how much the spindle bends. If the contact is along more than just a ring, then the calibration would have been incorrect. Had it been calibrated to your specific set-up, this would have been fine, but it's calibrated at the factory, so you need to make sure the spindle-to-crank contact is as close to equivalent in your bike as it is at the factory calibration rig. This is why the spacers are necessary, and why the pedals should be installed with a torque wrench. I bought a torque wrench specifically because of the Vector, and use 300 lb-inches (25 lb-ft) as recommended.

I'd hoped my White Industries Cranks, with their relatively flat faces, wouldn't require a spacer, and so I could minimize my pedal stance, since I have narrow hips. The spacers add only a few mm to stance, but over the course of hundreds of thousands of pedal strokes, even a few mm has an accumulated effect.

But after my first test, I decided to add one spacer to each pedal. I then went for another ride: to watch the Escape from Alcatraz with Cara, then climb the Headlands. I did this ride, despite legs still feeling tired after the Memorial Day Tour, the recovery from which was somewhat retarded by a challenging SF2G last week via a mountainous coastal route which included two extended dirt sections.

image

Alcatraz was super-cool, watching the swimmers emerge from the 57F water to the long swim-to-bike transition run. I simply can't contemplate swimming in that water, which I've seen people do without wetsuits. Even with a wet suit, just jumping in hits you with an icy cold shock. Not for me, although the bike and run legs are highly attractive, the run including the infamous sand ladder climb which is a lot of fun.

image

But while I was at the race, my Powertap battery died. My Vector Batteries had started issuing low-battery warnings along the way, but that wasn't a problem, since under low-battery there's still plenty of time to finish a ride. My first-generation wireless Powertap's "low-battery warning" is that it suddenly stops transmitting.

So I was working with partial data, with none of the extended efforts I made during my three climbs of blustery, fogged-in Hawk Hill. The climb was perhaps less interesting than the descents, which included strong cross-winds. I took them relatively slowly, but I experienced none of the instability I'd felt on MDR. I think tightening the headset may have worked.

Anyway, here's a comparison of the data. Note I get alignment along the much of the curve when I multiply Powertap power by 0.91. So this is an improvement over the 0.84 I used without a spacer. To match the highest power, I'd have wanted to use a factor closer to 0.90. The lower fraction is consistent with what I noted earlier about drivetrain losses.

As a sanity check, here's the L-R balance again, adding this ride to the previous day's. Here I've adjusted power by the 0.84 and 0.91 ratios to get power more closely matched to the Powertap.

I was initially puzzled by what could cause this. Of course the obvious explanation was the crank length was set incorrectly. I can't check that on my Edge 500 or Edge 800: only the newer units, the 510, 810, and 1000 have the capability to interact that closely with the Vector. But of course I set crank length when I first set up the system.

I decided to upgrade the firmware, so after swapping the batteries, I plugged the Ant+ USB stick into my Mac, and ran the Vector updater. Sure enough, firmware was upgraded from 2.1 to 2.4. But then it provided a widget to set the crank length. Crank length was 144.5 mm, it said.

Whoa! How'd that happen? Obviously I'd not set it up correctly, or else one of the Edge units overrode the value I'd set. 144.5 mm is 85% of the correct value of 170 mm. The Vector measures cadence and force, but to get power you need an extra factor of distance, and that distance is proportional to crank length. So having 85% of the correct crank length yields 85% of the correct power.

I set the crank length to 170 mm and went for another ride. That one didn't work out so well, however, because initially my Edge 800 which I'd been using to monitor the Vector wasn't displaying power, then I tried to sync with the Vector and it complained it found two separate power meters. Then I removed my Powertap wheel and put it half-a-block down the street, in a metal box, and finally the computer found only the Vector (I'd tried progressively less drastic displacements without luck before this). But it still wasn't reading power. So I power-cycled it and then it was reading power, but I must have neglected to hit start, because when I got home, the rest of my ride was missing.

So I'll try again. Hopefully this time setting the crank length stuck.

Note that if it does stick then I would get with zero spacers the Vector reading 1% below the Powertap. This is obviously incorrect since it would imply the drivetrain losses are negligible. But with the 0.91 conversion factor the Vector would read 7% higher than the Powertap. This would imply quite a high degree of drivetrain losses. But I need to see what my next test ride shows.

Sunday, June 1, 2014

Vector vs Powertap: data comparison (no washers)

On my relatively new randonneuring bike, which got its first serious long-distance test in the Memorial Day Ride (MDR) this past week, I've been using Garmin Vector Pedals I was lucky enough to get. The Garmin Vector, of course, offers the advantage of "true" left-right power, since it is effectively two independent power meters, one for the left, one for the right. But even though I've had the pedals on there for awhile, I've been ignoring the power data. I didn't trust it. It's not that I didn't think the Vector is a good product, but rather I didn't trust the installation decision I made to not install any washers. Of course, I could have just added the washers, but that would lose interesting data. I wanted to do a direct comparison with Powertap to quantify what the reduction in power, if any, was. Being generally lazy about this sort of thing, I procrastinated... until today.

In this post I compared power data versus climbing rate on the Cortland Hurl, comparing the Winter Allaban with the Vector versus the much lighter Ritchey Breakaway with a Powertap. The Allaban was measuring around 10% lower power than the trend for the Powertap, despite the bike being more than 2 kg heavier, which corresponds to a total mass difference of more than 3%. So that suggests 3% more power measuring 10% lower for a 13% error, or the Vector measuring around 87% total power of the Powertap. This is all very crude, however, and I really needed to do a 1:1 comparison.

So I moved the Powertap wheel over the the Allaban (one of my motivations for 700c instead of 650b wheels for the custom Allaban was to allow use of my existing wheels, including the Powertap). This worked fine, although the asymmetry between front and rear wheels was striking. Note the smaller rear wheel drops the rear, slackens the head tube angle, and increases the trail of the bike. But since the trail started at 3.6 cm measured, 3.9 cm designed, there was plenty of headroom on trail. The bike handled fine other than that the rear brake pads should have been closer to the rims (19 mm on the Powertap wheel versus 23 mm on my normal H Plus Son).

image

I set out at random in San Francisco, finally on a whim climbing 14th Street to Buena Vista, then doing one-legged drills climbs around the park. I then did the same little climb with both legs, then returned, finishing up with one slightly uphill sprint.

My left-right data was the same as it always is, with right-leg dominance at low powers, evening out at higher powers. I find it remarkable this is what I see every single ride. But is it trustworthy if I don't trust total power?

image

It's always tricky comparing power data because of synchronization issues. In my case, I started the two computers with well under one second time difference, but then I had them on auto-pause, so perhaps for that reason the Edge 500 (Powertap) data stream began 60 seconds after the Edge 800 (Vector). In any case, I find the simplest way to compare data is to plot maximal power curves, since that uses average powers over durations, and is insensitive to time shifts (except as they affect data sampling).

The result is as follows:

image

The curve shows the maximal average power over each interval. So for example for 60 seconds it finds the 60 seconds with the highest average power, and plots that average. Looking at the solid lines, the Powertap is measuring consistently higher than the Vector. I tried multiplying the Powertap by various factors until the two curves matched by eye, and the match with the 84% multiplication factor (see blue dotted line) is remarkable. I in general wouldn't expect an error to be so systematic. The fact it comes so close to a straight 84% scale factor suggests that there's a simple reason for the problem. The obvious suspect is the lack of a spacer.

But this is just total power. Maybe the error came all from the left foot, or all from the right foot, invalidating my left-right balance numbers. So I checked that by looking at my single-leg climbing efforts.

image

image

These power-versus-time curves during the one-legged sprints, with 5-second smoothing, show that the 84% scale factor works fairly well for either foot. It suggests the error on the left and the right sides is essentially the same. If there were a defective unit, either the left or the right would be defective, or they'd be defective in different ways, rather than their being defective in the same fashion. This is why I suspect the installation error.

Of course it would also be possible the Powertap was in error. But I've validated the Powertap with torque tests (see the borrowed wheel in this post) and in predicting the grade of Filbert Street consistent with reported values. So I have more confidence in the Powertap.

But the two meters measure power in different places. But the Vector should additionally measure the power lost to the drivetrain, typically 2-3% at high powers (see FrictionFacts) and more at lower powers, so the 84% scale factor should actually be lower, for example 81% if drivetrain losses are 3%. Ideally the Powertap, not the Vector, should measure lower.

It's good to have validation of what I suspected. Right after the ride I installed the washers. I'll collect some more data tomorrow and see if that worked.