Altitude correction algorithm

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.

Hello,

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. :)

Menion

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.