This object is in archive! 

Altitude correction algorithm

Skully Fox shared this question 3 years ago


I understood Locusmap 'automatic altitude correction' uses EGM96-30 geoid model file.

With NMEA logger application, I can see $GPGGA sentense - MSL(mean sea level) height anad Geoid separation.

For example, MSL height (100m) ,Geoid separation (20m) and EGM96-30 (15m)

without any altitude correction, Locusmap presents altitude as 120m (MSL+Geoid)

and with auto altitude correction, Locusmap presents altitude (105m) <-- (MSL+ Geoid - EGM96. ie, Ellipsoidal height minus EGM96 value)

But Geoid separation in the $GPGGA is incorrect value. then why use this value for calculating ellipsoidal height and correcting altitude with EGM96 ?

What is the difference and why?

A. Just use $GPGGA MSL value

B. MSL + Geoid - EGM96 (Locus automatic altitude correction)

Have a nice day.

Replies (1)


Hello Skully

I had to read carefully code I wrote a really long time ago to again understand what I did.

Why these methods exist? Most users probably don't care. Automatic correction should give results with good enough precision. Before automatic offset existed, there was the only option: using NMEA messages that deliver offset of the geoid to reference WGS84 ellipsoid. You write that these values are incorrect. Why this?

Anyway, you bring me the idea to remove "NMEA correction". I'll measure its usage and check if it's adept to remove.

Did I answer your questions?



Hi, Menion.

No-correction-checked height in Locusmap is ellipsoidal height? Is that right?

and that value came from $GPGGA sentence (MSL height plus Geoid separation height)

Is that right too?

But Geoid value from $GPGGA was different with many different devices (smartphone or external

bluetooth gnss receivers). and Its value was inaccurate than derived from EGM96 or EGM2008

grid. So Non-corrected ellipsoidal height is inaccurate value.

I think that's the reason why automatic correction exists.

And automatic-corrected-orthometric height (=MSL height) is very accurate in reallity.

At this, Irony Occurs. Because

MSL height in $GPGGA ---> 1

Geoid height in $GPGGA ---> 2 (inaccurate value)

Geoid height in EGM96 ---> 3

1 => accurate

1+2=> inaccurate (No altitude correction)

1+2-3 => accurate? (Automatic correction)

Below, Locusmap manual states NMEA correction is unreliable too.

If geoid value in $GPGGA is accurate like EGM96 or EGM2008 with some device,

NMEA correction will be good.




height from GPS is always related to WGS 84 ellipsoid, this is how the global position system works. It's on application to fix these measurements to the local used system (in most cases to geoid). Same with altitude value from NMEA message. How is anyway computed supplied geoid height in NMEA? I have no idea.

NMEA correction is marked as "not reliable" also because some defined reported NMEA messages without geoid correction (was "0"). Anyway, it is a long history. I wrote this part of code more than 5 years ago, maybe more, so I do not exactly remember real reasons.

Anyway summary: if automatic correction (so measured ellipsoid altitude + correction over EGM96 model) gives you correctly values, then there is nothing more to do. I only added a small internal log to check how many people use old NMEA based system and most probably in one of the future versions, I'll remove it completely.


Good day, Menion.

I wonder whether smartphone take 'ellipsoid height' or 'MSL height' from satellite.

That's my keypoint of question.

Because 'MSL height' and 'geoid height' is specified seperately at $GPGGA sentence.

I thought 'geoid height' at $GPGGA came from satellite signal for these days, but

many people said it's from device built-in data (It's not EGM96 file of

Locusmap) So, geoid value of $GPGGA is different with various devices.

If smartphone receive 'ellipsoidal height' from gps signal first, and devide it to MSL and geoid,

then everything will be clear. But who knows about this ..

Now, automatic correction of Locusmap works fine, and accuracy is good enough.

It's not complaint about app, Just my curiosity about 'what altitude' smartphone receive from

satellite. Or before $GPGGA created, more raw data exists? :)


Hello Skully

these are interesting question on which I, unfortunately, do not know exact answers. They are more related to precise knowledge what happens under the hood in Android system.

Anyway my few thoughts:

- MSL height and geoid height are from my point of view exactly the same terms

- all devices using GPS system receive as default ellipsoidical height because this is height GPS work with

- from where comes geoid offset is a good question. But more logical to me is that this value is generated on the device itself after raw GPS data are received. :)



Upper comment, geoid height is geoid separation. sorry.

Anyway, conclusion is that smartphone receives ellipsoidal height from satellite (Not MSL height)...

It's still curious how smartphone get geoidal separation (gps circuit or android filesystem)

But It's ok. Thank you for good answer, Menion.

Replies have been locked on this page!