Altitude calibration

I noticed that GPS shows way higher altitude then what is real.

That is because I often know exact altitude where I am standing, or simply I have Garmin GPS along and is shows altitude more correct. I am sure this is not problem in OruxMaps but generally with phone GPS.

Well, on my Garmin GPS I have an option to calibrate altitude by entering correct altitude on my standing point. After that GPS measures altitude more precise.

I searched all over the net and I could not find a way to do similar thing on Android phone. Is it really not possible?

pedja wrote:I noticed that GPS shows way higher altitude then what is real.

That is because I often know exact altitude where I am standing, or simply I have Garmin GPS along and is shows altitude more correct. I am sure this is not problem in OruxMaps but generally with phone GPS.

Well, on my Garmin GPS I have an option to calibrate altitude by entering correct altitude on my standing point. After that GPS measures altitude more precise.

I searched all over the net and I could not find a way to do similar thing on Android phone. Is it really not possible?

Hi, pedja;

May be your Garmin has a barometer to calculate the height. It is not normal for a gps correct the altitude by hand, because the direction of error is not known.

Maybe your problem is another:
The GPS gives the height above the GRS80 ellipsoid. To calculate the actual altitude over the geoid is necessary to correct the ellipsoid altitude. GPS usually have tables that can correct this value. This information is in the NMEA sentences. But Android informs to applications with the altitude above ellipsoide.

OruxMaps offers two options:
- Fix altitude manually (for androids < 2.0). The offset value is almost constant in the same zone, knowing the height of a point, one can calculate the value to use.
- Fix altitude reading the NMEA sentences automatically. Only available for Android > 2.0. OruxMaps extract that value from the NMEA sentences and applies it to the altitude.The problem is that there are several versions of android (2.3.x) where this does not work!

orux

I did not know that Android does have issues with geoid.

I saw an option for fix, but I understood that is for some special cases and as general fix. I have Android 2.1 so I guess fix by NMEA info should work. Anyways I will try to enter fixed correction to see if that would help.

Anyways, with Garmin (which does calculate height mixing info from satellites and barometer) I am acustomized to calibrate height whenever I can. Recalibration is simple - I just enter known exact height of current position. I think similar option should be available for OruxMaps users. They usually do not know about geoid, and how height is calculated. It is much simpler and user friendlier to just let them enter known height of current location and OruxMaps do the rest of the job.

orux wrote:...
Hi, pedja;

May be your Garmin has a barometer to calculate the height. It is not normal for a gps correct the altitude by hand, because the direction of error is not known.

Maybe your problem is another:
The GPS gives the height above the GRS80 ellipsoid. To calculate the actual altitude over the geoid is necessary to correct the ellipsoid altitude. GPS usually have tables that can correct this value. This information is in the NMEA sentences. But Android informs to applications with the altitude above ellipsoide.

OruxMaps offers two options:
- Fix altitude manually (for androids < 2.0). The offset value is almost constant in the same zone, knowing the height of a point, one can calculate the value to use.
- Fix altitude reading the NMEA sentences automatically. Only available for Android > 2.0. OruxMaps extract that value from the NMEA sentences and applies it to the altitude.The problem is that there are several versions of android (2.3.x) where this does not work!

orux

Hi Orux,

I have the same problem with my HD2 (and my Touch diamond before). It seems the geoid data is not transmitted in the NMEA sentence. For the time being, I have fixed the difference by looking up the geoid height in the http://earth-info.nga.mil/GandG/wgs84/gravitymod/wgs84_180/intptW.html WGS84 geoid calculator. But this is of course only valid for one place...

You could add the geoid calculation to Oruxmaps, so it works independently on the GPS capabilities (it seems more often than not this data is missing and few users understand how GPS altitude calculation works). I suggest you leave the internal correction on by default. The calculation of the geoid data is rather easy if you use the precalculated tables. For example a 0.5° table exists for the EGM84 geoid. You can use it straightforward via table lookup or a little bit more sophisticated as bilinear interpolation.
If you like, I can provide the code for this so you can paste it directly into Oruxmaps. This way, the recurring "GPS altitude" threads would be cut off once and for all...

- Martin

martin25 wrote:

orux wrote:...
Hi, pedja;

May be your Garmin has a barometer to calculate the height. It is not normal for a gps correct the altitude by hand, because the direction of error is not known.

Maybe your problem is another:
The GPS gives the height above the GRS80 ellipsoid. To calculate the actual altitude over the geoid is necessary to correct the ellipsoid altitude. GPS usually have tables that can correct this value. This information is in the NMEA sentences. But Android informs to applications with the altitude above ellipsoide.

OruxMaps offers two options:
- Fix altitude manually (for androids < 2.0). The offset value is almost constant in the same zone, knowing the height of a point, one can calculate the value to use.
- Fix altitude reading the NMEA sentences automatically. Only available for Android > 2.0. OruxMaps extract that value from the NMEA sentences and applies it to the altitude.The problem is that there are several versions of android (2.3.x) where this does not work!

orux

Hi Orux,

I have the same problem with my HD2 (and my Touch diamond before). It seems the geoid data is not transmitted in the NMEA sentence. For the time being, I have fixed the difference by looking up the geoid height in the http://earth-info.nga.mil/GandG/wgs84/gravitymod/wgs84_180/intptW.html WGS84 geoid calculator. But this is of course only valid for one place...

You could add the geoid calculation to Oruxmaps, so it works independently on the GPS capabilities (it seems more often than not this data is missing and few users understand how GPS altitude calculation works). I suggest you leave the internal correction on by default. The calculation of the geoid data is rather easy if you use the precalculated tables. For example a 0.5° table exists for the EGM84 geoid. You can use it straightforward via table lookup or a little bit more sophisticated as bilinear interpolation.
If you like, I can provide the code for this so you can paste it directly into Oruxmaps. This way, the recurring "GPS altitude" threads would be cut off once and for all...

- Martin

Thanks, martin;

it is a pity; because it was working fine with android previous to 2.3, and works fine with android 3.0 and 4.0
it seems that google does not want to solve the bug for 2.3x versions.

if you have the tables, may be I can add them to OruxMaps,

orux

Hi Orux,

interestingly, the "GPS Test" app does perform a geoid altitude correction and it works on my Android 2.3.7 version. So either
1. it has a different interface to the GPS, so the app can get the geoid correction or
2. the app has the geoid table built in.
Who knows?

Will send you the geoid table via email.

- Martin

martin25 wrote:Hi Orux,

interestingly, the "GPS Test" app does perform a geoid altitude correction and it works on my Android 2.3.7 version. So either
1. it has a different interface to the GPS, so the app can get the geoid correction or
2. the app has the geoid table built in.
Who knows?

Will send you the geoid table via email.

- Martin

Hi, martin;

last beta uses the table you sent me; thanks.

orux

orux wrote:...

Hi, martin;

last beta uses the table you sent me; thanks.

orux

Hi Orux,

tested it on my phone and it works!
Interestingly, if you search a bit, the missing geoid correction causes quite some confusion. I'v seen discussion threads where people are speculating about mismatched anntenas or other exotic causes. I did not know about the geoid correction before either, it's a rather exotic issue I think. Thanks for fixing this!

- Martin

Hi, thanks for the improvement on altitude calculation! I installed beta 4.7.12, does it include the new function? It isn't mentioned in release notes. If I want to use the lookup table, I just have to leave default option, NMEA correction disabled?

Also I found this website http://www.earthtools.org/ where I can see altitude at a given coordinate. Orux, did I understand your post correctly that I could manually set altitude correction in options with this information because the deviation changes very slowly and that would be good enough for a city? (Unfortunatley at the moment they only host altitude information of Europe and USA.)

It seems simply letting the NMEA correction enabled does the job.
The table used provides data in a 0.5° grid - this is about 50km. When you check the geoid values on
http://earth-info.nga.mil/GandG/wgs84/gravitymod/wgs84_180/intptW.html
you see that even over +-1° there is not much change (1-2m) on the geoid value. So a given correction value is probably good for a radius of a few 100 km (GPS altitude is not that correct anyway).

BTW you are mixing altitude with the geoid correction. The NMEA correction parameter is the difference between WGS84 ellipsoid and geoid value for a given coordinate, as the GPS calculates the altitude over the ellipsoid and you want to know the altitude over the geoid.

-Martin

martin25 wrote:It seems simply letting the NMEA correction enabled does the job.
The table used provides data in a 0.5° grid - this is about 50km. When you check the geoid values on
http://earth-info.nga.mil/GandG/wgs84/gravitymod/wgs84_180/intptW.html
you see that even over +-1° there is not much change (1-2m) on the geoid value. So a given correction value is probably good for a radius of a few 100 km (GPS altitude is not that correct anyway).

BTW you are mixing altitude with the geoid correction. The NMEA correction parameter is the difference between WGS84 ellipsoid and geoid value for a given coordinate, as the GPS calculates the altitude over the ellipsoid and you want to know the altitude over the geoid.

-Martin

Thanks for the explanation. I'm new to this and read a text about NMEA and geoid correction and maybe I was vague. I hope I understand correctly:
The wgs84 geoid is an approximation. NMEA gives you a value which is the difference between real measured altitude and w84 geoid.

So in the new beta Oruxmaps checks the Android version and uses the lookup table instead of NMEA when NMEA is enabled.

Please read this article http://www.esri.com/news/arcuser/0703/geoid1of3.html about GPS and the geoid. Wikipedia also has a number of articles on geoid, reference ellipsoid and such, but the esri article is much easier to understand.
GPS measures the altitude over the WGS84 ellipsoid. A map will show the altitude over the mean sea level, which is approximated by the geoid (egm84 or egm86 in case of WGS84). The correction simply is the difference between the WGS84 ellipsoid (coming from the GPS) and the mean sea level (approximated by the geoid).

- Martin

Thanks again for the link!

Hi!

I'm a bit of an intruder here, but I really mean no harm

I'm currently working on another Android application (called Gaggle) used by paraglider/hangglider pilots. The main issue that users are complaining about is this offset that Gaggle adds to the real altitude. After few searches, we understood that it was the lack of geoid correction that causes this offset.

I've looked at other softwares to see how they handle that, and as stated above, the use of NMEA (when correct) and embedding geoid data are the easiest solutions. I have the NMEA workaround ready but am afraid that it will fail to work on some devices (again, as stated above...). So i was also planning on having a second fix with geoid data in the app, in case NMEA fails. I would be very interested by your code martin25 if you are willing to contribute it to Gaggle. The software is GPL licensed, and the attributions would be set accordingly. If not, then, I'll recode it on my own

Anyway, thanks for the explanation here that were very helpful when I first started my searches

Marc

marc38 wrote:Hi!

have the NMEA workaround ready but am afraid that it will fail to work on some devices (again, as stated above...). So i was also planning on having a second fix with geoid data in the app, in case NMEA fails. I would be very interested by your code martin25 if you are willing to contribute it to Gaggle.

Marc

I did not provide any code, Orux does the programming. I only found the correction table. Anyway it is a simple table lookup. For a given coordinate value, you extract the offset from the table and add it to the uncorrected altitude. The only thing that can go wrong is that the GPS already has the correction applied, I assume. You can use a bilinear interpolation to improve table readout accuracy, but I doubt this is worth the effort.

- Martin

Oh, ok
Would it be possible to see which lookup table you found ? Is it directly the data provided by the original project ?
http://earth-info.nga.mil/GandG/wgs84/gravitymod/egm96/egm96.html
http://earth-info.nga.mil/GandG/wgs84/gravitymod/wgs84_180/wgs84_180.html

?

Marc

the geoid data I found is on http://geographiclib.sourceforge.net/ . Maybe you could use those functions directly, but actually access is very simple. I used the table in the section "Gridded geoid data"

http://geographiclib.sourceforge.net/html/geoid.html#geoidinst

# Geoid file in PGM format for the GeographicLib::Geoid class
# Description WGS84 EGM84, 30-minute grid
# URL http://earth-info.nga.mil/GandG/wgs84/gravitymod/wgs84_180/wgs84_180.html
# DateTime 2009-08-29 18:45:02
# MaxBilinearError 1.546
# RMSBilinearError 0.070
# MaxCubicError 0.274
# RMSCubicError 0.014
# Offset -108
# Scale 0.003
# Origin 90N 0E
# AREA_OR_POINT Point
# Vertical_Datum WGS84
720 361
65535

The table is the file egm84-30.pgm. At file offset 1A0, the 16 bit (MSB first) correction values are starting with 90°N, 0°E, in 0.5° increments. So for looking up 49°N, 8°E:
Offset = 0x1a0 + 2* (2* (90-lat)*720 + lon*2) = 0x1a0 + 2*(61920 + 16) = 0x1a0 + 123872 = 0x1e580. At this offset, the value in the file is 0xce3c.
Scaling by alt = val * 0.003 -108 m = 50.388 m.

http://earth-info.nga.mil/GandG/wgs84/gravitymod/wgs84_180/intptW.html gives 50.39m, so this is correct.

-Martin

Hello,

I've a THL W200 Android 4.2.1 phone and Orux reports always an altitude lower than the exact one (I know altitude of the site exactly). The geoid height in my country (Italy) is about +40m and I think my phone correctly reports in the Android API the altitude above sea level but Oruxmaps seems to subtracts for this value the 40m of the geoid heigh and than it reports the altitude value with the geoid height subtracted twice (one from Android, one from Orux).

Let me know.

Ciao, Marco.

MCE66 wrote:Hello,

I've a THL W200 Android 4.2.1 phone and Orux reports always an altitude lower than the exact one (I know altitude of the site exactly). The geoid height in my country (Italy) is about +40m and I think my phone correctly reports in the Android API the altitude above sea level but Oruxmaps seems to subtracts for this value the 40m of the geoid heigh and than it reports the altitude value with the geoid height subtracted twice (one from Android, one from Orux).

Let me know.

Ciao, Marco.

Hi;

Normally android returns the altitude above the ellipsoid.

There is a setting in configuration -- gps where you can choose to use or not use the correction on the geoid.


orux

Hello.

OK I found the config and it works fine (NMEA geoid correction = disabled). I'd just like you to note that the Android API specifies that locatio.getAltitude() should report altitude above sea level (i.e. above geoid), but I know that many implementation reports altitude above elipsoid.

Maybe this configuration should be better described in the Manual: I read the Italian one and I did not understood the reason of the NMEA geoid correction and the fact that select or unselect it depends on the own cellphone GPS implementation).

My best regards and thenks for this beautiful app.

Ciao, Marco.