Jump to content

Altimeter, why does it need to be Calibrated over and over again?


jlw82

Recommended Posts

If you believe Webster... Elevation in geographical terms is height relative to sea level. Altitude is more generic and can refer to sea level or the local surface.

 

http://www.merriam-webster.com/dictionary/elevation

1c : the height above the level of the sea.

 

http://www.merriam-webster.com/dictionary/altitude

1b : the vertical elevation of an object above a surface (as sea level or land) of a planet or natural satellite
Link to comment
If you believe Webster... Elevation in geographical terms is height relative to sea level.

 

http://www.merriam-webster.com/dictionary/altitude

1b : the vertical elevation of an object above a surface (as sea level or land) of a planet or natural satellite
To your first sentence, no, it's not - at least not all the time, as your 1b definition points out!

 

I believe it's that "1b" definition, with its two VERY different definitions built into one, that has one member's knickers in a twist. In the aero business, there's a whopping difference between ASL (above sea level) and AGL (above ground level) when this topic comes up. A cacher RARELY cares about the latter. Someone in an aircraft has to be exceptionally aware of it. There's a boatload of difference between "sea level or land"... unless the land happens to be at sea level, of course ;)

Edited by ecanderson
Link to comment
In the aero business, there's a whopping difference between ASL (above sea level) and AGL (above ground level) when this topic comes up.

 

Where are you using ASL in aviation? ICAO? In the US? We use MSL for pressure altitude, which is feet above Mean Sea Level. This is what's read on from the static part of the pitot/static system for airspeed and altitude. This altitude is pressure corrected in the cockpit according to a correction given from ATC or ATIS, unless above FL180 where it's always 29.92 inHG for uniformity. AGL is always the exact altitude above the point on the surface of the earth below the aircraft, as read by a radar altimeter (RADALT). It can be tierra firma or water.

Link to comment

Where are you using ASL in aviation? ICAO? In the US? We use MSL for pressure altitude, which is feet above Mean Sea Level.

Didn't want to further confuse the issue here as regards the definition of "sea level" (especially in Amsterdam!). Explaining MSL to most folks sounds totally bogus anyway since it is itself so variable, and is understood to be unknown with any accuracy except within a defined space -- so it really isn't a fair "mean". It's much better just to work with "above sea level" and let the definition of "sea level" left to another day -- it's completely irrelevant to the discussion of "elevation" ref GPS use.

 

...unless above FL180 where it's always 29.92 inHG for uniformity.
.. which is where most of my flying takes place, and would be the point where the distinction doesn't matter anyway. Always nice to know everybody agrees on something important to separation, yes?

 

Irrelevant in any case. As noted, the problem of the use of the word "elevation" was made clear by the previous post.. and others. We're dealing with terms that have more than one connotation depending upon the context. Consequently, there's no justification for beating anyone up about either use.

Link to comment

Where are you using ASL in aviation? ICAO? In the US? We use MSL for pressure altitude, which is feet above Mean Sea Level.

Didn't want to further confuse the issue here as regards the definition of "sea level" (especially in Amsterdam!). Explaining MSL to most folks sounds totally bogus anyway since it is itself so variable, and is understood to be unknown with any accuracy except within a defined space -- so it really isn't a fair "mean". It's much better just to work with "above sea level" and let the definition of "sea level" left to another day -- it's completely irrelevant to the discussion of "elevation" ref GPS use.

 

Do you fly in Amsterdam? What's that like?!?

 

MSL is used because there is no standard ASL for any given point. Latitude and tides change "sea level" all the time, so an average (mean) must be used.

 

You raised an interesting question, however. What "plane of reference" does GPS use to report elevation? Never really thought about it myself, since I've never used GPS elevation as sole "altitude" reference when flying, either civilian or in the military. In fact, I don't know anyone who does or if it's even FAR/ICAO legal. I'd think not.

Link to comment

Do you fly in Amsterdam? What's that like?!?

Nothing regular. Just in and out of there in August, though. It's strange to think about a runway below sea level is all. It's the only place I've had reason to experience that. Schiphol isn't anything out of the ordinary apart from that - unless you count a really weird piece of red and white art in the center of the passenger terminal <g>.

 

You raised an interesting question, however. What "plane of reference" does GPS use to report elevation? Never really thought about it myself, since I've never used GPS elevation as sole "altitude" reference when flying, either civilian or in the military. In fact, I don't know anyone who does or if it's even FAR/ICAO legal. I'd think not.
If you're asking what they're using when they use the satellite data instead of the baro sensor to create the numbers, those in common use will correct the altitude due to earth's somewhat non-spherical nature -- it has a little middle-aged "equatorial bulge" around the waist -- using the WGS84 model. That not only locks in latitude/longitude for all of us as a common datum (instead of dozens of them unique to each country or area), it assumes a specific model of the earth that takes the "bulge" into account, among other things. Local variations throw the ideal of a WGS84 shape for a loop, though, and is why a GPS has to take those into account also. Of some interest, it's WAAS (something some folks here don't think matters much, but I appreciate for the additional accuracy it provides in x and y) that provides the additional information in the z axis. Again, the z axis doesn't interest me much when I'm caching, but it is interesting to know it's there.

 

What I don't know is which WAAS capable units are actually taking the additional correction information into account when displaying altitude readings derived from satellite data.

 

As a result, the corrected projection of altitude is actually very close to MSL. I'm sure my Garmin Oregon 450 isn't certified for an IFR approach in the vertical, but I do know that there are some Garmin units that solve for altitude the requisite 5X per second that are. So it can be done, and the results must be pretty darned good.

Edited by ecanderson
Link to comment

I don't really want to pour petrol onto the fire, but when discussing reported GPS elevation, don't forget that the WGS84 specification has both a reference ellipsoid (which is a slightly flattened sphere), AND a reference gravitational equipotential surface (geoid) which sets local MSL above or below the reference ellipsoid.

 

See http://en.wikipedia.org/wiki/Geoid and http://upload.wikimedia.org/wikipedia/comm...6/Geoids_sm.jpg for a bit more information on the undulations of the geoid (surface of MSL) compared to the more simple ellipsoid.

 

I am 99% sure my Garmin Summit HC is programmed to report elevations against the geoid (i.e. elevation above or below local MSL), and it always shows an elevation of pretty close to 0 metres when I reach the coast on any of my travels (including Australia, South Pacific, Europe, South-East Asia, South America, etc).

 

I am 99% sure that my car SatNav (a cheap Chinese import) reports elevation against the ellipsoid. (Either that, or my car SatNav is using an incorrect geoid specification.) Here in south-east Queensland, it consistently shows elevation around 20 to 30 metres higher than standard topo charts, etc. Elevation above MSL is of no consequence for car navigation purposes, so it really doesn't natter that they don't seem to have programmed the geoid corrections into the unit. However, it means that while the reported elevation gain / loss is reasonably accurate, I can't easily correlate my car SatNav's reported elevation against detailed topo maps, elvation markers, etc.

Link to comment

I don't really want to pour petrol onto the fire, but when discussing reported GPS elevation, don't forget that the WGS84 specification has both a reference ellipsoid (which is a slightly flattened sphere), AND a reference gravitational equipotential surface (geoid) which sets local MSL above or below the reference ellipsoid.

Regarding the petrol, let's aim for 100 posts. :rolleyes:

Therefore, tell 'em about subtracting large numbers to get small differences........

Link to comment
...Schiphol isn't anything out of the ordinary apart from that - unless you count a really weird piece of red and white art in the center of the passenger terminal...
Don't forget the museum. And the meditation area.

 

And a weird budget hotel where you can get a sleeping room for your layover -- hardly bigger than a phone booth, with light switches that makes no sense to American or British travelers.

Edited by lee_rimar
Link to comment
...Schiphol isn't anything out of the ordinary apart from that - unless you count a really weird piece of red and white art in the center of the passenger terminal...
Don't forget the museum.
Yeah, like they need an annex. They can't get the original one rebuilt. Too bad, as the part that's open doesn't begin to fit the collection. Seems they keep running out of funds. Got an earful of politics from my driver on my last trip.
Link to comment
You raised an interesting question, however. What "plane of reference" does GPS use to report elevation? Never really thought about it myself, since I've never used GPS elevation as sole "altitude" reference when flying, either civilian or in the military. In fact, I don't know anyone who does or if it's even FAR/ICAO legal. I'd think not.
If you're asking what they're using when they use the satellite data instead of the baro sensor to create the numbers, those in common use will correct the altitude due to earth's somewhat non-spherical nature -- it has a little middle-aged "equatorial bulge" around the waist -- using the WGS84 model. That not only locks in latitude/longitude for all of us as a common datum (instead of dozens of them unique to each country or area), it assumes a specific model of the earth that takes the "bulge" into account, among other things. Local variations throw the ideal of a WGS84 shape for a loop, though, and is why a GPS has to take those into account also. Of some interest, it's WAAS (something some folks here don't think matters much, but I appreciate for the additional accuracy it provides in x and y) that provides the additional information in the z axis. Again, the z axis doesn't interest me much when I'm caching, but it is interesting to know it's there.

 

What I don't know is which WAAS capable units are actually taking the additional correction information into account when displaying altitude readings derived from satellite data.

 

As a result, the corrected projection of altitude is actually very close to MSL. I'm sure my Garmin Oregon 450 isn't certified for an IFR approach in the vertical, but I do know that there are some Garmin units that solve for altitude the requisite 5X per second that are. So it can be done, and the results must be pretty darned good.

Behind the scenes in the receiver, when the latitude, longitude, and height* are generated, the height starts out referenced to the WGS84 ellipsoid. Then for the user interface, a lookup table is used to apply a geoid offset to give MSL. That MSL height is what the barometer is calibrated to.

 

If you look at the NMEA $GPGGA definition, it gives the MSL height and the geoid separation that was used to calculate it. That way, you can back it out to the more mathematically pure ellipsoidal height and maybe apply a geoid model that works better for you than whatever the receiver is using.

 

WAAS doesn't really do anything specifically for height. It's just that the ionospheric corrections tend to give more improvement for vertical error than for horizontal.

 

I am 99% sure that my car SatNav (a cheap Chinese import) reports elevation against the ellipsoid. (Either that, or my car SatNav is using an incorrect geoid specification.) Here in south-east Queensland, it consistently shows elevation around 20 to 30 metres higher than standard topo charts, etc. Elevation above MSL is of no consequence for car navigation purposes, so it really doesn't natter that they don't seem to have programmed the geoid corrections into the unit. However, it means that while the reported elevation gain / loss is reasonably accurate, I can't easily correlate my car SatNav's reported elevation against detailed topo maps, elvation markers, etc.

Yeah, they probably just didn't bother. But this reminds me of a long time ago, figuring out that we had been applying the geoid separation with the wrong sign. The separation was small enough where we were developing that we hadn't noticed.

 

*I was joking in my earlier post about elevation being an angle. But seriously, since "elevation" is already being used in GPS receiver software to describe the angle of a satellite, it isn't usually used to describe the height. That would just be confusing. Mostly, GPS people just simply say "height", qualified with "MSL" or "ellipsoidal" (or "orthometric" when they're feeling fancy). I totally agree that jargon can mean something very specific to one user group and something very specifically different to another user group. That's why I just leave that up to people who do market-specific user interfaces. :rolleyes:

Link to comment

WAAS doesn't really do anything specifically for height. It's just that the ionospheric corrections tend to give more improvement for vertical error than for horizontal.

I've always been under the impression that local MSL tables were available from WAAS for units that didn't have the large internal tables necessary to avoid some interpolation error. Should have made it possible to get the added accuracy with a firmware upgrade. No?

 

Either way, what would be of interest is knowing which units have access (either internal or external) to the tables in order to provide the additional correction needed to bring the mathematical ideal more into line with reality.

Link to comment
Elevation on the GPS is height above the ellipsoid (that you have set in the setup) as stated above. Nothing more fancy than that.
At a minimum, certain Garmin units (e.g., the Garmin 430 and 530) absolutely do take the geoid correction into account (gotta, or they'd be useless for their intended purpose). Granted, both of these are gross overkill for geocaching, but there are no reasons that I can imagine that the requisite table data can't be involved in a handheld's computation of "altitude" as well. It is not a big calculational issue -- just a simple subtraction based upon a local data point, or at most, an interpolation of local data points. Even my little TomTom 740 automotive unit is running some 3rd party software (Off Road Navigator) that will, if so configured, subtract the geoid data to achieve the altitude solution.

 

Are you sure that a decent handheld isn't bothering with it? It can certainly make a whopping difference depending upon where you are.

 

Edit: interesting - as was pointed out above, there's some interesting information that appears in NMEA data. Where do you suppose that geoid data comes from?

 

 

$GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47  Where:	  
GGA		  Global Positioning System Fix Data
123519	   Fix taken at 12:35:19 UTC
4807.038,N   Latitude 48 deg 07.038' N
01131.000,E  Longitude 11 deg 31.000' E
1			Fix quality: 0 = invalid
					  1 = GPS fix (SPS)
					  2 = DGPS fix
					  3 = PPS fix
					  4 = Real Time Kinematic
					  5 = Float RTK
					  6 = estimated (dead reckoning) (2.3 feature)
					  7 = Manual input mode
					  8 = Simulation mode
08		   Number of satellites being tracked
0.9		  Horizontal dilution of position
545.4,M	  Altitude, Meters, above mean sea level
46.9,M	   Height of geoid (mean sea level) above WGS84 ellipsoid
(empty field) time in seconds since last DGPS update
(empty field) DGPS station ID number
*47		  the checksum data, always begins with * 

Edited by ecanderson
Link to comment

GPSlug said:

 

"But seriously, since "elevation" is already being used in GPS receiver software to describe the angle of a satellite, it isn't usually used to describe the height. That would just be confusing."

 

OK - now I'm confused! :blink:

On my Summit HC, the available altimeter data fields are called "Elevation"; "Height" is not one of the choices. The satellite page does not give me an option to view the satellite elevation and azimuth angles; all I can get is a crude "sky map" showing me roughly where the visible satellites are located.

 

As has been pointed out by others here, the term "elevation" means different things to different people in different contexts; however, plenty of people use "elevation" to mean:

 

"The elevation of a geographic location is its height above a fixed reference point, most commonly a reference geoid, a mathematical model of the Earth's sea level as an equipotential gravitational surface."

 

Ref: http://en.wikipedia.org/wiki/Elevation

(Yes, I know that Wikipedia is not the most authoritative reference, but it does indicate that this is in common usage!)

 

Red90 said:

 

"Elevation on the GPS is height above the ellipsoid (that you have set in the setup) as stated above. Nothing more fancy than that."

 

Not so - on my Summit HC, the elevation (i.e. "Height above MSL") is given above or below the geoid, not the ellipsoid.

Link to comment
(Yes, I know that Wikipedia is not the most authoritative reference, but it does indicate that this is in common usage!)

actually wikipedia is a pretty good source, as they're quite rigorous with demanding cited references for any statements that may be questionable or debatable. anyone familiar with how open source development works knows that the collective mind of the masses is quite a powerful tool. it's just people who disagree with something on wikipedia that try to use the "not a credible source" argument against it.

Link to comment

"Elevation on the GPS is height above the ellipsoid (that you have set in the setup) as stated above. Nothing more fancy than that."

 

Not so - on my Summit HC, the elevation (i.e. "Height above MSL") is given above or below the geoid, not the ellipsoid.

My impression as well given the NMEA data. The following makes it clear that the data is available:

 

46.9,M Height of geoid (mean sea level) above WGS84 ellipsoid

 

My only remaining question (per above) is how and from where that information was derived.

Link to comment

My only remaining question (per above) is how and from where that information was derived.

I believe it's programmed in as a look-up table; not sure of the resolution (possibly just 1 degree x 1 degree), but it just uses your current latitude / longitude to interpolate the local height of the geoid above / below the ellipsoid, and then uses that correction to adjust the reported elevation to be against local MSL.

 

Since consumer GPS elevation is only good to a couple of metres at best, you don't really need super-fine resolution of the Geoid correction data to get an acceptable correction.

Link to comment

My only remaining question (per above) is how and from where that information was derived.

I believe it's programmed in as a look-up table; not sure of the resolution (possibly just 1 degree x 1 degree), but it just uses your current latitude / longitude to interpolate the local height of the geoid above / below the ellipsoid, and then uses that correction to adjust the reported elevation to be against local MSL.

 

Since consumer GPS elevation is only good to a couple of metres at best, you don't really need super-fine resolution of the Geoid correction data to get an acceptable correction.

An EGM96 table that only resolved to 1 x 1 degree wouldn't be a heck of a lot of help out here where I live. We have these exceptionally large bumps just to the west <g>.

 

So no satellites actually supply the data? Especially as MSL is variable, you'd think that there would have to be a better source for "local" information than the static table, and that if it was a static table, it would have to resolve a heck of a lot better than 1 x 1 even for consumer units. The topography of the globe has some pretty extreme shifts over a degree.

Link to comment
...Schiphol isn't anything out of the ordinary apart from that - unless you count a really weird piece of red and white art in the center of the passenger terminal...
Don't forget the museum. And the meditation area.

 

And a weird budget hotel where you can get a sleeping room for your layover -- hardly bigger than a phone booth, with light switches that makes no sense to American or British travelers.

Did they ever raise enough money at Schiphol to put doors and “good buddy” dividers in the Men’s restrooms? Last time I was there you could still stand outside the restroom and look straight in to see everyone relieving themselves!

Link to comment

An EGM96 table that only resolved to 1 x 1 degree wouldn't be a heck of a lot of help out here where I live. We have these exceptionally large bumps just to the west

I don't now about the specifics of geoid fluctuations "out where you live" (Colorado), but here in Australia, the geoid to ellipsoid correction has a variation of around 5 to 10 metres or so for every 5 degrees change in latitude or longitude - see for example page 3 of http://www.ga.gov.au/image_cache/GA5175.pdf

The correction varies from about -31 metres in south-west Western Australia to about +61 metres at the northern tip of Cape York. As far as I can tell, it is not that different in the USA (even allowing for the "large bumps" a.k.a. "The Rockies") - e.g. see http://www.ngs.noaa.gov/GEOID/images/2009/geoid09conus.jpg

 

Given the inherent limitations of consumer GPS elevation accuracy (plus or minus 10 metres or so), recording the geoid corrections on a 1 degree x 1 degree grid and using interpolation for local correction would be well within the limitations of a consumer hand-held GPSr (in Australia, at least).

 

(You would need a more refined model for professional survey-accuracy GPS, but that is a different subject, I believe.)

Link to comment

Given the inherent limitations of consumer GPS elevation accuracy (plus or minus 10 metres or so), recording the geoid corrections on a 1 degree x 1 degree grid and using interpolation for local correction would be well within the limitations of a consumer hand-held GPSr (in Australia, at least).

Great map for Aus - first time I've seen that one. And from the looks of things, your issues are actually more pronounced over a smaller land area -- which is to say, you've got more slope in your deviation than we do.
Link to comment

Moderator's note

 

This thread is a train wreck. The totally off topic sniping at each other and general rudeness needs to be reeled in. As there actually is some valid discussion of technical merit (though increasingly unrelated to the original question) I'm not going to close the thread at this time. But please play nice.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...