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

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

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…

November 6, 2008

Surgery on the Garmin Edge 305

Filed under: Google Earth,GPS,Howtos / tips / tricks,Tech Corner — mtbguru @ 8:23 am

I’ve been using my Garmin Edge 305 for over two years and am pretty happy with it. Unfortunately though, it seems just like with many other electronic gadgets these days, two years is about the time at which things start to fail. One doesn’t have to be entirely paranoid to assume that they may be just designed that way. Anyways, the first symptom was the device randomly shutting off during bumpy sections on my road bike – looked like a case of ‘battery bounce’. This got gradually worse and worse, to the point at which the slightest bump on my (suspended) mountain bike would kill it; it just wasn’t usable anymore. The thing was long past warranty and I didn’t feel like forking out Garmin’s $100 flat rate for repair – so it was time for some surgery. It’s always fun to try fix things yourself.

A quick round of Googling showed that I wasn’t the only one with this problem, and soon I ran into this helpful thread on one of the Motionbased forums, from which I came up with this plan of attack:

Open up the device; the case consists of two halves which are glued together. You basically have to pry open the rear black section from the front section. Important: a rubber strip runs along the side of the device and covers the switches; it has been molded onto the gray front part and is to be permanently attached to it. The seam which has to be pried open is between the rubber strip and the black rear part, NOT between the rubber and the gray front part. You can use your nails or a spatula, see the picture below (all the photos below are linked to higher resolution images btw, click on them to see these).

Garmin Edge fix1
The adhesive will slowly come off (and make a bit of a mess), a gap will open up and at some point you’ll be able to lift the black cover off. As usual with these things, don’t force it or you may break stuff.

With some patience, you’ll be able to separate the two halves.
Edge fix2
The random shutdown problem is most likely caused by the spring connector (the 8 gold coated pins on the bottom left of the top part, which contact gold coated pads on the bottom part, see image below). When the device is closed up, the leads of the battery (in the top half) run through this connector to the GPS board in the bottom half; the other contacts of the connector contact the mini USB port. The little springs (see pic below) only create a good electrical contact if they’re sufficiently compressed. Edge fix10
And that’s the heart of the problem: the compression of the springs is determined by the gap between the two halfs. The contact pads on the bottom half sit on a small piece of PCB, onto which the external USB port is directly mounted (see pic).
Edge fix3
A spacer underneath the small PCB defines the gap (see the profile shot below) and it is the adhesive force of the glue that holds the two parts together.
Edge fix4
So, after numerous cycles of plugging in and out a USB cable and applying significant forces on this piece of PCB, it is not hard to imagine that it can get somewhat wedged loose over time and as a result the compression of the springs decreases or fluctuates, something which only will be aggravated when you have the device mounted on your handlebar during a bumpy ride. The intermittent contact then leads to the device shutting down.
Basically, it’s a design error with respect to strain relief and could have been avoided by not having the USB port directly mounted onto the piece with the contact pads for the springs.

In order to fix the problem and make the connector more robust for a hopefully long future use I decided to combine two fixes mentioned in the Motionbased forum thread: hardwire the battery leads to the GPS board, and add a spacer to the small PCB with the USB port.
First though, you want to properly clean all contacting surfaces to make sure there’s no dirt or other contamination creating trouble – you can use for instance DeoxIT contact cleaner for this – check out the macro-photo I took of the connector tips: it’s easy to see that some dirt on those tips can become an issue.
Detach the small PCB to expose the battery leads – it’s kept in place by two screws on the sides.
Next, solder a wire from each battery lead to the GPS board – this requires some care and a steady hand, but it isn’t that hard. A good type of wire to use here is magnet wire – thin, plastically deformable wire that has an insulating coating on it (and is typically used for coil spools). Because it keeps its shape when you deform it and the thin wire is very light, it won’t move around too much inside the device during use after you’ve closed it up again, and the solder joints shouldn’t come under any significant stress.
The picture below shows where I soldered the wires at the battery/USB connector side (and is also a testament of my sub-par but in this case sufficient soldering skills).

Soldering a wire from the battery leads to the board will pretty much eliminate the battery bounce effect during rides. But to ensure the contacts to the USB port (which you need to download data or recharge the battery) remain in good shape, the additional spacer comes in – this will basically compress the little springs a bit more and create a more robust electrical contact. I took a thin piece of rubber with adhesive on one side (the type you can buy to cut out for instance rubber feet to glue on small furniture or equipment) and cut out a piece that is pretty much identical in shape to the original spacer, then placed it on top of it.

Then put both spacers on the small PCB and screw it back in place. The picture below shows how it goes together. It also shows the contacts on the GPS board where you need to solder the other ends of the battery wires to (as always, be careful when doing this – you don’t want to smolder components or splash solder all over the place).
The trick then is to nicely wrap the extra wires you’ve put in there alongside the board in such way that you avoid them touching the spring connector or getting squeezed when you flip the two halves of the device back together. Practice this a few times, because in the final step you’ll need to do it with glue on the case.

When you feel comfortable with this, it’s time to put new adhesive on (of course, you’ve already scraped the old one off as well as you could). I used some ‘Black Max’ Loctite (see picture) that I applied on the edges of the black rear cover – this adhesive works well with rubber and plastic.

Move both parts now gently together, making sure the wires sit nicely in place and out of the way and being extra careful with the area that contains the spring connector. When the two parts are locked back together, put a weight on the device (see picture) and let the adhesive cure. You want to use this weight and apply a uniform force in order to minimize any gap between the two parts (remember this affects the spring compression and also the operation of the Start/Stop and Lap buttons).
Fifteen minutes later, take off the weight and power on the GPS! Check whether the USB port works as well (you could also do this before applying the adhesive by clamping the halves together and gently plugging in the USB cable in the port.
If all went well, it will stay on, including during the roughest bumpiest rides you can find. (If it doesn’t power on, not all is lost: go back to start – the Loctite adhesive is removable just like the original adhesive). I’ve done this fix a few months ago, and my Edge was working almost like new again – and as to date, it still is.

March 20, 2007

Mars on Earth

Filed under: Google Earth,GPS — mtbguru @ 2:42 pm

Shall we call this “In-flight Aerial Photo Geotagging”?
Or, how to make your boring ten hour transatlantic flight (slightly) more entertaining, using your GPS and camera.

Devon island

I was lucky to get a window seat on flight KL605 from Amsterdam to San Francisco, and that the weather over the Arctic was fairly clear that day. I had switched on my Garmin Edge 305 early on during the flight but didn’t get reception – two satellites and a reluctant third was all the GPS was seeing.

I tried again hours later, when I saw majestic glaciated fjords and cliffs tens of thousands of feet below me, and yes, this time I got decent reception, so I started tracking and taking photos.

Once home, I created this MTBGuru trip and started finding out what my photos were showing me, using the Google Earth file. Fascinating, the stuff you can learn this way: most of the photos below are of the south shore of Devon Island, Earth’s largest uninhabited island. Its coastline is characterized by steep glaciated cliffs, deep fjords and valleys. The main geographic feature of the island is the Haughton impact crater, in the west part of the island.

And, as the rocky polar desert around the Haughton crater is the closest thing on Earth to what most of the planet Mars looks like, it is also known as Mars on Earth and home of the Mars-Haughton scientific project…

Unfortunately I lost signal again, high above Canada’s Northwest Territories, but I did end up getting about a thousand miles worth of arctic GPS data!

Technorati Tags: , ,

March 6, 2007

GPX file Howtos

Filed under: GPS,Howtos / tips / tricks — mtbguru @ 1:36 am

A quick recap and list of useful links related to uploading and using GPX files on MTBGuru:

When you create trips on MTBGuru based on GPX files you’ve uploaded, the resulting trip pages may not always look the same:

  • We’re scanning the GPX file for tracks – lists of waypoints or routes are currently not supported. If the GPX file doesn’t contain at least one track, you won’t see a map on your trip page. Read more here

  • Most GPX files that originate from GPS units will contain elevation data, but this is not necessarily true – some GPS devices or software tools won’t save the elevation data in the file. Unless the latter is the case, you’ll see an elevation profile (elevation versus distance) on your trip page.

  • Not all GPX files will contain timing information – timing info is needed for the automatic photo geotagging to work, as well as to create the distance versus time and elevation versus time graphs. Most GPS units and loggers do allow you to save the timing info though, check your unit’s manual for more information or experiment with the settings.

More information and details on downloading GPX files from your GPS device are given in this blog post.

Alternatively, read this if you want to use GPX files you find on the site and upload them to your GPS to retrace the given trip.

Finally, here we describe how we treat multiple tracks in GPX files.

February 7, 2007

Navigadget blog

Filed under: GPS — mtbguru @ 10:43 pm

Navigadget is an interesting blog that I just discovered, on ‘GPS Navigation Technology’ and is featuring a lot of news on the latest and greatest GPS gadgets. There’s much more out there than Garmin, TomTom or Magellan, as you’ll find out…

January 29, 2007

Edge versus Vista (2)

Filed under: GPS — mtbguru @ 12:52 am

This is not a rematch, but some additional data highlighting the difference that the SiRFStar III chip (Edge) makes.

Previously, we noted that the accuracy of the Vista goes down significantly when under canopy or in narrow canyons, whereas the Edge was holding up very well. Most of the route in the previous test consisted of trails in open meadow land with some relatively short forested sections.

But when the trees are getting really dense, things become more pronounced. The Vista may start to lose signal – you’ll notice this when the track log is broken up in several sections. I took both units on another local ride (Alpine Road in Portola Valley to Skyline Blvd), this time mostly under dense canopy and/or skirting a fairly narrow canyon.

The first graph shows longitude versus latitude – the Edge recorded again a very clean track, whereas the spread on the Vista was large, and included several drops in signal. The route was done out-and-back.


The image below shows a section of the track recorded by the Edge, overlayed on a satellite image in Google maps on which the trail can be seen, hinting at the Edge’s accuracy. Of course, this isn’t saying much since this section of trail was obviously visible by a satellite (which would not be the case in really dense sections), but it does give an idea.

Alpine Rd

Interestingly, looking at cumulative distance over time (graph below), a lot of the spread in the signal is again averaged away, as mentioned in the earlier post. Except for the signal drops which may show up as small anomalies, the Vista produces pretty much the same data as the Edge. So even a GPS having crappy reception can still make a decent odometer… but not a good tracker.


January 28, 2007

Garmin updates: Training Center and the Superbowl

Filed under: GPS — mtbguru @ 10:08 am

Garmin Training Center for Mac OS X can now be downloaded from their site, and there is also an update for the Windows version. In related news, coming Superbowl weekend Garmin will be sporting a second-quarter ad, featuring – besides a muscular marketing budget – a battle between a ‘Maposaurus’ and the ‘Garmin Man’ – check it out on this Youtube preview on GPS Tracklog.

Our favorite Mac GPS tools remain GPSBabel+, LoadMyTracks and Routebuddy (the latter as soon as they’re supporting GPX), which all work or should work with Garmin devices, but it’s nice to see some progress from Garmin itself.

January 19, 2007

Edge versus Vista

Filed under: GPS — mtbguru @ 8:41 am

I recently did some field testing in order to compare my two GPS units, a Garmin Edge 305 and a Garmin Etrex Vista. Note that none of us at MTBGuru are affiliated with Garmin in any way, these just happen to be the units I own and generally like: the Edge is a good cycle computer, and with its SiRFstar III chip an excellent track logger. My Vista is a bit older, has a less sensitive GPS receiver chip and some other annoyances (such as dropping time info when saving tracks) but you’re able to upload topo maps which you can view on its big display, so for navigation the device is pretty good.

What did I want to find out? I already knew the Edge had much better reception under canopy, in wooded areas or narrow canyons. In these circumstances, the Vista would sometimes lose signal, with interrupted tracks as a result. The noise on measured latitude and longitude on the Vista is higher – how would the measured distances compare?
I was also interested in how the two altimeters would compare. Both units have a barometric altimeter. The Vista’s altimeter can be used in two modes: ‘auto-calibration’ on or off. When on, this auto-calibration uses elevation data based on the GPS signal to periodically recalibrate the sensor (about every 15 minutes). When off, it’s the barometer only that produces the elevation measurement.
In addition to this, you can also manually calibrate the altimeter (useful if you know the altitude at which you’re at). The Edge on the other hand features a barometric altimeter that is quasi-continuously being recalibrated based on its GPS-signal.

So I went for a ride with the two devices, up in the Santa Cruz mountains. From the Russian Ridge parking lot on I started logging, and headed up to Borel Hill:

borel hill

I hadn’t used or calibrated the Vista’s altimeter in a while and it was initially quite out of whack (about 400 feet).
At the summit of Borel Hill, 2572 feet high, I manually recalibrated the Vista and set ‘auto-calibration’ to off. In the meantime, the Edge was giving me the right altitude within 10 feet.


The graph above shows the raw elevation data from both units over the whole ride; the interesting part is that after being recalibrated on Borel Hill, the Vista’s barometric altimeter (without GPS ‘auto-calibration’) tracks the altimeter from the Edge almost perfectly. This is not too surprising: though they are in absolute terms not very accurate and require frequent recalibration, altimeters have very good relative accuracy and over a time frame of a few hours won’t drift much. A weather front that suddenly moves in is about the only thing I could think of that would knock it off quickly – otherwise baseline drift is a very slow effect. And I have actually still to experience any such effects attributed to fast-moving weather fronts; but then I live in an area where we don’t see much of these.

On the ride, I repeated the same section of trail multiple times – I did the same descent and climb three times, as an out-and-back. The graph below (a blow-up of the first graph) illustrates this:


The red dotted line connects points that represent one single spot: the top of the climb. The extra bump on the second peak is to be ignored, as I climbed there a bit higher to a ridge to take a break. At the third peak I took another quick break and played a bit with the controls of the Vista – that may explain the weird little dip in its signal. But as you can see, drift over the course of about an hour is minimal (less than 10 feet), and consistency of the data is quite good. Only at the third repetition of the climb, a slight deviation between the two units can be observed.

So concerning elevation, the two units aren’t very different. The Edge’s altimeter is just much more convenient because you don’t need to recalibrate – the ‘quasi-continuous’ automatic recalibration seems to work well due to its very accurate GPS signal. I used the Vista here with ‘auto-calibration’ off, because I wanted to rule out sudden shifts that would occur every 15 minutes. On another occasion, I’ll look at the effect of the latter. I will also keep the discussion on cumulative elevation gain and loss numbers for later – these are a function of the noise of the sensor and the filtering applied.
Other interesting data to look at would be the pure GPS elevation data but neither of these two devices allow extraction of such data (I’d need an Edge 205 or Etrex Legend which don’t feature a barometer to obtain this).

The difference in accuracy of the GPS-signal between the two units can be easily observed by plotting out latitude and longitude against each other (figure below) – this is the same descent+climb repeated three times as in the previous figure:

EdgeVista lat long

The graphs plotted here consist of an overlay of six times the same track segment (three times down and three times up). The spread on the Vista’s signal is clearly larger than the Edge’s, in particular around the area on the right, indicated by the red dotted circle, which was a section of trail under fairly dense canopy. Note that the Vista did not lose signal here – in other conditions where it would do that, the signal would of course be messed up even more as a number of points would be missing.

How does this translate into distance? In a way, distance is ‘cumulative location’; you’d expect that things will average out a bit, and indeed, if you plot distance versus time for the same 3x repeated track segment, you’ll see the Vista and Edge returning roughly the same graphs:


The slope of this curve is of course the speed, and you can quickly identify the descents, climbs and breaks. Distance is calculated from latitude and longitude using the great circle distance formula as mentioned in another post.

In conclusion, both devices are about equally good in generating elevation and distance data (with the Vista having a calibration issue), but for logging tracks the Edge’s SiRFstar III chip is quite superior. Another unit, the GPSMAP 60Cx seems to combine the best of both worlds, but it comes at a higher price, and in a bulkier package.

Next Page »