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.

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

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.

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 quiteentertaining 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).

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!

A power sensor has always been on my gadget wish list, as a bona fide bike geek should. However, the prohibitive cost of such things and their non-portability has always kept it in quarantine there. Portability may not matter to some but it does a lot to me as I’d love to experiment with singlespeed vs geared, 26 vs 29, road vs mtb etc -and swapping wheels or crankset doesn’t really work here. Of course, the main requirements are accuracy and consistency – this means so far I’ve been stuck with the – non-portable – crank or hub option. I could give the iBike the benefit of the doubt (a device that basically measures wind speed and inclination and hence the power demand, in order to estimate the power put in), but it just doesn’t cut it for me (it may be great in conjunction with a second power sensor on the bike though).

What would work well for me is a sensor that can be either mounted (a) in the shoe (b) on the cleat or (c) in the pedal. And which produces an accurate and consistent signal, of course. I’ve been thinking about this for a long time and was about to embed some piezoresistors in a shoe or cleat myself, but it now seems a very promising effort is underway – and close to market. In fact, a number of such approaches have been tried out or are being developed; the late Microsport Technologies tried a sensor integrated in a shoe, the Brimm Brothers are working on a cleat sensor, but the Metrigear Vector, presented at the latest Interbike, looks now to be the first one to launch. It seems to be based on silicon piezoresistors (which I always thought would be better than traditional strain gauges, since they’re more sensitive and you can more easily measure the different components of the force vector), in conjunction with an accelerometer to measure cadence/crank position (the latter is an absolute requirement for pedal/cleat/shoe based sensors), and is integrated in the spindle of the pedals. Bikes and MEMS, right in my backyard!

Metrigear is also a local (to me) startup, and led by a guy that climbs Kennedy in 30 minutes flat – though he used a crossbike ; ) – so they must be serious about their cycling! The device is ANT+ compatible, so it will work with e.g. a Garmin 705 as head unit, it will come initially as a modified set of Speedplay pedals (mainly for road) but is promised to become available in different types later. Dan Connelly (from low key hillclimb fame) is doing a nice job in discussing the device in more depth and there is lots of chatter and talk about this on the Wattage Google/usenet group. There are still many questions, about the battery, durability, sealing, signal processing and availability etc but I’m for sure hoping this works as well as advertized!

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.

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

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

I wrote an article about how to use static page caching with Ruby on Rails. While this covers basics that have been covered many times before on other blogs and websites, it also explains why all parameter validation checking should be done before an action method is called, otherwise Bad Things Will Happen.

At the time, I didn’t know this, so I didn’t search for or stumble into articles that warned against this. Hopefully this is article will help prevent Rails beginners from running into the same problem.