Saturday, January 30, 2010

combining GPS and barometric altimetry: intro

GoldenEmbedA discussion on the GoldenEmbed mailing list got me thinking.

GoldenEmbed is an open source hardware project to produce an ANT+ compatible cycling head unit: one which can record power from a variety of ANT+ compatible power meters such as Quarq Cinqo, SRM, and MetriGear Vector. It's built out of some nice modules available from SparkFun, basically a modern version of what Radio Shack used to be: a source for electronic hobbyists. The project was inspired by the Quarq Qollector prototype shown at Interbike, and Tim Clark of MetriGear's similar ANT+ sniffer used in Vector development.

MetriGear data loggerThe MetriGear data logger which in part inspired GoldenEmbed

So some of the GoldenEmbed guys mentioned you could go beyond ANT+ sniffing and incorporate GPS and barometric altimetry: SparkFun sells all of the required hardware. Cool! This enables the development of the functionality Garmin provides.

So the question is: what's the best way to manage both GPS-based altimetry and barometric-based altimetry to get a single altitude profile? Well, first consider the characteristics of each.

GPS tends to be very accurate, but not very precise. The signal tends to jump around by a few meters from the "true altitude", and the signal tends to drop out when line-of-sight to satellites is lost.

Avocet 50
Avocet 50, the first barometric-altimeter equipped bike computer

On the other hand, barometric altimetry tends to be more precise, but less accurate. Barometric altimeters derive altitude from air pressure, given the air temperature. But at a given temperature and altitude, pressure can vary as the weather changes. This is a core feature of weather prediction: dropping pressure often foretells the arrival of a storm. So barometric altimetry needs to be calibrated. Barometric altimeters, such as the original altitude-enabled bike computer, the much-loved Avocet 50, needed to be initialized each ride with a starting altitude. Then the rider hoped for stable weather. Nevertheless, upon returning to the same spot hours later, the altitude had typically shifted.

So the proper approach is to combine the two: use the GPS unit, which tends to drop out and jump around, to regularly calibrate the barometric altimeter.

I'll describe more on that next time.

Friday, January 29, 2010

power accuracy and the uniform cadence approximation

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 determination of instantaneous pedal rotation rate. Whether that can be nailed to within the needed 1% or so needed for that 1.5% power target depends on the mangitude of the differential noise. I left it at that, since I don't know what that would be.

The crank-based units don't need to separate out the propulsive component of force: they measure propulsive torque directly. I assume they ace that part. The harder thing is rotation rate. Cinqo, at least, uses a traditional magnetic cadence sensor to get the rotation rate. That gives a ping every full pedal stroke, which means I need to make assumptions about how the rotation rate varied over that pedal stroke. The simplist assumption is it didn't vary: uniform rotation rate. If the number is different the next stroke, then right after the cadence sensor pinged, the rotation rate instantly changed to the new value, and it remained constant at that value through that next stroke.

So is this a good assumption? Well, assume applied torque is constant, and in pedal rotation rate is varying in some unpredictable fashion. All I know is the average pedal rotation rate through the full pedal stroke. What I need to calculate is the average power during the stroke. All good: the average of a constant torque multiplied by a variable rotation rate is that torque multiplied by the average rotation rate. I get the exact answer by assuming the rotation rate is constant.

But torque isn't constant, of course. It varies, just as rotation rate varies, and this causes a problem. To see this, consider another possibility: rotation rate varies, but torque also varies to keep applied power constant. Power is the product of torque and rotation rate, so this assumption can be stated:

τ = P / ω

where ω is the rotation rate, and τ is the torque.

Let's then take the simplest possible case: ω = ω0 ‒ Δω for half the stroke duration (time, not angle), while τ = P / ( ω0 ‒ Δω ), and for the rest of the pedal stroke ω = ω0 + Δω, with τ = P / ( ω0 + Δω ). Obviously, the average power is P, since I am assuming that the power is always P.

But what would Cinqo conclude? It assumes the average power is the average rotation rate multiplied by the average torque. Average rotation rate is simply ω0. Average torque's a bit more complicated, though:

average τ = P [ 1 / ( ω0 ‒ Δω ) + 1 / ( ω0 + Δω ) ] / 2

   = P ω0 / ( ω02 ‒ Δω2 )

So if I calculate the power from this, where PQ equals the Quarq-effective power, I get:

PQ = P ω02 / ( ω02 ‒ Δω2 )

   = P / ( 1 ‒ Δω2 / ω02 )

So if Δω is zero, all is good: PQ = P. But as Δω increases, the trouble begins: the Cinqo always overestimates. Suppose Δω = 10% of ω0. Then the error from the above equation is 1% of total power. This is already close to the full Metrigear error budget of 1.5%. Take Δω up to 20% and you blow it out: the error is 4% of total power. That's some serious cheese.

How much pedal rotation rate varies within a pedal stroke another whole topic. For example, it depends on whether riding is "high inertia" or "low inertia". In "high inertia" riding, the pedals tend to want to keep moving at the same speed, for example when riding downhill at high speed in a big gear. "Low-inertia" riding is when the pedals can slow down relatively rapidly: for example when in your granny gear on a mountain bike riding up a steep slope: let up on the pedals at all, and you'll come to a rapid stop. Also the effect on power depends on how applied torque is correlated with pedal rotation rate. The constant power assumption may apply more in some cases than in others. So it's a complex issue.

The Metrigear Vector will be an enlightening tool in this matter, since it will be able to report pedal rotation rate throughout the rotation circle. This will best be done on a trainer where vibrations are minimized. This will provide some interesting insight into how accurate the crank-based systems really are, not under controlled pedaling at uniform cadence, but rather under real-world conditions where everything is constantly changing.

Wednesday, January 27, 2010

simulating Metrigear Vector cadence extraction (pt 4: orientation)

To extract cadence from accelerometer data is the accelerometers need to be properly oriented. So I constructed a simplistic scheme to extract the angle from the accelerations. It's super-simple: just accumulate average accelerations, then calculate a transformation rotation angle which beings one of them to zero.

Consider the following diagram:

some acceleration components at spindles

From the perspective of the spindle, radial acceleration is always in the same direction. Tangential (I seem to alternate between calling this "tangential" and "transverse") acceleration is also always in the same direction, as long as the crank rotation is consistently increasing (or consistently decreasing). I also show a vector for road vibration. It's easy to see this will tend to cancel out over time for each spindle. When the spindle rotates 180 degrees, it's in the opposite direction relative to the spindle. The same deal with acceleration in the direction of motion. When the spindle rotates 180 degrees, it flips.

Tangential acceleration may always be in the same direction as long as the cadence keeps increasing. But of course, it doesn't. Eventually cadence slows, and so over time, tangential acceleration also averages to zero. Only radial acceleration is never negative, except for "noise", which also averages to zero.

So the deal is, if I calculate an average for acceleration along each of two orthogonal coordinates, I can construct a vector from these components. Eventually I know the direction of this vector will converge on the radial direction, and I'm oriented.

One can do a bit better, though. By realizing the transverse acceleration will have a non-zero component proportional to the average rate of cadence change, I can tweak the result a bit. I tried this, and it didn't really help; the adjustment was small in comparison to the error from noise.

So I implemented the simpler approach in my Perl script. Here's the result for the the same eleven simulated "runs" I showed before, with the same noise. For each time point, I calculated the square root of the mean square of the error.

RMS orientation error versus time

This error quickly drops below 2 degrees, then sort of hovers there, not fully converging to zero within the time scale of the simulation.

Less than 2 degrees seems fairly good. But is this good enough?

Consider I'm applying force to the pedal at 45 degrees relative to the propulsive (tangential) direction. In this case, 71% of the force is propulsive, 71% of the force is perpendicular to the propulsive direction (I know -- this doesn't add to 100%. That's vectors for you.) What if I'm off by 2 degrees? Well, in that case I make a 2.5% error in the calculation of propulsive power. Were the error 1 degree, this would be a 1.2% error. The goal is for error from all sources to be less than 1.5%, so even a 1.2% error is too much.

Furthermore, suppose my cadence is smooth and I'm riding on a smooth road during this time. I estimate cadence proportional to the square root of the radial acceleration. This results in a 0.03% error in cadence estimation. So that's a small error. The bigger deal in this example is the force component. For that, I need the orientation to be well within 1 degree accurate. I fail that in this test.

But the good news is these tests are relatively short. The longer I ride after reorienting the pedals, the better I can estimate the orientation. So within a minute or so, I should be good. And this example was for highly inconsistent pedal cadence. For smoother variation, it does better.

I have no idea how MetriGear does its orientation. This is just one approach which might be used. But even so, it's not too bad. Brim Brothers, as I've noted, don't have the luxury of sloppy techniques, as they need to reassess the orientation, almost from scratch, several times a second. That's a far tougher problem. If they can crack that, I'm confident Metrigear have the orientation issue under control.

Tuesday, January 26, 2010

simulating Metrigear Vector cadence extraction (pt 3: cadence accuracy)

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 versus 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. It's easy to see this simple model tracks fairly well: the differential noise (all that the analytic model considers) dominates. In the plot, the green zone represents a less than 1% error, while the red zone a more than 2% error. To hit a 1.5% accuracy target for power, certainly the cadence error, cadence being only part of the power calculation (the other being force), should be no more than 1%.

The result is this 1% target is hit only for relatively high cadences. Hmm....

Now recall when I was discussing this differential noise, I noted that the accelerometers themselves are capable of measuring acceleration to remarkable accuracy: well within the requirements of cadence measurement. So I suggested crank flex as a possible source of such "error". And I had to get rather pessimistic about crank flex to get the 0.25 g peak amplitude I'd assumed for the differential noise acceleration components.

But is crank flex "noise" or is it "signal"? That's complicated, really, If the crank flex means the pedal moves forward or backward in its motion, that's not noise: that's a real change in pedal rotation rate. We need to include that to get the correct answer for power. On the other hand, if the crank flex is radial (that is a relative change in the crank length), well, then that's clearly noise. We're using the acceleration in this direction as a proxy for rotation rate. Crank length fluctuations do not represent propulsive power.

I think it's safe to say the length of the cranks doesn't actually change much. However, it's possible that frame flex causes the povot point for the cranks to move around a bit. And if the povot point moves, that's similar to the crank length changing.

But back a second to that crank length question: in reality, with flexing cranks the L & R pedals are not necessarily rotating at the same rate. I average the L & R accelerations to get a single rotation rate. This will introduce a bit of an error. But it's not likely as big of an error as assuming all crank flex is "noise".

So the key question is what the magnitude is of this "noise" term? And that's not so easy to measure, because as I noted, some of the "noise" is actually signal: real differences in the rate of pedal rotation.

So I did the previous analysis again, but this time instead of being pessimistic, I was optimistic: I shut off the differential noise term. Now all that's left is the vertical and horizontal noise. These "leak in" to the error since the pedal orientation may not be known to perfection, so the averaging of the left & right components fails to perfectly eliminate road vibration and translational acceleration.

Here's the result, where I keep the analytic model used before to facilitate comparison:

cadence models without differential noise

Now noise is a lot less. Here the 1% target is hit down to around 50 rpm. And this result is only a few seconds after the pedals were re-oriented, so with more time to nail down the pedal orientation, it would improve.

It's tempting to reduce the influence of these noise terms by filtering, with more smoothing applied as the cadence drops. But just because the crank is rotating slowly doesn't mean that high-frequency components are no longer of interest. Road vibrations may cause the chain to oscillate, which causes fluctuations in the rate of crank rotation. So personally I'd not want to do any sort of cadence-dependent filtering. But if RPM is detected by radial acceleration, that may be prudent for low cadences, since this acceleration component is proportional to the square of the cadence and therfore diminishes rapidly.

An aside: whenever noise is a factor, the more information you can use, even if that information is redundent, helps accuracy. In this case, there's that transverse acceleration component. It doesn't give cadence directly, but does in theory give the rate of change of acceleration. That might be useful, but not without substantially complicating things. I'll leave that alone for now. I like simple: it's complex enough, especially for my train commute.

Next time I'll look at the orientation extraction accuracy.

Monday, January 25, 2010

simulating Metrigear Vector cadence extraction (pt 2)

Back to modeling the Metrigear Vector with my little Perl scripts...

First I modeled the "inputs". I assumed vertical acceleration noise, affecting each pedal together, was around 1 g peak amplitude. I neglected internal modes, which I assume are too high frequency to affect the signal. So my vibration signals were simular to those described in this post.

For longitudinal noise, also affecting each pedal together, I assumed less amplitude: around 0.5 g.

I then added an additional noise component which affects each pedal independently, assuming a peak amplitude of around 0.25 g. Honestly I pulled this number out of thin air. Microaccelerometers typically have a noise density measured in the tens of micro-g's per root Hz. Electronic noise on the accelerometers isn't an issue, unless they're terribly starved for current. So the noise would have to be an actual acceleration noise. For example, crank flex would change the orientation of the spindles relative to each other. But crank flex is relatively small: for example 3 mm peak-to-valley. For this to yield 0.25 g requires a component with this amplitude at 6.5 Hz. Typical pedal rotation rates are around 2 Hz in a sprint. So 0.25 g seems on the high side for this sort of differential acceleration noise. But I'll intentionally overshoot, as maybe I'm overlooking something, and I want see how well I can do even with pessimistic assumptions.

This last component is really the one that matters most. The other two ideally get canceled in the averaging. However, noise in the vertical and horizontal acceleration will affect the orientation determination, and an error in orientation makes the averaging imperfect (some leaks through). So I plot a sample distribution of noise values in the following plot. I've succeeded in generating a distribution which is essentially confined to the ±0.25 g range.

component of noise assumed independent for L & R pedalHistogram of pedal-independent noise components

On top of these I added a acceleration associated with bike motion. I assumed the rider did not shift, so bike speed tracked cadence. I neglect accelerations from the bike leaning or turning. Consider these part of the "noise".

So then I modeled the "outputs". I first have the system try and orient each pedal, not initially knowing how they're oriented. Then I extract the radial acceleration components. Then I average these, as I described, and extract the cadence.

I ran this simulation multiple times, in each case with the left and right pedals given a new random orientation. Additionally, the noise components were re-randomized in each case. Here's the results of five of these runs:

simulated Metrigear cadence extractionsimulated Metrigear cadence, with "actual" cadence plotted in black

This is quite interesting! You can see the rider starts to pedal slowly. It takes a few pedal strokes for the "virtual" Vector to lock in on the spindle orientations. But remember it probably doesn't need to do this every ride. Just every time the pedals are adjusted or moved.

Once it figures out the orientation, it does quite well as long as cadence is above 30 rpm. Below this cadence, the orbital acceleration of the pedals is relatively small in magnitude, and the noise (which I've associated with really bad crank flex, but here may be other sources) becomes more significant. As rpm's increase though, it tracks very well.

This isn't hard to understand. I'm assuming 172.5 mm cranks. So at a cadence of 36, the orbital acceleration is 0.25 g, which is the peak amplitude of the noise. So when the cadence rises much above 36, the noise becomes a relatively small perturbation to the ideal radial acceleration. The good news is if cadence is this low, things are changing fairly slowly, so the data could be "smartly" smoothed to reduce the influence of the noise. My algorithm isn't that smart, however, not yet, anyway.

Of course, the rub is that I arbitrarily picked 0.25 g for this differential acceleration. Better to use real data, of course.

I'll take a closer quantitative look at these results next time, and see if they're good enough to hit a 1.5% accuracy target. I think it's fair to say it looks pretty good.

Sunday, January 24, 2010

Dolphin South End Runners Club Waterfront 10-miler

Today was my first road race of the season -- running road race, that is. In late 2008 I seat a goal of racing the Austin Marathon in 2009. It would be a fairly tight schedule, but I'd thought I could do it. Things were going well, as I raced first the Dolphin South End Runner's Club Embarcadero 10km road race, then the Pacific Coast Trail Runs Woodside 17 km, then the Run Wild for a Child 10 km road race. But then poor health following a cycling trip to Thailand and Laos put a stick into the spokes of that idea. But I built back some running fitness in time for the Enviro-Sports Woodside half-marathon trail run in Feb 2009.

Cycling took my focus back after that. But in fall of 2009, I returned to a running/cycling mix to my activity. Unfortunately my enthusiasm got the better of me, though, and I ramped up my runs too quickly. Ever since then, I've had issues with my left leg, primarily the ITB. But I've been working on that, and it's coming around.

So finally this season a return to some racing. Last weekend I did the Coastal Trail Runs 17 km in Woodside (the same course as my first trail run), then this weekend, a return to my favorite low-key running series, the Dolphin South End Runners races. This time: the Waterfront 10 miler.

This race was on the same course as the Embarcadero 10km, except it goes further: past the Ballpark, cross the bridge on 3rd St, along Terry Francois, then left on Illinois to the turn-around at 5 miles. Return. All roads I know very well.

My goal: 70 minutes. I knew that would be a bit of a challenge, as I've been doing absolutely no speedwork this year, just focusing on getting some endurance without hurting myself. My trail run last weekend was my first bout of fast running. And that was virtually all up or down and on dirt or relatively soft trail surface.

It's really hard to keep enthusiasm at bay during the start of a running race. I felt we were doing a nice pace, slightly fast, when someone nearby wearing a Garmin told me it was a 6:15 mile pace. Whoa! No way I could sustain that. So I throttled back, tried to find a rhythm I could find tolerable for the more than 9 miles remaining.

Despite slowing, I still hit the first mile marker in around 6:40. I was ahead of schedule, and fast starts are always punished in running. But I wanted to keep my mile splits in the 6:50 to 6:59 range the rest of the way. I was feeling better than expected. If I didn't do anything dumb, 70 minutes looked fairly doable.

I almost did that. I lost a bit of time near the turn-around on an uphill, but near the end I really did start to fade. Still, it's important to not let goal-creep get you down: I handily beat my 70-minute target.
Here's some numbers:

10 mile race splits

Note the plot is mislabeled as 10 km rather than 10 miles...

Sure, I would have liked to be faster. I would have liked to not have faded. But hey: reality check! Each of these miles was one of the ten fastest miles I've run on level ground this year. I faded, but I never cracked. I'll put that in the bank and move on.

And, more important, I seem to have handled the effort okay, soreness-wise. So hopefully I can build on this one, rather than having it break me down.

My 10 km splits weren't so great in comparison to my goal of beating 40 minutes at that distance, this was a longer race, my longest road race ever, and so obviously it's going to be a bit slower. On the other hand, were I to extend it out to a marathon, it's 3:02:37. I'd still like to qualify for Boston, maybe in 2011, and this shows I have some room to give up pace and still do that. Obviously I'd need to get a lot more solid training in to do a full marathon, though.

Next race: back to Woodside for another Pacific Coast 17 km trail run in Huddart on 6 Feb. I love that course! It conflicts with the San Francisco Half Marathon on the same day, but while road running is fun and is good for setting absolute time goals, running trails is such a wonderful experience, I'll go with the trail run this time.

Saturday, January 23, 2010

simulating Metrigear Vector cadence extraction (pt 1)

I've done a lot of discussion about the MetriGear Vector. A brief summary of some conclusions.

Metrigear Vector

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 requiring careful orientation of the hardware (as Metrigear describes doing with FrankenRider for test purposes).

Once the system has a good idea how it is oriented, it can determine the radial acceleration. However, there are many acceleration components. For example, when the bike speeds up or slows down, there is a forward or reverse acceleration component aligned with the direction of bike motion. When the bike bottoms out at the end of a descent there's a vertical acceleration component. And when the bike hits one of the many bumps on our fine San Francisco Bay Area roads, there's a corresponding response in vertical acceleration. Additionally, road bumps will introduce longitudinal (in the direction of bike motion) accelerations.

In addition to the direct affect of road bumps, there are internal modes of the bike-rider system. Hitting a single bump may cause the bike to oscillate. These oscillations are generally at relatively high frequency (30-60 Hz, for example), though, and can be filtered from the data before sampling.

The key is that all of these acceleration components move both pedals together. From the standpoint of the spindles, the accelerations are in opposite directions, since the spindles are rotated 180 degrees relative to each other, once they are "aligned" relative to the direction of pedal rotation. So for example if I hit a bump with the pedals at 12 o'clock and 6 o'clock, one spindle experiences an acceleration towards the center of the crank, the other away from the center of the crank. So if I average the accelerations on the two spindles relative to the direction to the center of the crank, or relative to the direction of propulsive rotation, these other acceleration components cancel. This is an advantage of the Vector versus the Brim Brothers system, which has accelerometers and force sensors in the cleats. The spindles have a nice stable orientation relative to the propulsive direction. The cleats, on the other hand, are constantly shifting relative to the propulsive direction.

So if I average the left and right spindle signals, I should be able to isolate the centripetal acceleration. Then I can derive the rate of pedal rotation (knowing crank length). Then extracting the correct component of force, I know power.

The key question, though, is how well does this all actually work? Metrigear set for itself an accuracy target of 1.5%: ouch! Assuming some error in force extraction, it had better be well under this threshold in rotation rate extraction, at least for the time scale for which this accuracy target applies (it doesn't necessarily, for example, get 1.5% for each millisecond).

So to see if this 1.5% target was reasonable, I decided to write a little simulator in Perl. This also gave me a chance to see if my proposed method of pedal rotation rate extraction actually worked.
my $a = $ride_data[$ndata]->[2];
my $v = $ride_data[$ndata]->[1] +
$a * ($t - $ride_data[$ndata]->[0]);
my $phase = $phase0 + $s * $dphaseds;
my $omega = $v * $dphaseds;
my $rpm = $omega * 60 / $twopi;
my $domegadt = $a * $dphaseds;
my $cos = cos($phase);
my $sin = sin($phase);
$s += ($v + $vlast) / 2 * ($t - $tlast)
if ($ndata > 0);

# calculate acceleration components
# assume left and right crank are 180 deg out of phase
# phase is defined as zero when cranks are horizontal
my (%ax, %ay);
my $sign = 1;
for my $lr ( "L", "R" ) {
my $g_noisy = $gfactor * $g + $a_noise_v;
my $a_noisy = $a + $a_noise_h;
my $at = $sign *
($sin * $a_noisy -
$cos * $g_noisy) +
$domegadt * $L;
my $ar = $sign *
($cos * $a_noisy +
$sin * $g_noisy) +
$omega ** 2 * $L;
$ax{$lr} = $calign{$lr} * $ar +
$salign{$lr} * $at +
$ay{$lr} = -$salign{$lr} * $ar +
$calign{$lr} * $at +
$sign = -$sign;


Now, before everyone immediately runs for the exits, I'm not going to describe the nitty-gritty details of these simulations, such as detailed signals the accelerometers would see, or the details of how I do the orientation determination. Frankly, these details would just bore even those of you I haven't already bored, anyway. So I'll just focus on the results. Can it hit the rotation rate target? Given a simplistic assumption of "noise" based on the work of Champoux and Hastings I've already described, does can it see the "signal"? These questions could actually be answered fairly simply analytically. But it's more fun to do so numerically.

More next time.

Friday, January 22, 2010

drivetrain losses: same speed, different gear

Last two times I looked at the results on drivetrain efficiency from having the same gear ratio, riding at the same power. This went to the question of whether it was better to ride a chainring with more or less teeth, choosing a rear cog to match cadence at the same power and speed. The answer was for low power/high cadence, you're better off in a low chainring, while at high power/low cadence you're better off with a bigger ring.

A lot of issues go into gear choice, obviously. Ted Huang told me he put a 27-tooth cog on so he could ride the Cat's Hill Criterium, which has a climb of around 15% (video from 2009 here) so he wouldn't need to front-shift at the top. The model suggests he may have been better off doing so anyway, although it fails to penalize cross-chaining in any way (consistent with the experimental evidence, which isn't very sensitive to the matter).

Ted Huang @ Cat's Hill (2007)Hmmm, Ted, that doesn't look like the big ring to me...

Anyway, another option is I'm climbing in a given chainring and I want to choose which gear to be in. Am I better grinding @ 40 rpm in a 36/12 or spinning @ 87 rpm in a 36/26? Now obviously here there are issues of physiological efficiency. I can't produce as much power at 40 rpm as I can at 75 rpm, for example. But this just considers drivetrain efficiency.

Since I know I can't maintain such good power in these low and high gears, I'm going to reduce my climbing power to 200 watts.
K = 3.37 mm
Kd = 0.0024 J/rev
T0 = 95.6 N
P = 200 watts
36/11 with 12T pulley @ 36.67 rpm: loss = 8.315W (4.157%)
36/12 with 12T pulley @ 40.00 rpm: loss = 8.039W (4.019%)
36/13 with 12T pulley @ 43.33 rpm: loss = 7.824W (3.912%)
36/14 with 12T pulley @ 46.67 rpm: loss = 7.659W (3.829%)
36/16 with 12T pulley @ 53.33 rpm: loss = 7.437W (3.718%)
36/17 with 12T pulley @ 56.67 rpm: loss = 7.367W (3.684%)
36/19 with 12T pulley @ 63.33 rpm: loss = 7.290W (3.645%)
36/21 with 12T pulley @ 70.00 rpm: loss = 7.275W (3.638%)
36/23 with 12T pulley @ 76.67 rpm: loss = 7.307W (3.654%)
36/26 with 12T pulley @ 86.67 rpm: loss = 7.418W (3.709%)

So here's an interesting result: at the lowest cadence, chain speed is low, meaning tension is high (power is the product of tension and chain speed), and drivetrain losses are high. Spicer says high tension is a good thing, right? But Spicer also says bigger rear cogs are a good thing, and Spicer was measuring each of his gears with the same tension, or different tensions at the same gear and cadence. Here's a "real-world" example: tension and cadence both depend on what gear you choose. Spicer was basically changing the "grade" of his "hill" every time he shifted in the rear. This is the point which was made by Walton and Walton using Spicer's data directly.

So despite the fact as I shift down from that ridiculous 36/11 tension is decreasing, efficiency increases. The chain is bending less at the rear cog. This only goes so far, though. Eventually, the rear pulleys start to have more of an influence, and the loss bottoms out at 36/21. Going to the 23 or 26, efficiency starts decreasing again: at the lowest gears, chain speed is increasing, increasing losses, while total tension and chain bending are changing proportionately less.

So the model produces interesting results. Neither the biggest nor the smallest gear is the best choice. Fortunately this minimum in drivetrain loss is close to my preferred climbing cadence, which is around 75 - 80 rpm. So in this example, there's no trade-off.

Thursday, January 21, 2010

drivetrain losses: running some numbers

I ran my model for two conditions. The first was for 290 watts @ 80 rpm, the other for 50 watts @ 90 rpm.

So what do we expect? At 290 watts @ 80 rpm, chain tension is relatively high. It gets harder to bend chains at higher tension, so reducing the amount of chain tension pays off. Lower chain tension comes from a bigger chainring. The crankset is a simple lever: force on the pedals is multiplied by the ratio of the crank length to the effective chainring radius, and that radius is proportional to the number of chainring teeth. Additionally the bending where it matters most, at the cog, is less in bigger front-rear combos.

On the other hand, at 50 watts, chain tension is small. The built-in tension, both from the chain hanging and from the force of the chain components against each other, still dominates. Here more compact gears gain benefit from moving the chain more slowly. Links bend less often at slower chain speed, so this pays off. And the bending where it matters most, at the pulleys, doesn't change with gear. So increased chain bending in smaller front-rear combos is less of an issue.

Here's some numbers. Don't worry too much about that 19.5 tooth cog.... it's just a model, so doesn't let the pragmatic requirement for integral tooth counts get in its way....
290 watts @ 80 rpm
28/14 w/ 12T pulleys: Ploss = 11.530 (3.976%)
30/15 w/ 12T pulleys: Ploss = 11.125 (3.836%)
32/16 w/ 12T pulleys: Ploss = 10.788 (3.720%)
34/17 w/ 12T pulleys: Ploss = 10.508 (3.623%)
36/18 w/ 12T pulleys: Ploss = 10.275 (3.543%)
39/19.5 w/ 12T pulleys: Ploss = 9.997 (3.447%)
42/21 w/ 12T pulleys: Ploss = 9.790 (3.376%)
44/22 w/ 12T pulleys: Ploss = 9.684 (3.339%)
46/23 w/ 12T pulleys: Ploss = 9.600 (3.310%)
48/24 w/ 12T pulleys: Ploss = 9.535 (3.288%)
50/25 w/ 12T pulleys: Ploss = 9.486 (3.271%)
52/26 w/ 12T pulleys: Ploss = 9.452 (3.259%)
54/27 w/ 12T pulleys: Ploss = 9.432 (3.252%)
56/28 w/ 12T pulleys: Ploss = 9.423 (3.249%)

50 watts @ 90 rpm
28/14 w/ 12T pulleys: Ploss = 5.128 (10.256%)
30/15 w/ 12T pulleys: Ploss = 5.195 (10.390%)
32/16 w/ 12T pulleys: Ploss = 5.274 (10.547%)
34/17 w/ 12T pulleys: Ploss = 5.362 (10.724%)
36/18 w/ 12T pulleys: Ploss = 5.458 (10.917%)
39/19.5 w/ 12T pulleys: Ploss = 5.616 (11.232%)
42/21 w/ 12T pulleys: Ploss = 5.785 (11.570%)
44/22 w/ 12T pulleys: Ploss = 5.904 (11.807%)
46/23 w/ 12T pulleys: Ploss = 6.026 (12.052%)
48/24 w/ 12T pulleys: Ploss = 6.151 (12.303%)
50/25 w/ 12T pulleys: Ploss = 6.280 (12.559%)
52/26 w/ 12T pulleys: Ploss = 6.411 (12.821%)
54/27 w/ 12T pulleys: Ploss = 6.544 (13.087%)
56/28 w/ 12T pulleys: Ploss = 6.679 (13.358%)

Tuesday, January 19, 2010

Drivetrain losses: friction-based tension dependence

After reviewing data from Spicer, from Kyle and Berto, from d'Herripon and Verhoeven, all I get is a headache. So to heck with experimental data. It's always a mistake to let experimental data get in the way of a good theory. So I'm going to forge ahead, and pull the numbers I like from the experiments, and resort to a simple theoretical model for the effect of chain tension on drivetrain loss.

I'll start by trusting the pulley friction measurement data I used before, based on experimental data, sure, but experiments on a simpler system (a pulley on bearings) than on a more complex system (a full drivetrain):

Kd = 94 mJ/rev for Shimano Dura-Ace
Kd = 2.4 mJ/rev for CeramicSpeed pulleys

Data measured by Mark Kelly:

Kd = 37 mJ/rev (standard bearings)
Kd = 6.4 mJ/rev (high quality steel bearings)

Then based on a pin diameter of 5/32 inches = 3.97 mm, and using a coefficient of friction for steel-on-steel with a smooth oxide coating = 0.27, with a tooth pitch L = 0.5 inches = 1.27 mm, I calculate:

K / L = π (5/32 inches) (0.27) / (1/2 inch) = 0.265.

That leaves T0. From Spicer's data, I got

2 (K / L) T0 = 50.65 N.

I can guess at the slack-side chain tension from measuring the oscillation frequency, but that wouldn't include the plate friction, so I'll stick with this number.

This gives me:

T0 = 95.6 N.

If I campare these results to Spicer's reported measurements, it's not too terrible, if you allow for the possibility Spicer had an offset in his efficiency measurements:

So what does this all give me?

Suppose I'm riding at 70 rpm up a hill at 290 watts. I have a choice of using a 36/18 or a 50/25. Which gear has the lower drivetrain loss? Following measurement-based Spicer's recommendation I'll assume cross-chaining has little effect. I also neglect differences in derailleur tension between the two gears. Additionally, I'm not using no freakin' Dura-Ace pulleys: instead I have high-quality SRAM pulleys with ceramic bearings (harumph!) and 12 teeth.

Well, here's the model, slightly rewritten:
Ploss = (K / L) P (1 / Nf + 1 / Nr) + C T0 K (1 + Nf/Nr + 2 Nf/Nd) + Kd C Nf / Nd


K/L = 0.265,
T0 K = 0.322 J.
Kd = 2.4 mJ (negligible)

Losses are 3.54% of total power.

So then I switch to the 50/25. I then get losses are 3.27% of total power.

So in this case, the smaller gear costs me 0.27% of total power. Assuming 12% of my power goes into wind resistance, the time saved in the climb from 0.27% less power = 0.27% / (1 + 2f) where f = 0.12, which equals 0.22% or 2.2 seconds out of 17 minutes. So that's worth thinking about.

Now what if I get my Red derailleur upgraded to a 15 tooth lower pulley? I'm back in the 36/18. Well, now losses are 3.45% of total power. I save 0.09% of total power. This increases my speed 0.073% = 0.7 seconds out of 17 minutes.

So at least with this model, that 15 tooth lower pulley doesn't do too much for me. Although every second counts... And just knowing I've got a blinged-out rear derailleur is probably good for a solid 10 seconds!

What about Dura-Ace pulleys? Back to the original derailleur, 36/18, I get 3.57% power loss. This costs me 0.03% of my power, and I get to the top 0.25 seconds slower. The difference between Mark's "high quality steel bearings" and the ceramic bearings is too small to even discuss.

So the end result is the compact gearing does seem to hurt a bit under this sort of climbing effort. And the pulleys, which sit on the low-tension side of the chain run, don't make much difference as long as they're clean.

Monday, January 18, 2010

Metrigear Vector versus Brim Brothers

Brim Brothers just published an update on their status, the first one since Eurobike last year. Brim Brothers system looks very promising: put the force sensors in the cleat of the cycling shoe. That sounds a lot like Metrigear Vector, right?

Well, not quite. I've made a large number of posts here about the Vector, as it's fun trying to figure out how it works. But there's a very important difference between the two.

This is hinted at in the Brim Brothers blog post:

The most important (and most fun) part of the algorithm is taking the accelerometer data and using it to work out cadence, crank angle and pedal angle at each sample point. This is the same kind of technology that allows a Wii control or an iPhone to detect movements, but we need to use it to measure complex rotational movements very accurately. Having the accelerometer attached to the cleat/shoe (which rocks back and forth by an unpredictable amount all the time) makes this a lot more complex than, say, having the accelerometer fixed inside the pedal spindle. But if we did that then you wouldn’t be able to just step off one bike and onto another and have the power meter come with you…

To measure power, you need the component of force in the propulsive direction. This requires you know the orientation of the cleat relative to the direction of pedal motion. With a shoe, this direction is constantly changing. It's changing not just in inertial space due to "ankling", but relative to the propulsive direction as the crank rotates. Terribly complicated.

On the other hand, as I've pointed out many times, the pedal spindle is always oriented the same relative to the propulsive direction. Once you figure out which that direction is, and I described already how one might do that, you're good to go until the pedal is adjusted. And if the pedal is adjusted, for example tightened or moved to a different bike, it would take only a few crank rotations for the system to figure out something's up and reorient itself. Recall in the tangential direction, the average acceleration over time goes to zero, while in the radial direction, the orbital acceleration is always non-negative and therefore averages to greater than zero. So if you can determine in which direction accelerations average to zero, and which orthogonal direction they average to greater than zero, you're oriented. I described all of this before in a long series of posts: nothing new.

So with Vector it's easier to determine which direction is the propulsive direction, and which is the radial direction. Only the propulsive direction contributes to power.

But power is force times speed, or equivalently torque times rotation rate. I get torque from force by knowing the crank length. Brim Brothers claims to allow you to jump from one bike to another, so it needs to figure out crank length. With Vector, you tell it the crank length, which makes its computational life all that much easier. In any case, you still then need to know rotation rate. The obvious way to rotation rate is via the orbital acceleration, ω²L, where ω is the angular velocity and L is the crank length. That acceleration can be measured every sample, providing a high-resolution reading on rotation rate.

some acceleration vectors at pedals
acceleration vectors at pedals: travel is from bike moving forward, road is from road vibration (for example), cadence is from pedals rotating.

The issue is that it's not the only acceleration in town. First there's the accelerations of the bike as it moves, turns, and/or responds to road grade changes. But additionally there's "vibration noise". I also did a number of posts on vibration. Vibration can come directly from the road, or the road can excite vibrational modes in the bike-body system. In either case, the pedals vibrate. They need to differentiate that acceleration from the orbital acceleration which provides the rotation rate, a critical element for power.

Sure, you can measure rotation rate separately, for example with a cadence sensor magnet. But these typically tell the average rotation rate over an entire pedal stroke. That's not good enough: you'd then need to assume something about the rotation rate within the pedal stroke. That won't be perfectly uniform. And for example when climbing and other "low-inertia" situations like riding through sand or into a headwind, the variation in rotation rate may well be correlated with applied power. So the assumption of uniform pedal rotation through a pedal stroke may yield a systematic power error.

But the nice thing about Vector is that we know the orientations of the two spindles. Road vibrations, accelerations, even most frame vibrational modes will all move the two pedal spindles in the same direction. On the other hand, the rotational accelerations are always in the opposite directions, assuming cranks 180 degrees apart. So subtract one from the other and magically road vibration, linear acceleration associated with the bike traveling forward, all that junk goes away. Brim Brothers is going to have a much tougher time with this. It gets even tougher the more types of float the pedal allows.

So the Vector has advantages in both determining the direction of forces and in determining the rate of pedal rotation. Errors in either quickly eat into the error budget for power determination. And when you're trying to hit a 2% error margin under all conditions, paved or unpaved, sprinting or cruising, climbing or descending, you need any advantage you can get.

So I wish the Brim Brothers the best. But they've got a tough challenge ahead of them, even tougher than Metrigear's.

Sunday, January 17, 2010

Bas d'Herripon and Jan Verhoeven's drivetrain loss measurements

In Human Power 48 (1999), Dave Wilson does a nice review of posts to the now defunct Bicycling Science mailing list (previously called "Hardcore Bicycle Science", presumably named to discourage the usual idle chatter which had diluted the USENET group). The most relevant data to my purpose was credited to Jan Verhoeven, although details were not available.

Searching the list archives, I found similar data from Bas d'Herripon.

Both tests were on a Shimano Deore LX drivetrain. Here's the results from d'Herripon:


For d'Herripon, crank cadence was at 70 rpm. I assume the same for Verhoeven. Both data sets were for drive power of 200 watts.

My model has three unknowns: K, T0, and Kd. But as before, I can set Kd based on specific measurements, using a value of 94 mJ/revolution measured on Dura-Ace pulleys. Then there's two unknowns for me to tweak to match the data.

Well, I did that using an OpenOffice Calc spreadsheet. But it became quickly clear to me I was in trouble. Look at the range of those efficiencies: from 91.6% to 98.2%. This is a range of drivetrain loss coefficients from 1.8% to 8.4%, a range of 467%! Nothing in my model allows for such a strong dependence on gear selection, given the range of chainrings and cogs used in this test.

In desparation, I plotted drivetrain losses versus gear ratio, and was surprised to see the following:

Drivetrain losses appear to be primarily a function of the gear ratio, rather than of some other function of the front and rear chainring, such as my suggested 1/Nf + 1/Nr for tension-dominated losses.

Note in the plot I fit a function to the data. I can't help it -- I like fitting functions to data. But there's no physics behind that function: it's simply what came to my head when I was looking at the data.

Since cadence is fixed, the rear wheel is spinning at a rotation rate equal to that cadence (70 rpm) times the gear ratio, so from this it appears drivetrain losses were a function of the rate the rear wheel was spinning. That's the sort of thing I'd expect from bearing or tire losses or wind resistance from the spokes, not chain losses.

Now, d'Herripon claims they corrected for spoke wind resistance. But I'm going to guess they made an error in doing so. Just a guess.

So first Spicer, then Kyle and Berto, and now Verhoeven and d'Herripon: I can't figure any of them out.

Saturday, January 16, 2010

Coastal Trail Runs: Huddart Park 17km

Today I ran the Coastal Trail Runs Woodside Trail Run, starting in Huddart Park. I did the "11 mile" course, the same course as the Pacific Coast Trail Runs "17 km" course in the same location. No coincidence: Coastal Trail Runs is the "sister" company to Pacific Coast Trail Runs, more low-key, with less focus on distance.

I know what you're thinking: "but 11 miles is 703 meters longer than 17 km!" Indeed the "fine print" distance is 10.6 miles, not 11. That's 17.06 km.

In this case, "less focus on distance" meant the long run was "only" a marathon (42.194 km) instead of 50 km.... And you really can't get much more low-key than PCTR. But maybe I'm biased by the standards of bike racing.

Anyway, the run started with a short descent, but then from there climbed steadily until it flattened out before the turnaround at 6.0 miles. I reached that in 56:53, fifth overall. By 57:07 I'd drank two cups of water, and was on my way back. I finished at 1:32:28, eighth overall, having been passed first by a guy early in the descent, then within the final mile by the lead woman and then another guy. The gap between my eighth and sixth place was 3 seconds.

So did stopping for those drinks cost me the time?

Suppose I had carried the water instead. I weigh around 124 lb. Add in around 4 lb worth of clothing. Suppose I drank 16 oz of fluid, which weighs about 1 lb. And suppose I could have carried that in a bottle instead of stopping at the summit.

Then I would have had to carry an extra 1 lb up that hill. Running on both the flat and uphill, power is roughly proportional to weight (wind resistance isn't very significant). So an extra lb of water carried up the hill would have cost me 1/128th of my climbing time. That's 26.5 seconds.

So it seems, neglecting possible issues of hydration, that having spent 14 seconds drinking those two cups of water was a better choice than carrying a bottle up the hill. Add in the weight of the bottle and maybe a belt to hold it and it's no contest.

My last run I carried the bottle. But my post-run analysis had me questioning that choice. So with today's conditions being cooler from those of that run last February, I made the choice to stick with only the gel flask.

But what about hydration? Maybe I would have been better off continuously hydrating than drinking all at the end of the climb. (I did carry a small gel flask with diluted Hammer Gel, but that's not much). Or maybe I would have been better off skipping the water completely? Of course these questions aren't easy to answer. I personally think I would have lost more than 14 seconds the rest of the way had I not drunk that water: that's only 0.7 seconds of my total return time. Running 90 minutes without water is a lot, even in today's cool conditions, given my state of fitness. My ITB has been giving me problems, and it's limited my training.

But no matter my placing, it was a fun run, and both Pacific Coast Trail Runs and Coastal Trail Runs put on fantastic events. Trail running is a ton of fun, a nice break from cycling, and obviously a really strong workout. I want to do a few more this year before my focus gets too deep into cycling.

Thursday, January 14, 2010

Kyle and Berto's drivetrain efficiency data

Last time I discussed Spicer's measurements published in Human Power 50 (2000). The key issue there is that drivetrain efficiency consisted of a component associated with infinite chain tension, plus an additional contribution proportional to the recprocal of chain tension. Each of these terms, the slope and intercept versus 1/tension, depends on some combination of the reciprocals of chainring teeth, cog teeth, and pulley teeth. The problem is for infinite tension, or worst with infinite tension and infinite-sized chainrings and cogs, the extrapolated efficiency exceeded 100%. For example my regressions had a maximum efficiency of 106.6%. Bonanza! The energy crisis is solved!

But onward to other measurements. In Human Power 52, summer 2001, Chester Kyle and Frank Berto published some really nice experiments measuring drivetrain efficiency, of primary interest being those of an Ultegra 3×9 system. They did their measurements with the crank driving the hub, and the hub driving an Al Monarch wheel via a pair of 36-tooth sprockets, one on the non-drive side of the bicycle hub.

Kyle and Berto apparatus, from Human Power 52

I'm not exactly sure how it worked, but the ergonometer wheel apparently was resisted by a hanging weight which could be adjusted. They end up with the following equation for work done on the ergonometer wheel in steady-state, where the wheel itself is not accelerating:

P = k ω (T₁ ‒ T₂)

where T₂ is the tension on the slack side of a cord, T₁ is the tension on the side lifting the weight, k is a proportionality constant, and ω is the angular speed at which the wheel is rotating. This is equivalent to the case where there's a pulley, with weight T₁ on one side, and weight T₂ on the other, where the former is raised while the latter is lowered.

To test the efficiency of the connection between the bicycle hub and the Monarch wheel, they drove the Monarch wheel directly at 75 rpm. This measurement included bottom bracket bearing losses as well, which are considered much smaller than losses in the chain and rear derailleur. In any case, they measured that this second drivetrain at 75 rpm had losses which went from 1.87 W for the lowest measured weight to 6.36 W for the heaviest weight, all when the ergo wheel was spinning at 75 rpm. I reproduce their results here, along with an equation I fit to their data:

As an aside, since all measurements were done at a crank cadence of 75 rpm, the bottom bracket bearing losses should be similar for all cases, so it's simple enough to add the bottom bracket bearing losses back in based on additional measurements.

from Berto and Kyle

In their Fig 14, they use these measurements to correct data measured including the Ultegra drivetrain. The crank is turning at 75 rpm with a 44-tooth chainring and a 16 tooth cog. This means the ergonometer is spinning at 44 / 16 × 75 rpm. Losses in the ergonometer drivetrain should therefore be at least 44 / 16 × 1.87 watts = 5.1 watts. At the lowest drivetrain power, 50 watts, you should therefore add at least 5.1 watts to the "transmitted" power in calculating the efficiency (this measurement likely used their lowest mass, so it should be close to this). Measured efficiency was 90.6% at 54 watts, which means transmitted power was 48.9 watts. I add 5.1 watts and I get 54.0 watts. Thus the "corrected efficiency" is 100%.

But they report the corrected efficiency is only 93.6%. So something's wrong. That represents a change in tramitted power of (93.6% - 90.6%) × 54 watts = 1.62 watts. This is lower even than the lower bound of the 75 rpm (on the ergometer wheel) measurements. It would imply an ergometer wheel rotation rate of 1.62 W / 1.87 W × 75 rpm = 65 rpm.

I'm stumpified, I admit.

Going back to the ergonometer measurements from their Fig. 13: those really are curious. They're curious because the chain tension should be proportional to the mass-load on the Monarch wheel (with an intercept for zero mass). Chain speed and chain bending are both constant since the test was done at a fixed 36/36 gear with a 75 rpm cadence. So by my simple friction model, power dissipated should be a straight line, with an intercept. Yet it's not a straight line, not even close. Is this a clue to the problem with the intercepts on the Spicer data exceeding 100%? If yes, I don't see it. To "save" the Spicer data efficiency needs to stop improving as tension is increased (1/T is decreased) relative to the highest values of T (lowest values of 1/T) used there. That requires power loss start increasing faster at higher tensions, not flatten out as it does in Berto and Kyle's data. Berto and Kyle use a fixed gear, while Spicer was going through a derailleur, but that shouldn't matter in the high-tension limit where the high-tension part of the chain sees only the cog and the chainring.

So I'm still stumpified both by Spicer and by Kyle & Berto.

Wednesday, January 13, 2010

Drivetrain losses: Spicer's data

Recall Spicer did some nice drivetrain efficiency measurements, which he published in Human Power 50, 2000. His argument is that chain tension is an important parameter, that higher tension tends to yield higher efficiency. Here's his result again:

Spicer's efficiency measurements as a function of reciprocal chain tension for each of three rear cogs

My model described dissipated power rather than drivetrain efficiency. To get efficiency (ν), I take the power dissipation as a function of T and divide it by power P, where T / P = chain speed = R L = C Nf L.

ν ≡ 1 ‒ Pdt / P = 1 ‒ (K / L) [1/Nf + 1/Nr + 2 (T0 / T) (1/Nf + 1/Nr + 2/Nd)] ‒ Kd / (Nd T L).

Spicer says efficiency depends on T but is independent of chain speed. However, since Spicer uses a conatant Nf, for him constant chain speed simply means constant C. the above equation is indeed independent of C. Furthermore, Spicer says ν is well fit by a formula ν = ν ‒ α / T for some constant ν and slope α. This equation also has this form. So it is fully consistent with Spicer.

Here's where things don't work so well. The intercept predicted by Spicer for infinite tension is above 100% efficiency. Bummer. This implies you could use a bike chain to construct a perpepetual motion machine. Allen comments on Spicer's data in the next issue of the journal. He asserts Spicer's approach was flawed in that he is determining drivetrain losses by comparing torques at the crank and at the hub. Small errors in one or both could easily translate into large errors in the difference. Better would be to use a device which directly measured the difference in torque. So the result of this is you can't rely on Spicer's extrapolated infinite-tension efficiency. Instead of using Spicer's values directly, it's tempting to assume he has a fixed error in his reported efficiencies.

So from my equations I come up with the "true" infinite-tension efficiency:

ν = 1 ‒ (K / L) [1/Nf + 1/Nr].

To compare to Spicer's values, I then apply a fixed error term:

ν∞,Spicer = 1 + Δν ‒ (K / L) [1/Nf + 1/Nr].

There's two unknowns parameters here ( Δν and K ) for which I have 3 data points (intercepts of 11, 15, and 21 tooth cogs).

That was the infinite-tension limit Additionally, there's the slope term, which describss how efficiency drops with 1/T. For that I have:

α = 2 (K/L) T0 (1/Nf + 1/Nr + 2/Nd) + Kd / Nd L.

This shows a relatively weaker dependence on the cog choice, since 2 Nf/Nd is going to be relatively larger than the other two terms, since Nd is typically 11 - 12 teeth (although some riders are using 13 teeth or even 15 teeth for increased efficiency).

Red derailleur modified by Dark Albert with 15-tooth pulley

Least-square fits to the Spicer data are as follows:


I fit these to the model. From the intercepts, which I plot versus 1/Nf + 1/Nr. The slope gives me K / L, the intercept Δν.

The results:

Δν = 0.066,
K / L = 0.447,

which yields K = 5.68 mm.

Now before moving further, this is already raising a big fat red flag. Δν = 6.6? How could that be? I already showed data published in Wilson that drivetrain efficiencies are typically in the 97-98% range. How could Spicer's data be off by as much as 6.6%? I'm starting to question my assumption of a fixed efficiency offset.

But what about K/L? Does that make any sense? This requires considering what the model means. The total bending angle of a link when it bends = 2π / N, where N is the number of teeth (or, if you prefer, 360° / N). The model says dissipation from this bending = K Ttot / N, where Ttot is the total chain tension (T0 or T + T0 in my model). So K is the equivalent distance associated with a full rotation of a chain link, assuming drag = Ttot. The radius of a chain pin is approximately 2 mm, so the circumference is approximately 12.6 mm. Thus the drag force is less than the effective tension: the proportionality factor is represents a coefficient of friction of 45%. A reference for the coefficient of drag for two steel surfaces coated by thin oxide films is 27%, but with clean surfaces it is 78%. This number falls between the two. But what about oil, you ask? Spicer found lubrication was a minor factor in chain drag. At the contact points, the lubrication is largely repelled from the pressure. So the purpose of the lubrication is more to keep the chain from rusting than it is to reduce friction. Anyway, this number certainly doesn't seem out of line.

Okay, onward: despite the issue with Δν, I forge ahead to the slope parameter. Here's a plot of α versus 1/Nf + 1/Nr + 2/Nd.

Unfortunately the data don't fall onto a nice straight line. So I needed help. The slope here depends on T0, while the intercept describes the rolling friction of the pulleys, Kd. So I'll cheat a bit and use data reported in the WeightWeenies forum:

Further tests by SKF, and confirmed by the Danish cycle magazine Cykel Magasinet (Sep 2005), describe dramatic reductions in friction compared to conventional cycle bearings. For example:

With a pair of race wheels (total of six bearings), friction with ceramic bearings is reduced 22 fold While Dura Ace pulleys consume 0.78W @ 500rpm, ceramic pulleys use less than 0.06W A Record BB @ 100rpm and 400W consumes 0.6W, the same BB with ceramic bearings consumes 0.02W

Conveniently, Spicer used a Dura-Ace derailleur. So given the test rotation rate of rpm, converting to 8.33 rotations per second, I get:

Kd = 94 mJ/rev

That was for the Dura-Ace pulleys. For the Ceramic, the number would be 2.4 mJ/rev.

Then I did a constrained linear fit on the data, yielding:

2 (K / L) T0 = 50.65 N,

or since we already solved for K / L, so it's easy enough to solve:

T0 = 56.65 N.

So how's this compare with typical values of T? Suppose I weigh 60 kg with clothing. That's around 600 N. If I stand on the pedal when the crank is at 3 o'clock, that's a chain tension of 1000 N, assuming 170 mm cranks with a 50 tooth front ring, with the half-inch tooth spacing. So it says the chain bending resistance at the top of the crank is around 18 times bigger than the bending resistance at the bottom of the crank.

But there remains that pesky issue of Δν. With that so large, the Spicer model is assured to over-predict drivetrain losses. I'm not sure what to do about that. Or does something magically happen at low values of 1/T that cause the slope (as plotted by Spicer) to suddenly flatten?

Tuesday, January 12, 2010

drivetrain losses: simple model

My model for drivetrain losses, which I'm sure is unoriginal as it's so obvious, is to model the power loss as each chain link completes a circuit:

Bicycle drivetrain from Wikipedia.

  1. Start at the bottom of the crank. The chain link is at a fixed tension determined by the derailleur spring. It moves backward, not bending, until it reaches the bottom derailleur pulley. This motion dissipates negligible energy. Note there is some bending here due to a nonideal chain line. But I'll believe Spicer's assertion, which I found surprising, that chainline is relatively unimportant.
  2. The chain link bends as it contacts the bottom deraileur pulley. It does so under low tension. The amount of bending is independent of the gear selection. This dissipates some energy.
  3. The chain link moves along with the pulley. This dissipates negligible energy.
  4. The chain link unbends after losing contact with the bottom pulley. This dissipates energy. Still the tension is low, set by the derailleur springs.
  5. The chain link moves to the upper pulley: no dissipation.
  6. Still under low tension, it bends at the upper pulley. Energy is dissipated.
  7. The chain link moves along with the upper pulley. No energy is dissipated.
  8. The chain unbends as it exits the upper pulley. Energy is dissipated. Tension is still low, determined by the derailleur springs.
  9. The chain now moves to the rear cog. No energy is dissipated.
  10. The chain bends as it contacts the rear cog. Tension is low. The chain dissipates energy as it bends. The amount of this bending is inversely proportional to the number of rear cog teeth.
  11. The chain link moves along with the rear cog. Tension increases as it moves. The chain link is doing work against the rear cog. Work done requires is proportional to a tension difference. It may well be, especially for a slightly stretched chain and a relatively less worn cog, that the majority of this tension increase occurs near the end of the period where the link contacts the cog.
  12. The chain unbends as it exits the cog. The amount of this bending is inversely proportional to the number of rear cog teeth. Here the chain link is under maximum tension.
  13. The chain link moves to the front chainring under high tension. No dissipation.
  14. The chain bends as it contacts the front chainring. The amount of this bending is inversely proportional to the number of chainring teeth, which is typically larger than the number of cog teeth.
  15. The chain link moves around with the chainring. Tension decreases as the chain moves, with the chainring doing work on the chain.
  16. The chain exits the chainring, unbending and therefore dissipating energy. The bending is inversely proportional to the chainring size. Tension is fixed, determined by the rear derailleur spring.
That's it for chain dissipation. I'll also consider dissipating in the pulleys, which spin under fixed load determined by the derailleur spring. This power is proportional to the rate at which the pulley spins, which equals the ratio of the rate chain links move to the number of teeth on each pulley.

I'll assume when a chain bends, its frictional losses are proportional to the tension plus a constant. Even a chain under no tension experiences some friction, due to the built-in stresses within the chain structure. Further, the loss is proportional to the amount of bending, which is inversely proportional to the number of teeth on the associated cog, chainring, or pulley. Note it doesn't matter for how long the chain is in contact with the cog, ring, or pulley. All that matters is the amount the chain bends to make contact, and subsequently unbends to leave contact.

So the model I'll assume for a bending (or unbending, which is equivalent) event is:

ΔEbend = K (T + T0) / N,

where T is the extra tension on the chain (0 when the chain is moving from the chainring ot the cog, positive when moving from the cog to the chainring), T0 is the combination of the tension of the chain on the return path and the built-in stress leading to friction of an unloaded chain, N is the number of teeth in the cog or chainring or pulley (assuming these are round), and K is a proportionality constant.

As an aside, if the chainring is not round (such as a Rotor ring, then what matters is how much the average link bends, which equals the average curvature of the ring. That will be slightly more than the curvature of a round ring with the same number of teeth. This suggests an exccentric ring (like a Rotor) will have a bit more resistance than a round ring. Additionally, the chain tension and speed become a function fo time, which complicates things further. But that's an aside. I'll keep the analysis to round rings.

Total energy dissipated in one circuit is the sum of bending and unbending events. There's four such events at the pulleys, all at low tension. Then there's one each for the cog and chainring at low tension, and one each for the cog and chainring at high tension. Summing these:

ΔErev = K [T (1/Nf + 1/Nr) + 2 T0 (1/Nf + 1/Nr + 2/Nd)],

where ΔErev is the energy dissipated by a link in a revolution, Nf is the number of chainring teeth, Nr is the number of cog teeth, and Nd is the number of teeth in each pulley. Note the tensioned part of the chain is assumed to have a total tension T + T0, so it appears in both terms.

To calculate the power dissipated, I need to multiply these energies, which are per link, by the rate at which links complete revolutions. This rate is simply number of teeth in the chainring multipled by the rate at which the chainring is turned:

R = Nf × C,

where R is the rate at which chain links complete the circuit and C is the cadence.

So in total:

Pc = C K [T (1 + Nf/Nr) + 2 T0 (1 + Nf/Nr + 2 Nf/Nd)],

where Pc is the power dissipated by chain bending.

Further simplification is possible by solving for T:

T = P / chain speed

   = P / ( Nf × C × L ),

where L is the chain half-pitch.


Pc = K [(P / L) (1 / Nf + 1 / Nr) + 2 C T0 (1 + Nf/Nr + 2 Nf/Nd)],

where L is the chain half-pitch and C is the cadence.

I then need to add in power dissipated by the derailleur pulleys:

Pd = Kd R / Nd
    = Kd C Nf / Nd.

These can be combined to yield the total power dissipated in the drivetrain:

Pdt =
Pc + Pd =
(K / L) (1 / Nf + 1 / Nr) P +
2 K C T0 (1 + Nf/Nr + 2 Nf/Nd) +
Kd C Nf / Nd

So this leaves us with three terms:
  1. A power-proportional term, which depends on the front and rear chainring teeth. This term is larger for a compact crank, where both Nf and Nr are proportionately smaller.
  2. A power-indendent term, which depends only on ratios of teeth. This term is smaller for a compact crank, where Nf/Nr may be the same but Nf/Nd is smaller.
  3. The pulley friction, which is less for the compact crank, since the pulley spins more slowly.
I've seen it argued the compact should be more efficient, as the chain is under more tension. But chain tension is just one part of the story: chain speed and the amount of bending are other components. At the pulleys, which are assumed to have the same number of teeth, the compact drivetrain results in slower chain speed and therefore the pulleys spin slower and chain links are bending less often there, both reducing the dissipation fo the compact relative to the conventional drivetrain. But then there's the contribution of T0 at the chainrings and cogs. Here the chain speed is an advantage to the compact, but that advantage is cancelled by the proportionally increased amount of link bending. So for the T0 component at the cogs and chainrings, it's a wash. Finally there's the T-proportional components at the cogs and chainrings. Here there's the additional factor that the tension is higher in the compact set-up. So in this component the compact set-up dissipates more. So whether the compact is more or less efficient depends on the details. There's no simple answer, at least with this model.

I'll compare with Spicer data next time.

Monday, January 11, 2010

drivetrain losses: introduction

Drivetrain losses are an important factor in cycling. A sort of canonical number is they are responsible for 3% of total power during high-intensity riding. Wilson's Bicycling Science 3rd edition (2004, MIT Press) page 343 shows data indicating at 200 watts, losses vary from 2.4% to 3.1% among three gear choices with a clean chain:

6-speed derailleur
Power (W)
24T cog
19T cog
13T cog

A comparison of a "no rust, lubricated" chain to a "rusty, dry" chain yields a difference of 4-5% (absolute) at 200 watts, which is huge.

Anyway, from these data it's clear a fixed "drivetrain efficiency" is a poor model. Even if you allow the efficiency to vary from one gear to another, there's a clear power dependence. And allowing an "efficiency" to vary with power is obviously obfuscated: you're applying a model that drivetrain losses are proportional to total power but then allowing that proportionality constant to vary with power. Better to use a proper model.

Spicer, in Human Power (2000) did some very nice measurements using motors, which allowed him to set the cadence, gear, and power independently. Thus he was able to measure drivetrain efficiency at the same chain speed and tension for different rear cogs.

Spicer's efficiency measurements as a function of reciprocal chain tension for each of three rear cogs

These were his conclusions:

It was found that larger sprockets provide more efficient transfer of power while smaller sprockets proved to be less efficient. Simple, frictional loss models were developed that gave sprocket-size loss variations that agreed with those variations measured experimentally. Typically, a 2–5% loss difference was measured between the 52–11 and the 52–21 sprocket combinations depending on the drive operating conditions.

Experimental results indicated that the efficiency of the chain drive varied as a function of chain tension. It was found that the efficiency varied linearly with the reciprocal of the average chain tension with the highest efficiencies occurring at high chain tensions and lowest at low chain tensions.

It was found that chain-line offset and chain lubrication have a negligible effect on efficiency under laboratory conditions.

A follow-up article by Walton and Walton (a high school senior and her college professor father) reanalyzed Spicer's data for the case where power and speed were fixed, but cadence was allowed to vary. This more accurately represents the case where a rider is trying to choose in which gear to ride on a given section of roadway.

But there's another case to consider, which is whether it's more efficient to ride with a 110 mm BCD "compact" crank (for example, a 36/24) or the equivalent gear with a 130 mm BCD "conventional" (for example, a 39/26). Is one more efficient than the other? This question has been discussed in online forums, but I can't say I've seen a clear conclusion on the matter.

Personally, I find Spicer's claim efficiency is higher at higher chain tension to be puzzling. All other things equal, how can increasing the chain tension reduce the power loss in the chain? It makes no sense. We were all taught in high school physics that frictional force between two surfaces is proportional to the normal force between those surfaces. If the chain tension increases, the links and pins of the chain should be pressed harder together, and drivetrain losses should increase, not decrease as Spicer suggests. Yet the measurements are real.

The issue is that chain tension is not an independent variable. Power delivered by the chain equals the product of the chain tension times the chain speed: that's simple physics. So if chain speed is fixed, and tension is increased, then power is increased. Instead of pursuing this further, and getting confused, I'll propose my own model for drivetrain losses, then compare the results with Spicer's data.

Frank Berto and Chester Kyle's data.

Then in Human Power 52 (2001), Frank Berto and Chester Kyle did some nice measurements comparing a geared drivetrain (a Shimano Ultegra mountain bike group (?), 22,32,44 by 12,14,16,18,20,23,26,30,34) with various internal geared hubs. The advantage over the Spicer data was that more gear combinations were tested, although each gear combination was tested less extensively.

I'll propose a simple model next time.

Sunday, January 10, 2010

closing a gap with head down

I did a quick calculation of the effect of the head position on closing a gap. Suppose I'm chasing a group riding @ 40 kph and I can ride with the head up at 45 kph. I can't sustain that pace for too long, so the clock's ticking. I have to close that gap as quickly as possible.

I'll do an first-order analysis, which means I assume a starting condition then apply a first-order correction for the small change. In this case the head position change is a small fraction of total wind drag, so the linear analysis should do fairly well. It wouldn't do well, for example, were I to swap my bike for a recumbent... an interesting thought.

Furthermore, I neglect drivetrain losses. Calculated powers are "PowerTap" equivalent. I assume drivetrain losses are proportional to transmitted power.

Baseline condition:

CdA = 0.32 m²
M = 65 kg
ρ = 1.1 kg/m³ (air density)
g = 9.81 m/s²
Crr = 0.5% (rolling resistance coefficient)

Then I get 40 watts dissipated in rolling resistance, 343 watts dissipated to wind resistance. So 343/383 watts goes into wind resistance: 90%.

Fabian Cancellara closing a gap to San Remo in 2008 (Graham Watson)

I previously calculated the effect of power on speed: a fractional improvement of power results in a fractional improvement of speed in a ratio of (1 + 2f):1, where f is the fraction of power going into wind resistance. In this case, that ratio is 2.8:1. In other words, it takes around a 0.28% increase in power to increase speed by 0.1%.

In this case, a fractional reduction in power required is equivalent to the same fractional increase in power produced (since I'm doing linear analysis). 6.7 watts out of 383 watts is 1.75%. So the effect on speed is 0.62%. At 45 kph that's 0.28 kph.

So I said I was riding 45 kph and chasing a group riding at 40 kph. That's a difference of 5 kph. I put my head down, and I'm now closing @ 5.28 kph. That's a 5.6% reduction in the amount of time it takes to close the gap.

So for example instead of chasing for 5 minutes, I'd have to chase for 4:43. 17 seconds in hell saved.

Huge big deal? I'm not sure, but it's free. This is as big a fractional advantage as is claimed for aerodynamic road frames like the Cervelo S, Felt AR, or Ridley Noah. People pay big bucks for these. Putting your head down doesn't cost anything.

Saturday, January 9, 2010

head position while on the drops

I got on the trainer and tried the following two positons, both representing a "chase to close a gap" mode (I couldn't necessarily hold these positions for a half hour, for example).

In the top photo, I've got my head up to focus on where I'm going. I used to ride this way all the time. In the bottom, I'm shrugging my shoulders and relaxing my head, looking up to look forward. I can see fine, it's just I'm looking up instead of straight. In the top photo it actually seems my arms are more bent (sloppy of me). Yet despite this advantage, you can clearly see my head is higher above my back: the difference to the bottom position is a full 5.6 cm.

With a head width of 17 cm (which I measured), Cd = 0.8, air density = 1.1 kg/m³, I can calculate the effect of a 5.6 cm drop in head position on power, assuming power depends on frontal cross-section and the head down allows more of my torso to draft. The result: 6.7 watts @ 45 kph.

Chasing to close gaps is always a dicey proposition. Small differences get amplified, since it's speed difference rather than speed which determines how long the chase will be. 6.7 watts can easily make the difference.

None of this is new, of course. Here's a photo of Jacques Anquetil setting the Hour Record:

Friday, January 8, 2010

changing setback

I took a break from thinking about the Metrigear Vector to think a bit about position, after the subject came up in BikeTech Review.

Position's a tricky deal. Move the saddle forward and you feel like sliding back. Then move the saddle back and you feel like riding on the nose. Saddle fore-aft must be dialed in, right?


The reason is when you change the fore-aft position of the saddle, you're changing other things as well. For example, the distance from the saddle to the bars.

Keith Bontrager has an interesting article on position, based on physics. His argument is the key thing is to get your center-of-mass positioned correctly for good handling in the different orientations you typically find yourself. The bike should be balanced in the saddle, out of the saddle sprinting, and out of the saddle climbing. I might add descending is another position which counts. But if you have the right center of mass relative to the bottom bracket, and the right bottom bracket relative to the front and rear wheels, everything should be good.

From a physiological perspective, body position can be dialed in, then the body in that fixed position rotated about the bottom bracket to give the correct center of mass orientation. Assume here that the body position is dialed, and the you're making an adjustment on fore-aft center-of-mass position.

Here's a diagram of my position from a photo I took pedaling the trainer a few years ago, when I was still riding my trusty Fuji Team Mercury-issue Teschner-built Al frame (ah, the good old days, when I worried less about bike mass and spent more time actually riding!)

To get this outline, I first rotated the original photo so the line connecting the hubs was horizontal.

First note the green dashed line: that goes from the front of the crank in a vertical line. Andy Pruitt says this line should come close to the front of the knee. It does in my case, so I pass this test.

But suppose I follow Bontrager's prescription and I want to adjust my position, anyway, after analyzing my center of mass. Focus on the lower triangle (B-S-H). Assume for the sake of this post my body angles are dialed in. So I want to rotate this triangle without changing any of the side lengths (which will also preserve each of the angles: surely you remember the Law of Sines!). Then if I keep the lower triangle unchanged, it's easy to see the upper triangle will be unchanged as well, rotating with the lower triangle. So I don't need to worry about the upper triangle.

The plot shows the length of the run and rise of each line segment, normalized to the high of the hip socket above the bottom bracket. From these dimensions, I can define coordinates, placing the bottom bracket at the origin.

(0, 0): position of bottom bracket
(xS, yS): position of hip socket
(xH, yH): position of hands

Suppose I want to hips back by Δx in these coordinates. If I were to do this and leave it at that, everything would go amok. With the change in xS, I also need to change yS, xH, and yH.

I could worry about angles, or as I noted referring to the Law of Sines, just the side lengths. I'll take that approach.

First the seat: I started with coordinates (xS, yS) for the hip socket. I want the distance to the hip from the bottom bracket to be the same. That's equivalent to the square of the distance to the hip socket to be the same. Therefore:

(xS + Δx)² + (yS + ΔyS)² = xS² + yS²

Expanding the left to first order, then subtracting off xS² + yS² from each side, then dividing by two yields:

ΔyS = ‒Δx (xS / yS)

So I need to lower my seat by a 27% the amount I moved the saddle back (this in x-y coordinates: I'd need to adjust for the seat tube angle).

I want to avoid sines, cosines, and tangents in this analysis, so I'll stick with distances. I now need to move the hand position to maintain both the distance to the bottom bracket and the distance to the hip socket. This involves two unknowns (ΔxH and ΔyH) and two equations.

The first equation:

ΔyH yH = ‒ΔxH xH

and the second equation:

(ΔxH ‒ Δx) (xH ‒ xS) =
   ‒(ΔyH ‒ ΔyS) (yH ‒ yS).

I can multiply all terms by yS then plug in the previous solution for the seat position:

ΔyS yS = ‒Δx xS,


(ΔxH ‒ Δx) (xH ‒ xS) yS =
‒(yS ΔyH + xS Δx) (yH ‒ yS),

which eliminates ΔyS. I now have a choice of solving for either ΔxH or ΔyH. I'll choose the latter, first multiplying top and bottom by xH then plugging in the first equation, then eliminating minus signs from each side (I hate minus signs):

(ΔyH yH + Δx xH) (xH ‒ xS) yS =
(yS ΔyH + xS Δx) (yH ‒ yS) xH.

Good: this is one equation and one unknown, so it's simple algebra.

(ΔyH yH + Δx xH) (xH ‒ xS) yS
(yS ΔyH + xS Δx) (yH ‒ yS) xH = 0.

Now collect terms in ΔyH and Δx:

ΔyH yS [yH (xH ‒ xS) ‒ xH (yH ‒ yS)] =
Δx xH [xS (yH ‒ yS) ‒ yS (xH ‒ xS)].

Some of those terms cancel! (If I'd had my eyes open I'd have noticed this sooner!)

ΔyH yS (xH yS ‒ yH xS) =
Δx xH [xS yH ‒ yS xH].

Then the bracketed terms differ only in sign:

ΔyH yS = ‒Δx xH

Or, simply enough:

ΔyH = ‒Δx xH / yS.

So using my parameters, I want to move my handlebars up 74.7% the amount I moved the seat back (again, in x-y coordinates: I need to adjust for head tube and seat tube angles).

It's then simple to solve for ΔxH:

ΔxH = Δx yH / yS,

which for my coordinates yields ΔxH / Δx = 76.5%.

So in summary, if I move my seat back 1 cm, I would also want to move it down 2.7 mm. I'd then want to move my bars up 7.5 mm and back 7.7 mm.

But I'm not quite done yet... Suppose my seat angle and head tube angle are both 74 degrees. This is what I measured from the photo (obviously a fairly crude measurement) and I don't recall the dimensions of the Fuji. Okay -- finally time for some trig. I then need to move the post down by 2.7 mm / sin 74° = 3 mm, then move the saddle back on the rails by 1 cm + 2.7 mm / tan 74° = 11 mm. Similarly, with the handlebars, I'd need to add 7.5 mm / sin 74° = 8 mm of spacers to the handlebar. And I'd ideally decrease my stem length by 7.7 mm ‒ 7,5 mm / tan 74° = 5.5 mm.

It might be tough getting the 5 mm shorter stem. But I can also get a stem of the same length and a different angle to bring the bars up and closer. I'll leave it here, though. The main point is a simple shift back on the saddle, to be properly evaluated, requires changes to both coordinates of both primary contact points.