testing time budgets: 2013 Low-Key Hillclimbs week 4, Portola Valley Hills

For Low-Key Hillclimbs week 4 riders must ride a series of short hills, and we add up their times on those hills. The intent is that riding between the hills not be included, but we don't want the riders to head out for lunch between climbs, the intent is that the ride be continuous, providing some test of endurance over short hills as well as peak power. So to allow for that there is a time budget to get from one hill to the next.

But if a rider needs to wait for a friend to finish the preceding climb, takes a wrong turn, or even has a puncture and does a fairly quick tube swap, we want the rider to have time to complete the transition. So the times to get between the climbs have been generously allocated. Additionally, Low-Key gets a broad range of riders, including unicyclists in the past, and so it would be a mistake to set these time limits for the fastest riders and compel the more endurance-oriented riders to take stupid risks to avoid additional time being added to their total.

Several riders have pre-ridden the course and posted their data on Strava. I have tested these riders with the PHP and HTML code I will use for rider data entry after the climb. Either the rider or I was able to transfer the data from Strava to the Low-Key Hillclimbs server in every case except one where the rider was using Internet Explorer. I don't consider Internet Explorer's woes to be my problem: it's essentially a broken browser. Fortunately these days almost everyone has access to an alternate.

My code generates a status report of how long it took riders to complete these "transfer" segments relative to the time budget. All of the riders who completed the course are relatively fast, all have ranked highly on Strava segments. So the test is optimistic: I need to make sure the time budget leaves plenty of buffer for the endurance crowd.

Here's the result:

plot

Note there's no data for segments where there is no time budget, segments which are part of the climbs which are intended to fully contribute to the end result.

For the other segments, all points fall well below the 100% limit at which time starts to count. This includes a transition where one of the riders expressed considerable concern over having gone too long due to detouring and stopping for water. That was the point to checkpoint 10 where 71% of the time budget was used. The same rider earlier took a wrong turn (he did the ride before I'd prepared a cue sheet for navigation). This added around 100 meters of extra riding, but more importantly led to a delay while he figured out his error. Here he used 63% of his time budget. So in both cases, despite not taking the most direct route between the points, he finished the sections with plenty of time to spare. All other riders completed all segments with at least 40% of the time remaining (no more than 60% used).

So it seems as if we're ready to go. Riders are crossing the lines reliably and have plenty of time to get between hills. My fingers are crossed things go well. Low-Key is, after all, a perpetual experiment.

Comments

Popular posts from this blog

Marin Avenue (Berkeley)

hummingbird feeder physics

Gallium Pro geometry