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

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

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

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 th

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 b

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

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: Start with the first point. 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. 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 segm

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

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

Last time I described how the goal was to eliminate climbs less than some threshold (which I'll call h min ) 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 h min . 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 h min But this isn't so easy either. Consider a clim

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 ev

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

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 bar