| Versions |
  |
|
|
Note: You must be registered in order to post a reply.
To register, click here. Registration is FREE!
|
| T O P I C R E V I E W |
| rwcx183 |
Posted - 05 juin 2004 : 19:25:22
Translating WGS84 coordinates
Many GPS users may not be aware of a potential discrepancy between the altitude reported by their GPS and their actual altitude. GPS receivers calculate position first in a coordinate system known as ECEF XYZ. That just means Earth Centered Earth Fixed xyz. The WGS84 defined center of the earth is given the coordinates 0,0,0. The x-axis extends from that center, to a point at the equator where the longitude is 0 and of course, in the negative direction to a point at the equator where the longitude is 180 degrees. The y-axis extends from the origin at the center of the earth, to a point at the equator where the longitude is 90 degrees east (for the + direction) and longitude 90 degrees west (for the -direction). Lastly, the z-axis is the same as the earth's polar axis. That is, it extends to the north pole (+) and to the south pole (-). This is all fine and dandy, but if I gave you coordinates of a position in this coordinate system, few people would be able to tell even roughly where that was. We're all much more familiar with latitude, longitude and elevation. So usually, GPS manufacturers will translate the ECEF XYZ coordinates to lat/lon/elev coordinates that we can understand. For latitude and longitude, this is not so hard to convert for those of us that still remember high school geometry.
The trouble with altitude.
We have to make some assumptions about the shape of the earth. WGS84 has defined that shape to be an ellipsoid, with a major and minor axis. The particular dimensions chosen are only an approximation to the real shape. Ideally, such an ellipsoid would correspond precisely to "sealevel" everywhere in the world. As it turns out, there are very few places where the WGS84 ellipsoid definition coincides with sealevel. On average, the discrepancy is zero, but that doesn't help much when you're standing at the water's edge of an ocean beach and your GPS is reading -100ft below sealevel. The deviation can be as large as 300ft in some isolated locations. When the National Marine Electronics Association came up with the NMEA standard, they decreed that altitudes reported via NMEA protocol, shall be relative to mean (average) sea level. This posed a problem for GPS manufacturers. How to report altitudes relative to mean sea level, when they were only calculating altitude relative to the WGS84 ellipsoid. Ignoring the discrepancy wasn't likely to make GPS users very happy. As it happens, there is actually a model of the difference between the WGS84 ellipsoid and mean sea level. This involves harmonic expansions at the 360th order. It's a very good model, but rather unusable in a handheld device. It was determined that this model could be made into a fairly simple lookup table included in the GPS receiver. The table is usually fairly coarse lat/lon wise, but the ellipsoid to mean sea level variation, known as geoidal separation, varies slowly as you move in lat/lon. So, the GPS receiver calculates an ellipsoidal elevation and then applies an interpolated correction to that, from the lookup table and the result is reported via NMEA protocol. Additionally, NMEA allows the reporting of the geoidal separation, as a separate parameter, for folks that might want to do their own ellipsoidal to geoidal corrections. Simply adding the altitude above mean sea level reported, to the geoidal separation value reported, nets the original ellipsoidal altitude. From that point, the user (with lots of time on his hands) can re-calculate the altitude above mean sea level, using whatever model he wishes. Very few of us would ever do that, as the GPS receiver calculated and corrected altitudes are plenty good enough.
The trouble with SiRF - UPDATED 02/2006 : starting with V2.3.3 on SiRFII , V2.1.1 on XTrac, and V3.1.0 with SiRFstarIII, the Geoid separation is now reflected in GGA field 9 to show MSL altitude.
Enter SiRF. SiRF, until very recently, have not bothered to do the ellipsodal to mean sea level correction, to altitudes reported in NMEA protocol. SiRF admits that, so there's no controversy there. Eventually, SiRF got tired of listening to complaints about altitude discrepancy and they did finally release new firmware that includes the corrections from ellipsoidal to mean sea level altitudes. I don't remember exactly what version it occured on, but somewhere between 2.20 and 2.30 (ed #1 - 2.30 introduced that). If you have an older firmware, the reported altitudes will be ellipsoidal and you will probably notice that when you're standing on any ocean beach in North America, the displayed altitude is below sea level, since for the whole of North America, mean sea level is higher than the WGS84 ellipsoid. You can usually tell whether a GPS receiver is reporting true altitude above mean sea level, or ellipsoidal altitude by examining the NMEA sentences. Example:
$GPGGA,192435.716,3340.9130,N,11740.0502,W,2,08,1.2,211.6,M,-34.1,M,1.3,0000*46
The field immediately following the "M", specifies the geoidal separation value. If a GPS receiver is reporting a value there, then that usually indicates that the the field just before the "M" is the altitude above mean sea level. So, in this case, we're fine. (ed #2 - except that contrary to NMEA rules, SiRF receievers do not deduct the geoidal separaration to calculcate the msl)
Here's another example:
$GPGGA,161618.123,3343.5789,N,11747.9085,W,1,04,3.5,137.5,M,,M,,0000*5F
In this case, the field following the first "M" is null, indicating that the GPS receiver did not report geoidal separation, most likely because it did not know what the value was. So, we can assume that this GPS receiver is reporting ellipsoidal altitudes. Technically, that's in violation of the NMEA protocol, but it's a pretty minor violation.
There are of course, exceptions to the rule. Two that come to mind are, my old Lowrance GM100 (non-SiRF based)GPS receiver that calculated and reported altitudes above mean sea level, via some clever programming tricks, yet did not (could not) report a geoidal separation value. Then there was the newer SiRF based Lowrance iFinder, that managed to report the goeidal separation value, but still was reporting ellipsoidal altitudes. I guess SiRF and or Lowrance was a little confused on that version of firmware, since it was corrected in a later firmware release (see ed #2 - I suppose that the lowrance having another software layer unlike a standalone receiver like a Bluetooth GPS could fix the SiRF discrepancy)
SiRF binary mode notes
One final not here. In SiRF binary protocol, positions are reported exclusively in ECEF XYZ coordinates and it's the responsibility of whatever software you're using, to translate from ECEF XYZ to lat/lon and (we hope) altitude above mean sea level. SiRF did add conventional lat/lon/alt coordinate reporting via SiRF binary protocol (MSG ID 41), to the most recent firmware releases, but MSG ID 41 is not enabled by default. MSG ID 41 does supposedly report both ellipsoidal and altitude above mean sea level.
There is a similar story behind SiRF supporting magnetic variation reporting.
J.G.
|
| 15 L A T E S T R E P L I E S (Newest First) |
| mich_blogs |
Posted - 15 févr. 2012 : 05:07:18
Actually it looks like it is me that is confused there. If the geoid is above the ellipsoid then the
altitude is less than the calculated ellipsoid height.
So the GPS must be calculating a height relative to the satellites of 133, and then
taking off the 21 metres, and reporting an altitude of 112. Which seems to be in the right ballpark
according to the local topographic map.
For some reason, the application is adding them back together again and reporting 133 as the "altitude"
|
| mich_blogs |
Posted - 15 févr. 2012 : 04:57:46
I am still having trouble with this altitude issue.
When the GPGGA message contains " time longitude latitude blah blah altitude geoid separation "
and the altitude is 112 (metres) and the geoid separation is 21 (metres ),
then according to the explanation of how the GPGGA message is supposed to work, it should mean that
(a) the GPS device calculated an altitude relative to the ellipsoid of 91 metres ( which is not displayed )
(b) the GPS estimated the geoid offset using some polynomial or interpolated model
and came up with 21 metres ( which is more or less correct )
(c) the GPS added these together to get an altitude of 112 metres.
Is this supposedly the correct interpretation of this result ?
The problem comes when I connect the GPS to the laptop and run the MiniGPS application,
and it goes and adds the 112 metres to the 21 metres AGAIN and reports an altitude of 133 metres.
That seems like double counting to me.
|
| dfrqeo |
Posted - 11 févr. 2012 : 13:20:42
Hello,
quote:
Originally posted by gpspassion
No problem reactivating an old thread, on the contrary, best way not to have to start from scratch.
About GPS altitude reading and aviation use.
I'm now a retired pilot, and an active backpacker.
I have used aviation gps (Garmin 100 since 1992, King Kln 89 since 1999) and outdoor GPS (Garmin Vista C in 2005, Dakota 20 in 2011).
In my personnal experience, all those GPS are pretty accurate in reporting/displaying true altitude, with an error well below 50 ft provided there are no big obstacles limiting the "view" of the sky.
The problem is with the words "true altitude". True altitude is providing separation with the ground ... If the GPS reported altitude is - say - 8900 ft and the ridge you are flying over is at 8000 ft, then its ok to trust the GPS : you have a ground clearence of 900 ft (+ or - 50 ft).
This is much more reliable than the best aviation quality altimeter using current sea level pressure.
But, if you need a vertical separation from other airplanes, then, the GPS is not the tool for the job.
Quite simply, because other airplanes use theyr barometric altimeters, and those are subject to theyr own sytematic errors.
Two airplanes flying at 8000 and 9000 feet on theyr barometric altimeters might be actually at 7500 and 8500 ft true altitude, but they will still be separated by 1000 ft ...
More so if they are flying in the flight levels on 29.92 (or 1013).
|
| gpspassion |
Posted - 15 avr. 2010 : 01:06:32
Welcome to the forums.
No problem reactivating an old thread, on the contrary, best way not to have to start from scratch.
Don't have the Touch HD to check but I think I've seen it on other Qualcomm based smartphones, starting with the HTC Kaiser back in 2007. I'm not too surprised that there are few complaints as these devices are generally used for car use where altitude doesn't matter much (often isn't shown) and not so much for outdoor use where it does, which is probably just as well since they are not great performers and drain the battery very quickly, never pleasant but even worse so on a device you may need to use to make an emergency call.
Not the answer you were looking for, but I'd suggest using an external Bluetooth GPS, possibly wit a data logger, to get better performance and more battery life. |
| rpher |
Posted - 02 avr. 2010 : 12:54:03
I know I am opening an old thread here. Given that noone has touched it for 4 years I had assumed that the problems indicated had been resolved by now.
However I recently bought an HTC touch HD which uses Qualcomm GPSone GPS and discovered that the NMEA messages suffer from the problem outlined above, that is the GGA message field 11 is always 0 and field 9 gives the height above ellipsoid rather than above MSL.
I am surprised not to find others complaining about this.
Can other people in the forum confirm my findings for the HTC touch HD (and presumably other phones with the same chipset), to prove to me that my unit is behaving normally (if not correctly)?
Thanking you.
|
| sjnicholson |
Posted - 16 mars 2006 : 19:35:35
rwcx183 did a good job of explaining the ellipsoid and its relation to sea level. For those of us who learn best from pictures, there is a fair (I've seen better) depiction of the relationship at:www.ngs.noaa.gov. Click on "Geoid" under "Project & Division pages". The (U.S.)National Geodetic Survey develops new models of the Geoid about every three years, in part because the ellipsoid is influenced by gravity and the earth's magnetic core is dynamic, constantly changing. All GPS receivers compute Height Above Ellipse (HAE). Most have software/firmware that will calculate orthometric height (approximately Height above sea level) based on a model such as the ones developed by the NGS. The best receivers, such as those used by land surveyors, allow the user to upload different Geoid models to fit the applicaton or outcome the desire or when new models become available. An instructor at a workshop I attended likened geoid modeling to creating a mathematical model of a potato! It might never be perfect. |
| gpspassion |
Posted - 23 févr. 2006 : 00:08:17
This way http://www.gpspassion.com/forumsen/topic.asp?TOPIC_ID=37175
_________________________________________________________________________
Discounts and Assistance/Réductions et Assistance (Club GpsPasSion) / Où commencer? |
| frder |
Posted - 22 févr. 2006 : 22:41:42
Speed problem in NMEA mode in the royaltek firmware?
I did'nt notice any speed problem.
francesco
|
| gpspassion |
Posted - 22 févr. 2006 : 19:49:29
Good catch, I just noticed that myself yesterday on the RBT2010, it seems the Royaltek receivers have a specific 3.1 firmware (speed problem in NMEA mode as wellà, the Globalsat has that fixed.
_________________________________________________________________________
Discounts and Assistance/Réductions et Assistance (Club GpsPasSion) / Où commencer? |
| frder |
Posted - 22 févr. 2006 : 16:07:51
I'm confused, my rbt-2001 Sw version GSW3.1.1_3.1.00.07-C23B1.00 shows in GGA field 9 the ellipsoidal altidude and in GGA field 11 the value 0.0 (the correct value where I live is 45.6).
Is that SW version newer than V3.1.0?
francesco |
| gpspassion |
Posted - 17 févr. 2006 : 00:45:23
UPDATED 02/2006 : starting with V2.3.3 on SiRFII , V2.1.1 on XTrac, and V3.1.0 with SiRFstarIII, the Geoid separation is now reflected in GGA field 9 to show MSL altitude.
_________________________________________________________________________
Discounts and Assistance/Réductions et Assistance (Club GpsPasSion) / Où commencer? |
| DaleDe |
Posted - 15 déc. 2005 : 01:30:11
Oops I got the link wrong (need to learn how to do this correctly).
It should have been http://www.gpspassion.com/forumsen/topic.asp?TOPIC_ID=43272. |
| gpspassion |
Posted - 15 déc. 2005 : 01:28:20
No that's fine, forums offer this type of flexibility, most people just like to start new threads though, I'm happy when I see a new one coming back to life! You don't need to quote a thread above yours though, just type your text in the box of hit "Reply"
Yes, I did have these geo-stationary SBAS satellites in mind, but that's not the way the GPS sytem was designed so it's OT really, but one senses that having different ranges of altitudes would help with triangulation in the same way a horizontal distribution does.
_________________________________________________________________________
Discounts and Assistance/Réductions et Assistance (Club GpsPasSion) / Où commencer? |
| DaleDe |
Posted - 15 déc. 2005 : 01:21:16
Sorry, I hadn't check the date but I was following a more recent thread and 43472 http://www.gpspassion.com/fr/articles.asp?id=43472 that shows that GPS altitude cannot be trusted and it referenced this discussion. I hadn't realized that I have switched to a really old thread. I am not used to this discussion group. I will pay more attention. However the topic really pertains to the other thread so I will pursue it a bit more.
I do not see how altitude would change the DOP which is the dominant factor in predicting accuracy. It would however make the calculations a bit more difficult. Today all of the satellites are on then canopy surrounding the earth and the angles are all relative to this canopy. If there were different alitutudes of satellites it would make DOP a bit tougher to compute but not likely to change the outcome. It is DOP itself that predicts that vertical accuarcy is usually less.
By the way, if altitude of the satellites mattered then SBAS systems would get an added boost since they are twice as far out. I guess I need to move back to the original thread and leave this one alone.
Dale
quote:
Originally posted by gpspassion
Welcome to the forums.
Old message you've dug out there, I agree that my explanation lacked some detail and clarity, I do seem to remember I had the distibution/angles in mind. Giving it some more thought I'd say that the fact that the GPS satellites are all at an altitude of 20,000 kms doesn't help. If they were staged at different altitudes then it might be different with more triangulation "material" available.
_________________________________________________________________________
Discounts and Assistance/Réductions et Assistance (Club GpsPasSion) / Où commencer?
|
| gpspassion |
Posted - 15 déc. 2005 : 00:09:04
Welcome to the forums.
Old message you've dug out there, I agree that my explanation lacked some detail and clarity, I do seem to remember I had the distibution/angles in mind. Giving it some more thought I'd say that the fact that the GPS satellites are all at an altitude of 20,000 kms doesn't help. If they were staged at different altitudes then it might be different with more triangulation "material" available.
_________________________________________________________________________
Discounts and Assistance/Réductions et Assistance (Club GpsPasSion) / Où commencer? |
|
|
| This page was generated in 0,88 seconds. |
 |
|
- 
- 
