Low-Key Hillclimbs week 7x: timing Marin Ave with GPS

Saturday was a double event of sorts for Low-Key Hillclimbs. We had the standard climb, up Lomas Cantadas in the Berkeley Hills, but we combined that with a bonus event, to do Lomas and Marin Ave, in that order, in the same day. We called it the 7X Challenge.

The climb of Lomas Cantadas was fun. I felt stronger than I had the week before, at Patterson Pass. The pace was very quick at the start, requiring a level of explosiveness I simply do not have now or maybe ever, and I drifted back. This cost me a bit on the short descent, where I was in slower traffic than the leaders, but I did well on the final steepest portion, passing riders who suffered from having stuck closer to the leaders in the early going. Among the riders without electric assist, I was 9th, a very good result for me this year, given my ongoing physical therapy to recover from my June crash and injury.

I helped with the finish line crew to get the numbers of riders finishing after me, then headed over to the parking lot near Grizzly Peak Boulevard where Cara had brownies and gingerbread in addition to water, juice, and other goodies. Paul McKenzie and Paul Chuck were there on their tandem, and they led a group to Marin Ave, to complete the 7X challenge.

Marin Ave on tired legs is a memorable experience. The first 8 blocks wear you down so when you crest Euclid, revealing the final three, steepest blocks ahead, it makes a rapid impression. But I survived these three blocks, ending up 4th out of 9 among men in the challenge standings (as I write this: riders may still upload their data until Monday evening). In addition there was one woman, one hybrid-electric bike, and, remarkably, Paul and Paul's tandem.

The timing of the event, not surprisingly, didn't go as smoothly as I'd hoped. It was better than Portola Valley Hills, for sure, but part of that was because there were so many fewer riders. The GPS timing was applied to both Lomas Cantadas and Marin Ave, the former to allow those who didn't do the Low-Key climb to still participate in the 7X Challenge. I'll look here at Marin Ave.

Here's the x-y position (the start line of Lomas is the origin) for all of the riders who did the Challenge course. Most of the data are excellent, but there are three clear outliers:

I plot only the data between the triggering of the start line at the traffic circle at the bottom of the climb and the triggering of the finish at the top of the climb. The obvious culprits are 409 (Edge 500), 405 (Edge 500), and 108 (Edge 800). This wasn't completely to the script that Edge 500's cause all the trouble, but they were still 2/3. In the case of 405 and 108, the data recovered just in time to trigger the finish line. In the case of 409 I had to apply a manual finish line move to have him trigger it (I could also have defined a manual trigger time for the rider: that's a code feature I want to add, since it would be faster than moving the line). I did that by referring to his altitude. I could also have looked at his speed, but the top was fairly obvious from altitude.

This brings up the question whether altitude provides a way to automatically trigger timing events in GPS-timed competitions. For example, if position is poor, but altitude is accurate, and I know the finishing altitude of a climb, then I can trigger the timer when the rider approaches that altitude (leaving some margin for error).

To investigate this, I plotted altitude versus distance for each of the riders. In this case, the distance starts when the rider first triggers the start of the climb. Two riders returned to the start and retriggered it, one after riding partway up Marin, the other up an alternate street. The timing code handles this fine: the time is taken from the last time the start line is crossed. But this isn't important to the purpose here: what's of interest is the start and finish altitude, and if the rider's altitude changes monotonically from start to finish.

The answer: clearly not. And interestingly it's some of the same suspects as last time: 405 (Edge 500) and 108 (Edge 800) have the worst altitude data. 409's profile is poor, but that's perhaps because distance is wrong: the altitude increases monotonically between limits consistent with the other riders.

So what we have is there's a good chance poor position is associated with poor altitude. Since the Garmin units use GPS-corrected barometric altimetry, that's not too surprising. If you're relying on GPS to calibrate the barometer, and the GPS is out on vacation, you're using an unreliable reference. Altitude can't naively be used as a backup for poor position data. Good altitude and good position go hand-in-hand.