Altimeter cyclecomp/GPS?
 

A while back I had a few watches that had an altimeter in them. Not 100% accurate, of course, but gave me a good idea of the climbing I did. One of them lasted less than 2 months, so I'm not bothering with those anymore. The cyclecomputers on a couple of my bikes just went, so I'm thinking about getting something with an altimeter. Not sure I want a pure GPS device, as I'm no techie. (Do those things have the usual ave. speed/ride time/distance functions?) I'm not interested in paring it with a smartphone, as I know I'll have all sorts of problems getting it to work. Are there any simple to use cyclecomps with an altimeter?

I have a Bontrager Node 2 that has a barometric altimeter.

It's expensive for a cycle computer but I like it.

I don't know if the current Bontrager computers have barometers.

Most of the Garmin Edges from the 520 up have barometric altimeters. I'd think most other manufacturers of cycling computers/gps intended for cyclist wanting metrics data will have models with barometric sensors too.

They aren't 100% either. But they give some useful data when it's all taken relative to a bunch of rides.

300 feet is close to noise. I suspect steeper/longer climbs make the number more accurate.

Hopefully, cyclists aren't too concerned about logging 300 foot rides.

RWGPS and others use the same elevation database. The resolution of that database is fairly low, which means it can miss climbs that cyclists care about. That is, the database numbers will tend to be lower than the real number.

It seems many people think it's as accurate as horizontal distance. It isn't.

IME, accuracy of the three altitude/climb measurement techniques:

1. GPS satellite-only. Climb up a narrow gorge with trees, satellites dropping out because of rock walls or trees, or bogus satellite multi-path signals (bouncing off the other side of the gorge). "What? accuracy?"

2. GPS plus topographic maps. Sometimes fairly decent, sometimes laughable. My favorite was a climb where the mapping software tried to interpolate between contour lines, with the result that a 1,200' climb registered as 2,700'. The road followed an old logging railroad line, so it was a consistent 2-3% grade most of the way. The elevation plot that thing put out looked more like the logging saw than the railroad elevation.

3. Good barometric altimeter, as long as there's no weather front moving through. I've consistently gotten within 5-10' of the surveyed elevation difference between a gap and a crest on the Blue Ridge Parkway, for instance, with 1,000-3,000' climbs. (I don't know any other route that so consistently has elevation signs for every gap and overlook!)

​​​Whatever was being done in this case, it doesn't sound like interpolation.

It's interpolation of elevation from interpolation of two-dimensional (i.e., xy) location. This may be way off topic, but it's at least tangentially related as it explains why mapping solutions are sometimes erratic.

The program figures out where the road is going, and follows the road path. For every interval (for example, every 50 feet of road distance), you figure out the lat/lon or x/y location of the road. Then you figure out, for that point, what's the elevation. Say the road is climbing the side of a mountain, and goes over a gully. The topo lines are the parentheses in this ASCII art, and the vertical bar is the line, and downhill is to the left:
)|)
At the bottom of that segment, the road is halfway between two topo lines (call them 1150' and 1200'). The mapping program will calculate the elevation to be 1175'. Halfway up that segment, the program calculates that the road is 20% of the way from the 1150' elevation to the 1200' elevation, so it says the road dropped to 1160'. Up at the top of the segment, you're back up to 1175', halfway between the two contour lines. You may have actually climbed 5' in 100' of road travel, but the simplistic mapping program will calculate you've descended 15' and ascended 15' -- three times your actual climb!

You can see that you'll get a similar over-calculation if you through a cut around the edge of a ridge. ASCII art for this is: (|(

Better programming will filter these results - most of the time. I suspect some of the programs and web sites have inserted highway department data to correct many widely traveled roads. Still, I treat mapping programs' calculations with suspicion.

Seems like an odd approach.

It would seem easier and faster (and less erratic; maybe, more accurate, on average) to just use the topo lines where the topo lines cross the road.

I've been using a Garmin watch with a barometer for years. Did a ride up Washington Pass with 3,500 feet of vert according to the topographic maps. My altimeter had a total error of 13 feet. I'm with you, this stuff can work amazingly well.

​​​​​​It's actually improved quite a bit. I'm not able to calculate total cumulative gain using GPS numbers because that's not how things are programmed. But I have a page set up with the GPS altitude and the barometric altitude, they're always very close (as long as I've calibrated the barometer).

Topo lines are going to miss a lot of elevation changes that your device with barometric sensor will record and accumulate. Topo lines at best are going to have a 10 foot vertical spacing. So it's possible to go up and down many times between them.

Most of the Garmin Edges with barometric altimeter are supposed to be able to resolve two feet of difference. So in the right terrain, I could have a gain loss of hundreds of feet and never cross a topo line.

The interval of contour maps as well as the resolution of elevation information in map database will always make comparing device information to map derived gain/loss the same as comparing apples to oranges.

... unless you do a ride that's entirely up or down, even for a portion.