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

Last time I argued for automated speed limit enforcement using GPS receivers installed in all new vehicles sold. I would be negligent in doing so without at least proposing an algorithm. So the algorithm is this: Determine the present speed limit. If GPS is used to monitor speed, the GPS coordinates would need to be mapped to a street map to determine a local speed limit. This seems complicated, but in many urban areas the speed limit is the same on all roads in a local grid, so you'd basically just need to identify if the driver might be on an expressway or an interstate based on position and direction. If the speed limit was varying wildly from one road to the next, this would become more complicated, and only the maximum of the local speed limits could be enforced this way. GPS has only a certain position precision. Set a true speed limit 5% higher than the nominal. This gives some margin for error. GPS doesn't have systematic error nearly this large, but it makes se...

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 p...

As I initially described here , I have been developing an event model for GPS data for the Low-Key Hillclimbs. This allow us to do things which weren't possible before: dirt climbs: 2012 and 2013 , where it's better to let riders do it on their own short-hills routes , where there's too many time points for practical hand-timing bonus climbs , supplementing the standard "event", in which riders get a chance to experience more challenges A limitation of the model has been checkpoints are defined as fixed line segments. This provides a much better solution to event applications than does the Strava timing algorithm, which is optimized for users who within a few seconds define an arbitrary, abstract "segment" and the code is left to match rider data to the segment without much additional information. My model is set up for a course designer who is willing to carefully optimize the placement of a series of checkpoints, to improve timing accuracy and to...

As I noted, when dealing with GPS problem cases in the Portola Valley Short-Hills version of the 2013 Low-Key Hillclimbs, I couldn't help but notice every one of the cases I grappled with was an Edge 500. This is anectdotal, so I wanted to take a closer look at the problem. The initial plan was to scrape the HTML from the Strava pages with a Perl app, since the API doesn't provide computer type, but when this didn't work out for me since Strava requires user authentication to see this info bit I started thinking about PHP options but finally when I couldn't sleep last night I just went to the pages sequentially and transcribed the computer identifier from the browser. Brute force. Not elegant. I feel so dirty. There were 69 riders @ Portola Valley who each reported the URLs of their Strava records. I then compared these using the root-mean-square average of the distance from the center of the lines the riders triggered the lines (units: meters). The ideal number...

This is yet another in a series of the Low-Key Hillclimbs Portola Valley Hills multi-climb day. We used GPS to time riders based on when they were interpolated to have crossed a series of "lines" (essentially passing through virtual pylons) in the correct direction. Between certain lines there was a time budget which was designed to be easy to meet, as long as you didn't dally. The lines were designed to be wide enough so all riders who rode the course would be credited with crossing all of the lines, even in the presence of GPS errors. It all worked so well in testing. But in practice, on "game day", the conclusions from testing proved optimistic. First I'll look at time budgets. I had provided a lot of slack in these, and I needed it. There's two major reasons for this. One is that the test riders were mostly solo. On the other hand the "event" riders tended to ride in groups. With group rides the faster riders would wait at the top...

This is another in a series of the Low-Key Hillclimbs Portola Valley Hills meta-climb. It was the second climb where Low-Key used custom timing code to extract rider times from GPS data. But it was by far the most complex, since instead of one climb where time was the difference between the time at the top and bottom, it was a series of 5 climbs where the times from each were added. I did preliminary testing of the Portola Valley Hills course with 6 data sets of riders who had attempted to pre-ride the course. One did the climbs in the incorrect sequence, leaving 5 riders which the scoring code processed. I had no problem with these riders. But it's a big difference between processing 5 data sets and processing 70. Here I'll look at the GPS tracks I recorded for each of the climbs in the Portola Valley Hills. First, the good. Here's plots for the three climbs ending at appropriately named Peak. The plots are x versus y, where x and y are the distance eastward and ...

I'm getting ready for the Devil Mountain Double, and it's a good time to review GPS options for the ride. Back before Strava, GPS was a bit of fluff for rides like this, but the social networking + power analysis + segment timing of Strava provides so much value I wouldn't consider skipping GPS today. The following are the strengths and weaknesses of the various GPS options available to me: Garmin Edge 500: Mine had the tabs snap off on me, so using it would require putting it in my jersey pocket. But I can borrow Cara's for the day. Battery life is likely adequate: it should last the double century if I start with a full charge. I will make sure auto-pause is on to limit battery consumption during rest stops (which will be minimal, but every bit counts). Smart sampling is unavailable due to the power meter (and I wouldn't use it anyway). It's light: only 58 grams without the mount, 66 grams with the mount. It's compact: mounted on my stem it won...

I previously posted a route profile for the Chanteloup climb near Paris, France. This is a climb with an amazingly rich cycling history, going back to Velocio who used it to demonstrate the superiority of multi-gear bikes to the fixed-gear bikes which dominated professional racing in the early 20th century. Later it became the sight for the "Poly de Chanteloup" event, which was contested by randonneurs and professional racers. The randonneur event unfortunately seems to have died, but the professional race continued as the Trophée des Grimpeurs , a traditional last race of the season until sponsorship was lost in 2010 and it also expired. Jan Heine, in his highly recommended book "René Herse" , has the following quote about the gearing of the winning tandem in the 1949 randonneur contest. I posted this last time but I repeat it here because I find it remarkable: A single chainring was sufficient for the 14% of the climb of Chanteloup, which had to be climbed e...

Here's a summary of the method I used to extract times from GPS data on the Kennedy Fire Trail run. First I defined a course. This was done with a series of "lines": line segments the riders needed to cross in a specified direction. This is in contrast to Strava's approach of defining a course via points. For matching, Strava treats the start and end point as special, requiring the activity to pass them with close proximity. Intermediate points need to be matched in a much cruder fashion, and only then a certain fraction of the points. My approach, however, required all intermediate "lines" to be crossed. I defined these points using latitude-longitude coordinate pairs, which are easily extracted from Google Maps (select point, right-click, "What's Here?"). Split times were specified as pairs of lines, where the start line is 0, and the finish line is the last line. For example, my course had split times from 0 to 1 (an initial 40 mete...

Garmin released its Edge 500 head unit at around the same time as CycleOps released its Joule. Each of these was an ANT+ Sport compliant head unit which could read power data from compliant power meters like the Quarq and PowerTap. However, otherwise they almost couldn't be more different. The Joule's focus was on functionality. Power users like to analyze their data, CycleOps reasoned, so we're going to give the user as many options as we can fit to crunch power numbers and even do history analysis. This sounded good, but the head unit is the wrong tool for this job. Riders would upload their data at the end of the ride anyway, for example with Golden Cheetah or WKO, then may be from there to a web site like Training Peaks. So the result was a heavy, bulky, and expensive head unit which sold like coldcakes. And despite all the cost and complexity the unit lacked GPS. Why burden a head unit designed for a power meter with GPS? The Wattage List old-guarde esche...

Okay, back to altimetry. After painstakingly constructing simulated altitude data consisting of the following: true altitude GPS altitude signal: tends to fluctuate and drop out for periods, never deviates too far from the true altitude, at least in my model barometric altitude: smoother than the GPS and never drops out, but has a slowly varying offset from the true altitude So the approach I take is to first identify points at which the GPS signal is good. At those points, I calculate a difference between the GPS and barometic altitudes. I then locally average these distances using my favorite smoothing function, cosine squared: The key is to pick the time constant. Too short a time constant, and you don't suppress the GPS fluctuations. Too long a time constant and the barometric error may change sufficiently that the correction is no longer accurate. So I picked: τ = 100 seconds. When the GPS signal drops out, I don't do the averaging to calculate the correction amplitud...

I'll now describe the model I used for the various altitude signals. This is probably a bit more elaborate than it needed to be, I admit. But I like realism. First, the altitude versus time, as this was the most complicated. I started with Fourier coefficients generated using normal random magnitudes each chosen with an rms value proportional to a Lorentzian factor 1 / [1 + (s / λ)²], where λ is a reference distance of 10 km, describing the approximate length of a typical climb. This distribution is nice because it keeps enough of the high-frequency component for things to be interesting, but while allowing the low-frequency components to generate nice continuous climbs. The phase for each component was then randomized from 0 to 360 degrees. But this doesn't represent a realistic profile, since the random Fourier components yield peaks and valleys of the same shape. So I transformed the altitude using the following: z → (50 meters) ln [ 1 + exp(z / 50 meters) ], which you...

A 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. The 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 baro...