Ridecast logo
January 30, 2010

Figure out the trip type

Filed under: GPS — mtbguru @ 10:12 am

Check out this graph:

Three tracks: 1 bike, 1 car, 1 public transit

The three traces (speed versus distance) originate from GPS tracks taken between the same point A and the same point B, on different occasions, using three different transportation modes: driving, cycling and public transit (bus+train).

It is pretty obvious which is which. You can even recognize and identify traffic light stops, sections of freeway, bus stops, bus versus train rides (and also – ahem – speeding).

Which makes one think that it should be possible to algorithmically deduce the trip type and nature from just the GPS data, with pretty good accuracy. There will be problems though (fast trail runner or mountain biker?)…

January 28, 2010

MTB event calendars

Filed under: Riding and racing — mtbguru @ 10:04 pm

We’re already a month underway and I still need to figure out which races I want to do in 2010 – not that I really need to do any, but they’re sometimes too much fun to pass on. Alas, there is so much out there, and so little time – which I guess is a good thing. As I tend to forget the various calendar url’s and sites, below is a list of links, mostly for my own reference (hence a bit of a Norcal bias) – but they could be of general usefulness…

mtbcalendar.com
Very nice (Rails-based) community-based calendar site, covering a huge amount of events, pretty much everywhere.

norcalmtnbikeracing.blogspot.com
Excellent site focusing on Northern California events

www.prerace.com
Very useful US based race calendar site – nice thing is it also contains road races and e.g. xc ski events.

www2.mtbracenews.com/calendar
Another good one…

www.usmtb100.com
The National Ultra Endurance (NUE) series of 100 milers.

www.usacycling.org/mbnc
USA Cycling calendar

Also, the ultra racing forum on bikepacking.net is something to keep an eye on, there are some amazing rides being staged – the new, awesome and particulary grueling looking Arizona Trail race comes to mind!

My plan? To do a bunch of local events (e.g. Sea Otter, CCCX, Coe), a still-to-be-decided 100 miler, throw in some tri, xterra or road events for good measure and I’d love to do a bikepacking event as well, but we’ll see how far I get – so much to do, so little time…

January 19, 2010

GPS elevation: Garmin versus iPhone

Filed under: GPS,Tech Corner — mtbguru @ 12:30 am

In the previous post we mentioned that barometric altitude sensors will generally give you a more accurate measure for altitude and total elevation gains than a purely trilatered GPS elevation signal. That would be true if the barometric sensor is periodically or continuously recalibrated, and if you don’t happen to be hit by some crazy weather system (see Mike B’s comment below).

A question now is, by how much? The barometric sensor is accurate because it is possible to very precisely measure small differences in air pressure. Slow drift has the potential to mess things up – the reason for the recalibration-caveat – but on short time scales (and at a constant temperature) altitude changes can be measured as accurately as to a few feet. GPS trilateration without some kind of ‘augmentation’ can’t beat that, says Wikipedia; such augmentation schemes generally make use of ground stations to improve the GPS signal, and there’s a whole garden variety of them.

Rather than keep this a theoretical discussion, I was curious to see how well one of the most common GPS devices out there without barometer would perform: the iPhone. I don’t know whether the iPhone does GPS augmentation, but I can imagine it does, since the thing obviously does communicate to cell phone towers. And so I set out to collect some data and compare an iPhone 3GS with my Garmin Edge 705 (which uses a barometric sensor for elevation with automatic and continuous/periodic recalibration).

The iPhone doesn’t come with a native GPS application, but there are of course a gazillion of apps that could come in handy – I found MotionX GPS to be a very impressive GPS application, and one of the best ways on the iPhone to record tracks, statistics and display them on maps (for the record, we have no connection whatsoever to MotionX or its creators). You can download the raw track data off the phone, nicely wrapped in GPX format – of course, I don’t know how the raw iPhone data looks like and what kind of algorithms or filtering (if any) MotionX performs on these track data, so it should be understood in the discussion below that there may be MotionX idiosyncrasies at work rather than just iPhone 3GS ones.

The first data set was taken on a ride in Santa Teresa County park in San Jose – the route is an out and back on rocky, techy, yummy singletrack (featuring Stiles Ranch and Rocky Ridge, for the connoisseurs), with plenty of small up-and-downs typical for mountain bike rides. The blue (top) trace shows the Edge 705 data, the red (bottom) the iPhone data, taken simultaneously.

Santa Teresa data

Totals:
Garmin Edge 705: elevation gain 1797 ft, loss 1786 ft
iPhone 3GS: elevation gain 1476 ft, loss 1536 ft

The iPhone data is not terrible and actually looks a bit better than I’d expected, but still deviates over 15% for the totals; and this for a short 10 mile ride. Since this is an out-and-back, the curves should look symmetrical – the Edge data is looking very nice indeed, the iPhone data drifts off quite a bit.

The graph below shows a subset of the same data, but plotted against time rather than distance (about a seven minute section).
Santa Teresa data
The Edge has a setting to impose ‘adaptive’ data recording meaning some points (which do not differ much from the previous ones) are thrown out, to save memory; this setting was used here. The iPhone doesn’t have such feature, but it does have another interesting one: ‘accelerometric assisted GPS’ – used for this data set – another form of GPS ‘augmentation’, though I’m not sure how effective this is (another experiment would be required).
Interesting to note on the graph is that the sampling rate of the iPhone is generally a bit higher, except in large ‘voids’, where a lot of the signal is missing.

A second data set was taken, this time during a 17 mile car drive, in order to see if there was anything specific to the previous data – in particular, what effect the relatively low speed of mountain bike riding has.

Car drive data

Totals:
Garmin Edge 705: elevation gain 690 ft, loss 704 ft
iPhone 3GS: elevation gain 301 ft, loss 294 ft

The iPhone seems to deviate even more now (-50% on the totals, the curves differ more) even though the elevation profile of this track is generally ‘gentler’ – what is most different here in this track are the moving speeds (50 – 60 mph) so this probably says the GPS trilateration process isn’t fast enough and can’t keep up with the barometric sensor.

Of course, a third way of extracting altitude/elevation data not requiring any altitude measurement is to overlay the tracks after they’ve been acquired (longitude and latitude on the earth’s surface) on digital maps or digital elevation models (DEM’s), but that’s opening up another can of worms (interpolation, etc) – which is maybe something for another occasion.

January 12, 2010

Elevation accuracy, revisited

Filed under: GPS,Tech Corner — mtbguru @ 9:00 am

Time to revisit a familiar topic: since a few months we’re using a different algorithm to extract elevation data from uploaded GPS tracks. Without going into too much mathematical detail (which can be quite entertaining though), it consists of a discrete exponential smoothing filter followed by simple thresholding. There are more refined and better filters possible (trigonometric bandpass filters etc), but it is simple, and with only two parameters (RC constant and threshold), it seems to work pretty well for the typical data that gets uploaded to the site.

This data is generally recorded by GPS devices, and usually of decent quality already in its raw form. The best devices combine barometric sensor readings with the trilatered elevation (z-coordinate) from the GPS satellites, the latter typically being used to compensate any slow drift of the barometric sensor (for instance due to weather changes). Nevertheless, even for raw data of such relatively high quality, calculated totals for altitude gain and loss during rides have been a source of doubt and confusion for many people. And this goes both ways: it’s being felt as being either inflated, or underestimated (though mostly the former).

The trusted numbers...
Something people generally do tend to trust, are the totals the device itself displays at the end of the ride – perhaps because of the more tangible nature of the process? But that number is of course also the result of some internal (and unknown) filtering algorithm. Now the issue is mostly for mountain bike rides on rather chunky terrain (technical, many short ups-and-downs), or for very long mountain bike rides (100 milers e.g.), where small errors may accumulate to very large ones – for road rides and other ‘smooth’ tracks there was never much deviation with the old algorithms or ground for discussion.

So back to filtering, which I’ll now try to explain using simple, non-engineering terms. You basically want to get rid of two things: spiky noise in the elevation signal – say points in the datastream that look like they jump up and down for no good reason (but do so because some tiny atmospheric disturbance is messing up the signal of the GPS satellite a bit, or a cosmic ray that happens to impact a chip in your device, etc) – and secondly, slow drift in the signal. To understand where the latter may come from: imagine you’re riding on perfectly flat terrain, which means your total elevation gain should be zero – the sensor data may however still show small changes in elevation from point to point (because of subtle changes in air pressure due to weather conditions that confuse the barometric sensor, or because the circuit in your device is rounding off the numerical values and does so with small errors, etc), and when you add this all up, it gives a non-zero total.

An electrical engineer will say he has both high frequent (the spiky stuff) and low frequent noise (the slow drift) in the signal and he’ll want to get rid of it using a ‘bandpass filter’. The ‘band’ is the part of the signal that is of interest, which can be considered a meaningful measure for elevation changes, and all the rest is noise that needs to be filtered away. Our current algorithm (the exponential smoothing, basically a low-pass filter, followed by thresholding, which is a simple form of high-pass filter) is an implementation of this idea – by no means the best or most refined – but it seems to work well enough: in my experience from the last months (many tracks from a Garmin Edge 305 and 705), the totals calculated by the site match up with the ‘trusted’ totals displayed on the unit itself, mostly within a few percent.

Of course, for units that generate lower quality data (older, less accurate GPS receivers, no barometric sensors, etc) the simple filtering will not magically crank out the right answer, but I figure those who really care about things like how much altitude they’ve gained will get a better device eventually!

Here is a link to the script we use to process the GPX files – if you can run Ruby on your system, you can try it out for your self. The two parameters in our filter (RC constant = 40ft and threshold = 3ft) received values we found to work well but they can of course be played with…

January 2, 2010

Bye 2009, hi 2010

Filed under: General MTBGuru stuff,Riding and racing — mtbguru @ 10:44 am

A happy 2010 and new decade to everyone, and we wish you keep the passion burning, for whatever it is you have some! 2009 for me was a ‘grand cru’ year for riding: I think I rode more than I was hoping to, explored new places, as well as many familiar ones – with towards the end of the year a little reminder not ever to take things for granted. And we got plenty of inspiration by fantastic trips and rides I see posted on the site all the time (Plymmer’s unparallelled Coe explorations or Skyline35′s awesome photos and trip reports come to mind). Here’s twelve pics, one a month, to hand a proper farewell to the year.

January offered plenty of evidence of why it’s great living in the golden state: you could chose to go snowshoe or ski in the Sierras with your sweetheart, or ride some trails with her in balmy and sunny conditions.
Long Ridge, Saratoga

February was wet at times, but that’s what makes the abundance of rocky creek crossings and streams in Henry Coe interesting.
The hike-a-bike through the Narrows in Coe

Spring! That means: more Coe riding – we were able to enjoy and gawk at a spectacular display of wildflowers in March… and of course the riding rocks.
Hoover air strip in Coe

April is Fort Ord and Sea Otter classic time. I love this annual bike ‘circus’, and though I don’t venture out to the Fort that often, each time I look at the trails I see a lot worth loving!
Part of the Sea Otter Classic XC course in Fort Ord

My Moab-pilgrimage happened in May this year… I need this place, for spiritual renewal, or something. Or it could be for the incredible riding experiences, vistas, vibes, the overwhelming light and sound spectacle of a thundering desert storm (I hit quite a few of those this time around), and finally fulfill an old promise/resolution: ride the slickrock with my dad. Unfortunately in May there was also an immense loss – I didn’t know Anthony personally but had learned about Moab and was ‘primed’ to it, and many other places he visited and rode, through his lens.
Bar M and Circle O trails in Moab

I met new and awesome people in June – that’s what trail work days are really good for. Take Paul for instance, who devised this fantastic ‘devious’ Coe epic that I thoroughly enjoyed. The high lasted for days after!
Late spring ride in Coe, along some 'devious' trails

Summer time – this means Tahoe riding season, and the chunky granite goodness that comes with it. Magical moments in July, and we were delighted with the new (to us) stuff we were able to discover…
Rocky Tahoe goodness!

In August I tackled one of the challenges I set myself for the year: do a ‘hard’ (i.e. with ‘technical’ course) 100 mile endurance race. It was harder than I imagined and I found myself in strange places (physically and mentally), but that’s of course what makes it interesting and worthwile. Oh and the high afterwards, it lasts for weeks!

(photo credit: anonymous friendly trail runner from Bend)
During the inaugural High Cascades 100 in Bend, OR

The sunny season is winding down, summer travels are being wrapped up: this means Coe – scorched by the long hot days – comes back in my sight. I had signed up for a local race in September – the first one held here in ages – and to my own surprise won the sport class. Yay to yet another new experience, though I thought I’d gotten too old for that; I still think the rest of the field probably took a wrong turn somewhere…

(photo credit on this one: sir C. Kortman)
During the Henry Coe MTB challenge

October brought some new and needed rain to the Bay Area, enough to fill up China Hole in Coe and make it a crystal clear refuge from the occasional Indian summer heat…
Another magical Coe moment, in China Hole

A beautiful fall day in November was lit up by some improvised trail work and fun…
Pacheco Creek trail fun

Finally, December brought some injury and illness, enough to make me fully appreciate all the good days. And there were plenty this month too, in very magic places…

Nounou Ridge trail in Kauai

Cheers, and here’s to 2010, and the ‘tens’ (‘noughties’ sounded akward, seems it’s not improving much yet)!