Recently, I get a Emtac Bluetooth GPS receiver, and I’ve been using it with both my laptop and smartphone. So far it’s been great, and I’m amazed at its horizontal resolution. This is my first GPS device, so the fact that such a device can show me not only the street I’m on, but which side of it I’m standing on is mind-blowing to me.
Vertically, however, it’s a bit odd. I know that altitude is trickier for GPS devices, and that it’s the direction more prone to error. And my position does wander in that direction a good bit when I have a shaky satellite fix. But more often than not, I get a good, stable altitude reading that only wanders a few meters.
The real issue with that altitude is that the stable reading it likes to settle on is consistently about 100 ft lower than what I see on topographic maps. My house, for example, is at an altitude of 940 feet. But my receiver likes to settle on number in the area of 840-850 feet. The same behavior ocurrs in a half-dozen other locations I’ve been able to compare.
Why would my readings be so consistently wrong, by the same amount, in the same direction? You’d think if it were going to have that kind of precision, it would be accurate, as well.
A couple of things are going on. First, the vertical accuracy of GPS is not as good as the horizontal accuracy - it’s a matter of geometry, and the fact that you are likely to have satellites on either side of you (or front-and-back), but satellites only above you. In GPS-speak, your vertical “dilution of precision” (VDOP) is a greater value than your horizontal DOP. Second, and more importantly, it’s likely that your GPS unit is giving you an altitude estimate with respect to an ellipsoidal approximation of the earth, and not to local sea-level. Again, in GPS-speak this would be your height w.r.t. the WGS-84 ellipsoid. You can find more about this by google-searching terms like “GPS” “alititude” and “WGS84” - but here are a couple of websites that might explain things too: one and two. Or, shoot back here if there’s anything else.
I assume missed a “not” in your second sentence: “…and the fact that you are likely to have satellites on either side of you (or front-and-back), but satellites only above you.”?
Second - I re-read the paragraph, and it should stand at typed. Picture a hemisphere above you - this is the sky. Now sprinkle some GPS satellites randomly across the hemisphere (notice that there are no satellites below the horizon). The way GPS works is that you get a distance estimate to each satellite in view; by intersecting the radii from the satellites, you arrive at an estimate for your position (plus your local clock offset, but that’s not important now). Because you only have satellites above you (but not below you) whereas you have satellites on all sides (again, on average), you don’t have as much information with which to estimate height as you do to estimate horizontal location. Your VDOP is usually on the order of 1.5x the HDOP. Good questions & hope that helps.
As Schuyler said, the datum you are using is most likely the problem. Some GPS units are clever enough to apply a transform from the WGS84 geoid to the local sea level - at least here in the UK, if you switch to the UK Ordnance Survey grid then most units will also convert to height above local sea level. I’m not sure what the relevant map datums are elsewhere in the world.
As I said in my OP, I realize that my VDOP is destined to be higher because of the way GPS works. I’m not expecting miracles of precision. But I’d expect all the wrong altitude readings to average around the right value.
However, I see know that the datum issue seems like the logical cause of my problem. Unfortunately I don’t believe there’s anything I can do in my receiver or the software I’m using to make the proper correction.
In any case, thanks to Schuyler and everyone else for the help.
Okay, I may have to retract that last post. It appears that my receiver is quite aware of the local variation between the WGS84 ellipsoid and the geoid. In the NMEA data (GPGGA), I’m getting a consistent height-above-geoid of -33.5 m at my house. So even with this correction presumably applied, I come up consistently short. Interestingly, and probably coincidentally, I’d be almost perfectly on target if it weren’t making that correction.
So now I’m back to being bothered by consistent, but wrong results. I feel like I’ve got enough precision in altitude to make me happy, but poor accuracy.
Also keep in mind that in the old days, measurements of altitude any significant distance from a coast were made with essentially a mercury barometer, and there was no reliable way to compensate for variations due to weather systems.
A lot of these measurements made it into bechmark data, etc. and some is still floating about. Altitude of various peaks, for example, have traditionally accepted values, and modern “accurate” values.
Basically, nobody wants to know that the nth step (I forget which one it is supposed to be) of the state capital in Denver isn’t actually 5280’ MSL. “The somewhere near a mile high city” just doesn’t have the same ring to it.
This is why a lot of outdoor recreation units come with a barometric altimeter built in. It will generally be more accurate than GPS based altitude readings, both in a relative sense to your starting point, and an absolute sense, provided you calibrate the thing to a known benchmark when you turn it on. For street navigation, altitude simply isn’t very important anyway.
A gps unit needs 4 sat’s to get a altitude reading. If the signal is ‘shaky’, you might be only using 3 to get a lock, which is also called a 2D lock (sort of using the distance to the center of the earth as the 4th ‘sat’). The GPS will assume a altitude, so it’s not going to change much, if at all. If you do have a good lock on 4 sat’s then the altudute reading should be ‘better’.
Maybe. But it ain’t true anymore. If you’re willing to spend the dime - and the time - you can consistently get sub-foot horizontal accuracy now. You just need to take a higher number of readings at each position of interest. Of course, this assumes you’re in an area where you can hit enough satellites, too. And are within range of at least three Continuously Operating Reference Stations (CORS).
GPS was initially emplyed with intentional error, (Selective Availability) but which allowed full accuracy by cryptographic means available only to military users. The system has been “open” will full accuracy available to all users for the last several years…memory working here: This was done under a presidential directive issued by Bill Clinton, but didn’t actually happen before he left office IIRC.
SA was made largely moot by WAAS (Wide are augmentation system) which corrected the SA errors in areas of navigational significance (ports, airports, etc).
Selective Availability was a mechanism that added short-term noise to the satellite clock, which effectively introduced a non-deterministic (to non-military users) error in the GPS pseudorange measurement. WAAS is a method of providing a correction to the pseudorange depending on the user’s location (and which satellites are being used), and is primarily to remove ionospheric errors. The time constants in WAAS corrections are longer than the rates of SA clock drift, so WAAS would not have helped SA (LAAS is a different story, but also a different question). In quiet ionospheric conditions, WAAS won’t help much, since your position estimate will already be pretty good - but WAAS isn’t meant to make things go from “pretty good” to “really good”, it’s to give aviation users an idea of how large their position errors might be, and which satellites (if any) to exclude from their solution.
I think I may have answered my own question. As it turns out, the geoid height I metioned above isn’t coincidental at all.
My receiver uses a SiRF II chipset, which seems to have deliver its NMEA data in a non-standard way. As I mentioned, the GPGGA sentence delivered by my receiver includes a value in the “geoid height” field. That’s all well and good, but the NMEA standard expects that this should be accompnaied by an altitude value that is already corrected by this amount. So in my case, the receiver should be sending a value of 940 ft, which is already corrected, along with a value of -110 ft which is nothing but some extra information in case you want to go back and figure the height above the WGS84 ellipsoid.
But my receiver, instead, sends the uncorrected value of 830 ft, and the “geoid height” field then becomes necessary for divining the truth. I discovered this because I found a trial of some Smartphone GPS software which is aware of the issue, and allows to user to apply the proper correction to SiRF chipsets. Most software, however, assumes that the data will come in a standard form, with the altitude already corrected.
This is actualy common complaint about this chipset from the hardcore GPS geeks out there. So there’s enough information available to make me confident that this is what I’m experiencing. I was able to find this through dome diligent web searching, but I couldn’t have done it without the links posted by Schuyler, which pointed me in the right direction. So thanks again!