On Bicycles, and.... what else is there?

After last week's Powertap snafu where I tried pacing myself off the power meter only to later realize it was substantially over-reporting power, I wasn't feeling super-warm-and-fuzzy today about following the same approach in what was essentially a mandatory new attempt at the Wednesday Noon Ride. Using the calibration cycle on the Garmin Edge 500 had appeared to restore the Powertap to the regime where it was able to stay in tune during coasting phases alone, and the numbers I typically saw in the display were more typical of the pre-Switzerland mediocre Dan than the "suddenly blessed with amazing fitness" Dan the Powertap had been assuring me had replaced it. Chris Evans and Brian Schuster of Squadra SF were at the start, two very solid climbers, especially Chris who'd been putting in an impressive string of mid-16-minute Old La Hondas with his approach of starting each week with a leg-ripping effort which I can only imagine matching for more than a mercifull...

The last time I considered the constant cadence approximation as it applies to circular chainrings. Recall the principal issue is that the constant cadence approximation makes the following assumption for each pedal stroke: = × where ω is the angular velocity of the pedals, τ is the propulsive torque, and brackets signify a time-average. The error from this approximation is obviously: × − which is fairly trivially shown to equal: − ) × (ω − )> which is proportional to the correlation coefficient between torque and angular frequency, where a positive correlation results in an underestimation of power. Angular frequency is proportional to what I refer to as "instantaneous cadence": the rate at which the crank arms are revolving. So the issue comes down to whether the instantaneous cadence is correlated with applied torque, or similarly, if it's correlated with applied power (assuming applied power fluctuations are due more to torque changes than cadence c...

A big issue with power accuracy is to not only get the force versus time accurate but also to get an accurate cadence versus time. Power is the instantaneous product of propulsive force times pedal velocity, pedal velocity being proportional to cadence multiplied by crank length, and therefore errors in cadence translate directly to errors in power. It is typical in the power meter business that cadence is approximated as constant over a full or perhaps half pedal stroke. Indeed, Garmin has announced they are using this approximation on the Vector. This is of course technically incorrect: cadence varies over a given pedal stroke just as it varies from one pedal stroke to the next. Ideally cadence would be sampled at a sufficient rate to get multiple points within a half-pedal-stroke, so the variation in pedal speed between the strong and weak portions of the pedal stroke would be captured. I have previously looked at this issue and I concluded the power error would be proportion...

Last time I proposed an algorithm for pedal smoothness. I can hardly take credit for it, it was basically the reciprical of Coggan's variability index without the 30-second smoothing. It's fairly obvious to apply it to the pedal stroke, as well. Here's some data left over from the old Metrigear Vector blog, showing measurements taken with the Metrigear-era Speedplay Vectors. These data are at a much higher sampling rate than would be recorded by an Edge computer: they show the detailed power and cadence during just a few seconds of a longer "ride" (on the trainer): I used Plot Digitizer to pull points off the plot (off-topic: I really like Plot Digitizer; it's replacing g3data , which I previously used). Here's a view of a subset of those data. Curiously, the left leg is going negative power, while the right leg does not. The plot also shows total power, the sum of the L and R legs. This shows a strong oscillatory character: it goes from a ma...

In anticipation of the release of the Garmin Vector, or perhaps the Rotor Flow, Garmin added a pedalstroke quality field to its Edge-series head units in the recent firmware update. But consistent with the Vector-team's approach to not release anything which they won't stand behind, on the first public release of the Vector power meter, that field remains unpopulated. It's an interesting question about how important pedal technique actually is. I think most cyclists think if they can pedal in a smoother, more uniform fashion, their cycling will improve. This has been difficult to demonstrate in the laboratory, however. For example, a recent work by Arkesteijn, et al, used force-feedback to encourage riders to pull up more on the upstroke. This worked, improving the uniformity of force application around the pedal stroke, but gross energy efficiency of their cycling failed to improve. On the other hand, it appeared the smoother pedaling increased the ability of the c...

In the previous post I compared power from the Stages power meter to power from the Vector power meter (or meters, since L and R are separate) measured by DC Rainmaker on a ride he did in DC after the Vector release in Boulder, Colorado. Since Stages is measuring power only on one side of the bike, it is natural to compare the results with Vector, which measures power on each side of the bike separately. Before that, I showed that the Vector total power agreed well with Powertap and Quarq. If I assume that validates total power for the Vector, then it validates L and R power separately, since total power is derived from L and R power (the validation would be invalid if there were errors which naturally canceled between the L and R side, but I can't identify any). But Stages does one thing I really like: it measures cadence multiple times per second, instead of relying on an average cadence associated with the time for a full pedal rotation. The constant cadence approximation l...

I was at Interbike for the first time this year, and a big trend was crank arm-based power meters. There were at least three there: Rotor Power, Pioneer, and StagesOne. The fundamental physics behind each of these three units is the same: to propel the bike force is transmitted via a mechanical path: pedal body to pedal spindle to crank arm to (left side only) bottom bracket spindle to spider to chainring to chain to cassette to free hub body to spokes to rim to tires to road. You can in theory extract propulsive torque anywhere along this path, and when combined with rate of rotation, convert the torque into power. In the case of the crank arm-based models, torque applied to the crank arm bends it, a bending moment proportional to the torque. To decent approximation the bending is proportional to the moment, and is thus proportional to the torque, so if you can measure bending then with suitable calibration (for example, hanging a known mass from a pedal orientated horizontally) ...

An interesting issue came up in the Wattage list , and that is that the Cinqo (and presumibly the SRM ) calculate power under the assumption that the pedal cadence is uniform throughout the pedal stroke. This is an interesting assumption, worth investigating, in light of my recent discussion of Metrigear hitting its 1.5% power target. In my discussion on Metrigear, there were two principal limiting factors to accuracy: one was nailing down the pedal orientation, the other was getting the pedal rotation rate correct. For the orientation, the system was getting close after only 20 seconds of my simulation of highly variable cadence, a worst-case scenario. Results I didn't show were that if I simulate longer periods, the system continues to improve on its orientation determination, and can nail that down to a fraction of a degree. That's good enough to separate out the "propulsive" component of force. On the other hand, the primary challenge remained the determ...

Last time I simulated the Metrigear Vector cadence extraction using reasonable assumptions about vertical and longitudinal vibrations, and a quite arbitrary choice on differential vibrations (separate for the left and right pedal). The result looked fairly good, despite the fact my algorithm for extraction is just something I hacked together on my train commute, hardly a best case of what one could do. I'm not using all the information which is available. I'm not really using the transverse component of acceleration, for example. But let's take a closer look at those numbers... I ran 10 simulations, and for each time, I calculated the error in the rpm from the ideal value (pre-noise). I calculated the root-means-squared of these errors, and plot them here versus the ideal cadence: Cadence errors, in revolutions per minute, are plotted on the y-axis. Also plotted is a curve derived from a simple analytic model, based on the amplitude assumed for the differential noise....

I've done a lot of discussion about the MetriGear Vector . A brief summary of some conclusions. The Vector measures force components on the pedal. These force components can be derived from bending moments measured at at least two positions in the spindle. Power equals force in the direction of pedal motion multiplied by pedal speed. Pedal speed is rotation rate multiplied by crank length. Crank length can be derived from data, or instead as Metrigear has indicated, can be provided by the user. Providing it simplifies calculations. With a spindle firmly screwed into a crank, the propulsive direction is always the same, perpendicular to the direction of orbital (centripetal) acceleration. Acceleration in the tangential (propulsive) direction averages to zero, while the centripetal acceleration averages to a positive value. Determining which direction of acceleration averages to zero allows the system to orient itself, to determine which is the propulsive direction, without ...