## Sunday, November 28, 2010

### Low-Key Hillclimbs step response and CTL time constant

This year I was able to ride weeks 3,5,6,7,8, and 9 of the Low-Key Hillclimbs(I coordinated weeks 1-2 and week 4 was canceled due to concerns over rain).

I also started a new job the Monday following the week 3 climb, which reduced my training to essentially the Low-Key Hillclimbs only (I also got in 2 long Sunday rides and one 45-mile commute to work during this period). Previous to this, I'd had a week's vacation in Italy with lots of riding embedded within a longer period where I had weekend rides and weekday training sessions.

My scores clearly suffered from the neglect as the series progressed. I did a regression of the scores, which are normalized to the median rider (sex-adjusted) time which scores 100. Here's the result:

Curiously the time constant came out within 1% of the 42-day CTL time constant.

Anyway, not much significance here, and more sources of variability than I can count, but I thought it was amusing. It appears the 42 day time constant does a fairly good job at matching the rate at which I lose fitness. Note this is my trajectory fitness under my current level of "training": a hard hillclimb effort one day a week, four weeks out of five, with the occasional long ride.

Also on the plot I show an asymptotic projection to my week 3 result with the same time constant. I'd need to start training at the level I was pre-new-job to follow this trajectory. Not enough time before the 1 Jan San Bruno Hillclimb, even were I to get in those mid-week training rides again. And that would be hard to pull-off.

## Saturday, November 27, 2010

### Comparing the Terrible Two, Climb to Kaiser, and Death Ride: Peak Climbing Segments

Today I'll take another look at the route data from the Death Ride, Climb to Kaiser, and the Terrible Two.

Here for each climb I first map the data onto a 50 meter grid, then slightly smooth it using an estimated 15 second time constant (the same as when I calculate a climb rating), then I map it back to a 50 meter point separation (since smoothing disturbs this at the beginning and end of the ride) then I calculate the total climbing (with zero threshold) between each pair of points on the route. For each segment length (which is the number of contiguous points minus one multiplied by 50 meters) I find the segment which maximizes this total climbing.

The only efficiency trick is if I have a given segment length, I don't need to calculate it fresh each time: if I start with the segment from points 1000 to 2000 (length 50 km), and I want to calculate the climbing from points 1001 to 2001, I take the previous sum, subtract the climbing from 1000 to 1001, and then add the climbing from 2000 to 2001. Similarly, if I have the climbing from points 1 to 2000, and I want to calculate the climbing from points 1 to 2001, I need only add the climbing from 2000 to 2001, saving a lot of time.

Anyway, here's the result for the three climbs:

So up to around 30 km, the Terrible Two has the steepest segments, then from 30 km to 160 km the Climb to Kaiser has the greatest climbing density, then the Death Ride catches climb to Kaiser. They're fairly well matched to the point the Death Ride ends at 200 km, then Climb to Kaiser adds a bit more until it comes to a merciful halt at 250 km. The Terrible Two matches Climb to Kaiser over the same distance but overtakes it with a sheer volume which lasts out to 314 km.

Also of substantial interest is where these peak climbing segments fall. So for each amount of climbing, I plotted a band showing where the shortest segment containing that amount of climbing is. First, the Death Ride:

So the steepest short stuff is on Ebbetts East. For a bit longer, it moves to Monitor East and then to Monitor West. Beyond 940 meters or so you need combinations: first the Ebbetts pair, then the Monitor pair, then finally (on the range of the plot) to Monitor-Ebbetts-Ebbetts.

Here's the same analysis applied to Climb to Kaiser:

Obviously the nastiest grades are at Big Creek. For more climbing you go to Tollhouse. And for more still, start at Big Creek and go all the way to Kaiser summit. If you run out of climbing here (Big Creek is preceded by a descent) you go from Tollhouse and continue past Shaver Lake.

Finally, Terrible Two:

For shorter segments, Gualala and Fort Ross compete for the steepest. For longer, you go to the Geysers. If you run out of room there, the repeated climb-descent segments of Skaggs Springs are the densest climbing. After this you get into more extended combinations.

Anyway, I like this analysis, and will likely add it to the pages for future Low-Key events.

## Tuesday, November 23, 2010

### Comparing the Terrible Two, Climb to Kaiser, and Death Ride: Profiles

Last time I used grade histograms and total climbing versus climbing threshold to compare three really solid one-day riding challenges: the Death Ride, Climb to Kaiser, and the Terrible Two.

What I left out is sort of the obvious: the route profiles. Every big ride shows its route profile, and they all tend to sort of look the same: up and down. So to compare the three, I plotted them on the same axes. I use km for distance and meters for altitude:

That one's worth more than the measly 100 kpixels shown here, so if you click on the plot you should see a higher resolution version.

Anyway, the Death Ride and Climb to Kaiser look sort of imposing here. The Terrible Two is almost lost under the giant altitudes of those other two rides. Climb to Kaiser is perhaps most striking of the three, starting down in the lowlands before rising to and beyond the lofty altitudes of the Death Ride. Indeed, Climb to Kaiser is a very special ride, one I often recommend to those who think the Death Ride is the best thing since the invention of the cable-actuated derailleur.

Next time I'll introduce yet another way to plot the altitude data: total climbing versus distance, where for each distance the ride segment was chosen to maximize the climbing.

## Monday, November 22, 2010

### Comparing the Terrible Two, Climb to Kaiser, and Death Ride

First, a bit about the climbing algorithm. Just two paragraphs, I promise. Then on to good stuff.

I just described an algorithm by which you can calculate total climbing from a route profile with a given "climbing threshold" designed to both eliminate small bumps which can be coasted over, but more importantly to get rid of the small altitude fluctuations which occur with "noise" in both barometric and GPS-based altimeters. I proposed that a 5 meter threshold worked well, but that there was no unique answer for what is the "true" climbing of a route.

Well, that algorithm does work well for a relatively small climbing threshold, but when you crank the threshold up to the size of the largest hills on a ride, it can be fooled. For this post, I thus added an extra step to the process, in which peaks closer than the climbing threshold from the minimum altitude on the ride, and valleys closer than the threshold from the maximum altitude on the ride are both pruned. This may not be perfect, either, but suits the purpose of this post.

That purpose is to compare three rides, each of which is considered a major climbing challenge for Northern California cyclists: the Death Ride, Climb to Kaiser, and the Terrible Two.

I've done each of these rides at least twice, and so have a special affection for each of them. They each have their own unique character, each their own brand of challenge.

Total climbing plotted versus climbing threshold provides a certain signature to the nature of a given route. So I'll do that here for these three climbs, where in each case I downloaded data from recent versions of the rides from Garmin Connect:

Impressive, all three. Each claims to have the most climbing for some range of climbing thresholds. With a low threshold, including my recommended value of 5 meters (indicated with the dotted line on the plot), the Terrible Two comes out ahead. Indeed, the Terrible Two is well names, presenting the rider with a series of extremely steep challenging climbs, most notably Skaggs Springs Road out to Highway 1, then to seal the deal, Fort Ross Road back inland. Yet none of these climbs is particularly long. The net climbing drops to zero at around 832 meters, the Gaysers.

Now consider the Climb to Kaiser. That scores second with a 5 meter threshold. But at around 25 meters if fades behind the Death Ride: Climb to Kaiser has its share of bumps. Then it fades more until it hits a wonderful plateau at near 400 meters, just enough to filter out the descent-climb at Big Creek Road. Beyond that it's clear sailing all the way out to 2695 meters, or 8840 feet, the altitude gained between the start and Kaiser Pass. This is what Kaiser is famous for: the sheer enormity of the altitude change between Clovis and the turn-around.

The Death Ride is the last of the three climbs at the 5 meter threshold. But where it excels is between approximately 70 meters and 900 meters. That's what the Death Ride is: a series of long, steady climbs followed by long, steady (and fast!) descents.

This plot compares the magnitude of climbing on the routes, but it doesn't directly say anything about grade. For that, I go to my climbing histogram, where I plot the net climbing at or above each given grade for each of the three climbs.

This plot is less ambiguous. It's clear at dishing out the steep, Terrible Two is the terrible winner. It's a solid 5% steeper at each given total climbing point than the Death Ride over much of the plot. Those are five painful percent. Climb to Kaiser delivers its dose of nasty at Big Creek. That's about as tough as it gets in this sort of ride, but it's just one climb, while Terrible Two dishes out the pain multiple times throughout its 200 miles.

Of course, Death Ride supporters will always say the altitude is the big factor there. And it is a big factor. Even though Climb to Kaiser gets higher than the Death Ride, the Death Ride stays at over 4000 foot altitude throughout, while the Climb to Kaiser just visits for part of the day. But Climb to Kaiser has terrible heat in the valley, ironically providing some of the greatest difficulty on the flattest portion of the ride. And while not up to Fresno's standards, Terrible Two is famous for its heat as well, subjecting riders to the heat for more of the course than Kaiser where it's really only the final 25 miles after riders drop from the sky.

So I stand behind the numbers: Terrible Two first, Climb to Kaiser second, and Death Ride third. All three are tough, though: it would be a terrible mistake to take the Death Ride for granted.

## Friday, November 19, 2010

### testing the corrected total climbing algorithm

Okay, so déja-vu time. Once again I exercise my total climbing algorithm, except this time doing it right.

Here's the ride from last Sunday again, where I plot total climbing versus the climbing threshold. I've "greyed out" the result from the flawed version of the flawed algorithm. The difference is most evident for the larger values of the climbing threshold, where there's more pruning to be done. As long as pruning was on isolated segments, the old algorithm did okay. It's when multiple sequential climbs and descents were clipped that things went sour.

Now I look once again at the data from my ride. I plot here only the data from after I first crossed the west peak of Mt Tam. Here's the result using a 5 meter threshold, compared to the full measured profile:

Next, the 15 meter threshold. This did okay last time, and with the improved clipping, it does even better. 15 meters is close to the 50 foot threshold I believe was used with the old Avocet 50. However, it does merge the two climbs approaching the west peak, and when riding, those really do feel like two climbs separated by a descent, so I'd prefer they not be merged. Points to 5 meters. However, unlike the last time, the 15 meter algorithm is doing much better on the climbs in Sausalito and San Francisco.

So finally the 50 meter threshold. This one is clearly merging quite a lot. It has made substantial progress with the corrected algorithm, but still simply fails to give adequate recognition to the repeated onslaught of small steep hills San Francisco likes to dish out if you're not careful in route selection (and I have a habit "neglecting" to avoid the steep stuff).

Obviously this time I checked all of these using the reverse direction as well. Descending in the reverse direction should equal climbing in the forward. And indeed while the two directions don't necessarily result in the identical selection of points, they do always result in the same total climbing. In some cases there are multiple points at the same altitude and the direction may affect which how the ties are broken.

So there it is. I wish I hadn't made that mistake earlier, but I'm prone to mistakes. Sigh.

## Thursday, November 18, 2010

### total climbing and descending algorithm: correct version

Last time I demonstrated how important it is to take some care in pruning points to simplify the profile while conserving climbs which are in excess of the minimum threshold. Before that, I'd proposed an algorithm to calculate total climbing and descending, but I was sloppy. Nevertheless even my flawed algorithm demonstrated that a climbing threshold of 5 meters was desirable.

There's one key thing I was missing in my previous algorithm, and that's to make sure pruned segments are bounded on both the high and low side by adjacent points. So here's my revised approach.

First, merge monotonic segments, as follows:
2. Until the following two segments are either climb-descend or descend climb, or until the following point is the final point in the ride, delete the following point.
3. Move on to the next point and repeat the previous step if there's at least three points past the current point.

So now the profile consists of uphill segments alternating with downhill segments (or perhaps just a single flat segment if there's no climbing or descending in the route). Next we prune it down:
2. Check to make sure there's at least four points starting with the current point; if not, we're done.
3. If of the four points starting with the present point, if the difference between the middle two are less than the climbing threshold, and if neither of these middle two points are greater than both the first and last points nor less than both the first and last points, then delete the middle two points and back up two positions (or to the start of all points if there's fewer than two points prior to the present position). If there was no deletion, move to the next point.
4. Repeat step 2.

There we go: that's it. An example, where the threshold is 5, follows. The current point will be marked in green. S point about to be deleted will be marked in red:

We start at the first point:

1, 2, 4, 3, 6, 2, 7, 6, 5, 4, 6, 1

The next The next two segments are both climbing, so we delete the next point:

1, 4, 3, 6, 2, 7, 6, 5, 4, 6, 1

Now we have a climb-descend combo, so we move to the next point:

1, 4, 3, 6, 2, 7, 6, 5, 4, 6, 1

Now a descend-climb, so next point:

1, 4, 3, 6, 2, 7, 6, 5, 4, 6, 1

Climb-descend, so next point:

1, 4, 3, 6, 2, 7, 6, 5, 4, 6, 1

Descend-climb, so next point:

1, 4, 3, 6, 2, 7, 6, 5, 4, 6, 1

Again, to the next point:

1, 4, 3, 6, 2, 7, 6, 6, 4, 6, 1

7-6-6 doesn't have both a climb and a descent, so the middle point goes:

1, 4, 3, 6, 2, 7, 6, 4, 6, 1

7-6-4 lacks a climb, so the middle point gets pruned:

1, 4, 3, 6, 2, 7, 4, 6, 1

Now we have a 7-4-6 descend-climb, so next point:

1, 4, 3, 6, 2, 7, 4, 6, 1

4-6-1 is good, and these are the final three points, so we're done with the first part. Now we go to the second part... back to the first point:

1, 4, 3, 6, 2, 7, 4, 6, 1

The first four points are 1-4-3-6. The middle two points are encapsulated by the outer two, and the difference is less than 5, so they go. Normally we'd back step twice at this point, but we're at the first point already, so there's nowhere to go:

1, 6, 2, 7, 4, 6, 1

Again the points are within 5, and neither is either the largest or smallest of the four points starting with the current point, so again the middle two get snipped:

1, 7, 4, 6, 1

Here the 7 and 4 are less than 5 apart, but the 7 is the largest of the four, so we don't want to delete it. So we move up:

1, 7, 4, 6, 1

Here the 4 and 6 are less than 5 apart, and neither is larger than the 7 or less than the 1, so they go, and we back up:

1, 7, 1

There's fewer than four points left starting with the current point, so we're done.

So from those original points:

1, 2, 4, 3, 6, 2, 7, 6, 6, 4, 6, 1

All we ended up with in the end was the climb from 1 to 7 and the descent back. We could run the points in the opposite order and get the same result.

## Wednesday, November 17, 2010

### total climbing and descending algorithm: FAIL

In my last few blog posts, I proposed a total climbing algorithm. Now to tell the truth, I didn't just invent this for the first time now -- years ago I wrote a program to decode files from the Specialized pBrain, a rather well-designed altitude-recoring cycling computer which actually cost more over 10 years ago than an Edge 500 does today, but having downloadable altitude profiles was so novel, I considered it worth every penny, at least until the bike I had it mounted to was stolen. I lost track of that old source code so I basically started from scratch to facilitate generating climbing statistics for the Low-Key Hillclimbs.

Anyway, I was reviewing the plots I posted last time and I realized the algorithm I just described was flawed. You can see it most clearly in the 50 meter threshold plot:

Ouch -- there's a bunch of low-lying fruit which remains unpicked in the 90-95 km range, all passed up for a higher point at km 103. This clearly isn't calculating total climbing properly.

Since the algoritm calculates climbing and descending it had better be the case that climbing calculated in one direction equals descending calculated in the opposite direction, and for that to be the case the points chosen for the tops and bottoms of each sub-climb (or descent) should have the same altitudes. This is clearly not the case here:

What a total mess: the algorithm is choosing different peak and valley points if it starts from the right than if it starts from the left. Neither of these directions yields the optimal choice. For example there's a big juicy peak at km 9 which neither direction chooses.

The problem is when I had 4 consecutive points and eliminted the middle two (the second of three segments) if it was less than the climbing threshold. Yet I reclessly pruned sub-standard segments without due attention to maximizing the altitude gain of the surviving segment. Consider the following bad example, which if the points are processed left-to-right the algorithm I described would yield:

Bad, bad, bad. The top of that hill has been snipped off. The following is the correct choice:

Once you've got a good picture of what you want, the algorithm almost produces itself. And in this case I got a big deja-vu from having worked on this 10 years ago.

Anyway, the "correct" approach next time...

## Tuesday, November 16, 2010

### testing the total climbing algorithm

On Sunday I did the following ride. I'd like to say this sort of thing is typical but sadly it was the longest ride I'd done in at least 5 weeks. New job and a tendency toward Sunday rain around here has kept me from getting in any long ones lately:

I imported my Edge 500 data into GoldenCheetah, exported CSV, and ran it through my algorithm. As a test, I varied the climbing threshold from 1 meter to 100 meters. Here's the the result:

Clearly, there's no "correct" answer, no unique value of total climbing. We generally agree if I make 100 different cycling computers and each measure distance, they should agree within, for example, 0.1% if perfectly calibrated. Sure, there's issues of whether they measure the distance traversed by the handlebars or by the tire-road contact patch if the bike banks into corners. But these are minor differences. However, with "total climbing", assuming you don't want to measure every vibration as a "climb", the result is sort of arbitrary. In the the "feel" test applies. If something feels like a climb, it should probably be counted as a climb. It should be memorable.

So I pulled out selected climbing thresholds for the "feel" test. I already noted I don't think if momentum alone can deliver the potential energy to get over an altitude difference, that should count as a full climb. So 5 meters is the lower limit. Here's the result for 5 meters, where for clarity I've restricted the plot to the portion of the climb from the Mt Tamaplais parking area back home:

Already I can tell you I remember every one of those "climbs" and they are real. So I'm fairly sure I have my answer already. From a noise standpoint, I think we can agree the Edge 500 does rather well. I'd hope there's been improvements since the Avocet 50, close to twenty years older.

Here's the result for 15 meters:

That's not too bad, really. But starting from the left is the short climb to the Mt Tam parking lot near the East Peak. There I stopped to check on updates on Miles, who works at the snack bar but is on leave for cancer treatment, and of course to admire the view. From there the road descends, climbs, descends again, then climbs to the West Peak, the so-called "Golf Ball" due to the old military spherical antenna mounted there. Unfortunately these little climb-descend sequences get merged with a 15 meter threshold. So 15 meters is too high. 5 meters did better by the "feel test".

Now 50 meters: this is what that yields:

That's just plain silly. Okay, so it got Pacific Ave climbing out of the Presidio up to Davisidero. But it discarded Fillmore Street, the famed climb from the old San Francisco Grand Prix. And I assure you that Fillmore Street very much qualified for the "feel test". You'd have to be a real hard-case to claim the threshold should be 50 meters.

So there it is: 5 meters wins. 1 meter and you're counting stuff which can be coasted, and are subject to the whim of minor barometric variations (assuming pressure is used to help with altimetry). Much more than 5 meters, though, and you're losing stuff which the legs will tell you is a real and worthy climbing segment.

## Sunday, November 14, 2010

### total climbing and descending algorithm

Last time I described how the goal was to eliminate climbs less than some threshold (which I'll call hmin) while preserving the starting and ending altitude for a route. Here's the algorithm I implemented.

A climb is represented as a series of points, each with a distance and altitude. I'll ignore distance. Distance might be used to apply some numerical smoothing to the data before implementing this algorithm, but that's optional. Here I care only about altitude.

One approach might be to consider consecutive points and count only climbing or descending which exceeds hmin. This obviously fails because a climb might consist of 1000 consecutive one-meter altitude gains. So then I might combine all adjacent non-descending segments together, then all adjacent non-climbing segments, etc, to yield alternating climb-descend-climb-descend. I could then eliminate the segments which gain or lose less than hmin But this isn't so easy either. Consider a climb which gains 4 meters, descends one, then gains 4, descends 1, one hundred times total. That's a 300 meter climb, and certainly should be counted.

So I've got to be careful in how I do this.

I'll look at four consecutive points at a time. I'll call these points a, b, c, and d. If I move on to the next point, the old b becomes the new a, the old c becomes the new b, the old d becomes the new c, and the new d is the point which follows the old d. Additionally, if I delete a point, the following points shift to fill the missing position. For example, if I delete c, the old d becomes the new c, and the point following the old d becomes the new d.

1. First, if I'm at the first position in the data (otherwise this isn't needed: until b is either higher than both a and c, or lower than both a and c, or until there is no remaining point c, delete b.
2. Next, until c is either higher than both b and d, or lower than both b and d, or until there are no remaining point d, delete c.
3. If there's still a point d, then if the difference between the altitudes of b and c is less than hmin, then delete both b and c.
4. If b and c were deleted, move back a point. Otherwise, move ahead a point.
5. If there's still a point c, repeat, otherwise we're done.

Here's an example derived from randomly-generated numbers.... I'll set hmin = 5. I list altitudes, which could be meters, but that's irrelevant:

38, 26, 23, 20, 46, 42, 44, 29, 8, 41

In each case the point I've been labeling "a" will be marked:

38, 26, 23, 20, 46, 31, 44, 29, 8, 41

First, step 1:

38, 23, 20, 46, 42, 27, 29, 8, 41
38, 20, 46, 42, 27, 29, 8, 41

Step 1 now is done, because 20 < 38, and 20 < 46. Then step 2 does nothing (since 46 > 20, and 46 > 42). So step 3: 46 ‒ 20 > 5, so I don't delete any points, and move on to the next point: 38, 20, 46, 42, 27, 29, 8, 41

Step 1: I'm not at the first position, so I skip this.

Step 2: 46 > 42 > 27, so 42 goes

38, 20, 46, 27, 29, 8, 41

Step 3: 46 ‒ 20 > 5, so I don't delete anything and move ahead (step 4):

38, 20, 46, 27, 29, 8, 41

Step 1: Not at the first position, so not needed.

Step 2: 29 is the largest of 27, 29, and 8, so nothing to delete here.

Step 3: 29 ‒ 27 < 2, so I need to delete the pair 27, 29:

38, 20, 46, 8, 41

Step 4: we move back a point:

38, 20, 46, 8, 41

Steps 1, 2, and 3 do nothing, so we move the point back up:

38, 20, 46, 8, 41

Step 1: Not needed, since I'm not at the first position.

Step 2: there's no point d, so nothing to do.

Step 3: there's no point d, so nothing to do, and I step forward:

38, 20, 46, 8, 41

I've got only two points left, so I'm done:

38, 20, 46, 8, 41

So I see I have a descent of 18, followed by a climb of 26, then a descent of 38, then finally a climb of 33. Total climbing = 26 + 33 = 59, while total descending = 18 + 38 = 56.

So that's it: really simple.

This example wasn't the best, because it failed to demonstrate why you need to step back after deleting point pairs. The reason is if you delete b and c, then the old d becomes the new b, and it's possible the difference between a and b is now less than the hmin. If I step backward I'll catch that is step 3.

Here's the result for Mt Hamilton Road, using data I got from Garmin Connect:

```km      meters  climbing descending
0       0       0        0
9.56243 461.522 461.522  0
10.8524 407.685 461.522  53.837
10.9968 413.452 467.289  53.837
12.418  362.502 467.289  104.787
17.5911 597.073 701.86   104.787
18.6179 541.794 701.86   160.066
18.7925 552.852 712.918  160.066
19.0447 533.623 712.918  179.295
29.6209 1161.39 1340.68  179.295```

Here's these key points plotted on top of the original profile:

One comment on this algorithm: it's not totally rational. Consider the following points:

0, 1 .

Total climbing = 1, since I don't touch either the starting or the finishing point. But now I add an additional point:

0, 1, 0 ,

and now total climbing is 0. So adding a point reduced the total climbing. But what can you do? The alternative is total climbing minus total descending might not equal the net altitude change, so I'm willing to live with the anomaly.

## Saturday, November 13, 2010

### Calculating Net Climbing and Descending

 The Alta Alpine 8-pass challenge is listed with 20300 feet of climbing in 198 miles
Whenever a route is described, for example a climb or a "century"-type ride, people want to know two pieces of information: distance and total climbing. There's not much to be said about total distance, although different methods (GPS versus counting wheel rotations versus using digital map data) may yield slightly different results. Climbing, on the other hand, is more challenging.

You'd think it would be simple: for each adjacent pair of points a and b, if the route travels from a to b and b is higher, the difference in altitude is added to total climbing. If a is higher, the difference is added to total descending. Now b becomes the new a, the next point after the old b becomes the new b, and repeat.

Except this doesn't work. The reason is measuring altitude typically involves errors which are different from one point to the next. Suppose I have points every 10 meters on a perfectly flat 100 km route. Suppose 25% of these points tend to be measured 1 meter too high, 25% 1 meter too low, and 50% the correct altitude rounded to the nearest meter. Then I'll make on average an error in climbing of 37.5 cm in climbing and 37.5 cm in descending per point. By the end of 100 km, the accumulated climbing from these small +/- 1 meter errors will be 3750 meters. That's a huge total for 100 km.

 Avocet 50: ahead of its time
So you need some sort of filter. Avocet had the first popular cycling computer to calculate net climbing, the Avocet 50. Jobst Brandt worked with them on their algorithm, which worked better than most computers produced for years after (I recommend the California Triple Crown data of total climbing reported by a range of cycling computers on qualified double century rides). Avocet's approach was to ignore climbs which gained or lost less than 50 feet. I like that approach, so will describe here how such an algorithm can be implemented.

First, even in the absence of measurement error, there's a rational basis for such an algorithm. After all, each bump in the asphalt is "climbing" and "descending". Yet the bikes coasts over these small bumps, they aren't "climbed" in the traditional sense. So a decent criterion for what consistutes a significant change in altitude is how large an altitude difference can be coasted.

The solution is simple: the ratio of kinetic energy to total mass is ½v², where v is the initial bike speed. The ratio of potential energy to total mass needed to change altitude is gh, where h is the height and g is the acceleration of gravity. Coasting up a hill converts kinetic into potential energy: when all the kinetic energy is gone, the rider needs to pedal. So the height h which can be climbed from coasting, neglecting rolling resistance, wind resistance, and mechanical losses from the bike, is:

h = ½v² / g

So consider an initial v = 10 meters/second. g is about 10 meters/second². So this gives:

h = 5 meters

5 meters is less than the 50 feet the Avocet might have used, but is pretty much the lowest value I'd personally use. 5 meters of elevation gain is really too small to contribute to a route feeling hilly.

So that's the goal: eliminate climbs and descents which are less than some threshold. But I'll apply another constraint: the starting and ending elevations of a "ride" are unchanged by the algorithm. In other words, while "total" or "gross" climbing may be subject to debate, "net" climbing should not. In particular it would be embarrassing if the algorithm decided climbing did not equal descending on a route which finished where it began.

So I'll describe my algorithm next time.

## Monday, November 8, 2010

Approaching Mt Vaca

We're getting close to the end game in the 2010 Low-Key Hillclimbs and the mind naturally turns to the 2011 schedule. And there's one climb which I've wanted to visit ever since it was first suggested to me three years ago.

That's Mix Canyon Road out of Vacaville. From Vacaville, you follow Pleasants Valley Road to the north until Mix goes off to the left.

View Larger Map

The usual response is it's sort of far afield. Sure, from San Jose it's 91 miles and it's 86 from Palo Alto but from San Francisco, where I live, it's closer than three of the climbs on the 2010 schedule. I'm not too worried about the distance. It's worth a bit of travel for a very special climb.

After the turn the road climbs gradually but it gets steeper the further you go. Approaching the summit is a will-cracking 15% sustained, which means sections at 20% with "recovery" at around 10%. The combination of altitude gained, the duration of the steep portion, and the location of the steep segment within the overall climb is a combination which is really hard to resist.

The profile tells a big story, but I also like grade histograms. My favorite representation is in total climb at or above each particular grade after applying a smoothing function representing the general ability of a rider to "power up" short steep sections. Here's how Mix Canyon fares in this analysis, compared to Old La Honda road, the unit reference for cycling climbs:

There's some serious action there in the ≥ 15% range. Mix gives up nothing to Welch Creek or Bohlman-Norton up here. And Mix delivers its maximum grades in a bigger chunk, with more climbing already in the legs.

And the numbers back this up. The climb's rating is 245. That compares to 235 for Alba and 231 for Bohlman-Norton. Mix is rated higher than any climb Low-Key has done.

Anyway, it's definitely on my to-do list, one way or another.

## Sunday, November 7, 2010

### 2011 Cervelo geometry

The 2011 Cervelo bike pages are finally up. I find Cervelo particularly interesting because they are deliberate in their geometry decisions, designing their bikes with a coherent philosophy across the entire size range rather than the more ad hoc approach which generally preceded them.

Initially Cervelo came out with the R and S series which were designed to be aggressive. The idea was if you needed the handlebars higher, you could always simply add spacers. But riders don't like spacers: they don't "look pro". Of course if the rider in question isn't pro, "looking pro" shouldn't be a concern. But for some reason people want to "look pro" for their club rides. And indeed there's a limit to how many spacers you probably want. Better to have the frame design utilize available space a bit better.

So they came out with the RS, a more relaxed geometry. No problem: now they spanned the geometry range. Now if you wanted the bars sufficiently higher than the R-series, you could get the RS. The RS also had longer chainstays for a bit more comfort over rough roads.

Yet some people didn't want to be seen riding the "RS", obviously a "fatty master's bike". It didn't matter how few spacers you had: just the letters "RS" looked un-pro.

So Cervelo for 2011 simplified: increase the chainstays up to the RS-standard (and the standard of the rest of the industry: the 2010 R and S series chainstays were exceptionally short), and more assertively increase the head tube length with the frame size. As a result, the large and extra-large R-series frame this year is basically the 2010 RS.

But the key difference is the frame says "R", not "RS". So riders need not hang their heads in shame. They're on the "pro" bike.

They also reduced the pedal-to-front-wheel overlap on the smaller frames. Some riders didn't like it that if you turned your wheel away from your forward foot, the tire could strike your shoe. The obvious solution is to not turn your wheel into your forward foot: to turn the wheel that much requires walking-pace speed anyway. It's not hard to avoid. But people don't like it, anyway. Cervelo's view was that good handling at high speed (which comes with the shorter front-end) is more important than handling at walking pace (which is compromised by toe overlap), but they've finally backed down from that position.

Here's a plot of the head tube length plotted as a function of reach, reach being the horizontal distance between the seat post and where the fork steerer tube exits the head tube. You can see the 2011's are all-around taller in the head tube: fewer unsightly spacers! The difference goes from 8 mm in the smaller frames up to the full gap between the 2010 R and RS in the larger frames.