GDL90 Ownship Geometric Altitude

[maehtricks]

First of all: thanks for your fantastic work.

I've noticed an issue with RC5 regarding GDL90 Ownship Geometric Altitude. With RC4 the altitude was shown correctly in SkyDemon, but with RC5 it's off.

GDL90 spec states that it has to be reported as relative to the WGS84 ellipsoid, with RC5 it looks like MSL alt is send.

• WebUI: 91m - correct alt
• XCSoar (FLARM): 138m - too high, looks like ellipsoidal height is send instead of MSL alt
• SkyDemon (GDL90): 130ft - too low, looks like MSL alt is send instead of ellipsoidal height

I'm using Prime MK2 Hardware.

[lyusupov]

Please, provide, being taken at earth surface level, screenshots (width <=800 pixels) of: 1) status page ; 2) settings page ; 3) 'monitor' window of XCSoar's device menu (in landscape mode) with at least one full second burst of GNSS NMEA sentences.

[maehtricks]

Alright, I did some testing this morning. My hardware is t22_v07.

I took screenshots from RC4 and RC5:

1. Status
2. Settings
3. SkyDemon (GDL90)
4. Avare external I/O plugin (GDL90)
5. XCSoar (NMEA)

RC4

status settings skydemon (alt in ft) avare xcsoar

RC5

status settings skydemon (alt in ft) avare xcsoar

[lyusupov]

Ok. Thank you!

Your report is a mix of two issues: 1) in both RC4 and RC5 there was a minor bug in GDL90 geometric altitude reporting. Fixed in https://github.com/lyusupov/SoftRF/commit/cf5d37eebaf47fbcfb1fa40dc7fb37fa9d81b3d0 2) you have so-called "heavy counterfeit" GNSS module soldered into your T-Beam.

Indicators of that:

and

Issue with these GNSS modules is that they always report "0.0" as a geoidal separation value. Recently it was first discovered and reported by Pawel Jalocha .

Most of modern GNSS ICs are reporting AMSL altitude in their NMEA $GxGGA sentence: http://aprs.gids.nl/nmea/#gga Followed by "geoidal separation value" - height difference between WGS84 ellipsoid and EGM96 geoid.

We don't know for sure what is the "altitude" value reported by this "heavy counterfeit" GNSS chip, but it looks like an altitude relative to WGS84 ellipsoid. Old GPSes (designed prior to year 2005 or so) were also reporting WGS84 altitude, but they were supplying EMPTY geo separation field.

This is an example for your location (latitude, longitude and altitude) taken from online calculator:

Your Input Coordinates and GPS Height: 

Latitude = 49.63° N = 49° 37' 48" N 
Longitude = 8.61° E = 8° 36' 36" E 
GPS ellipsoidal height = 142.0 (meters) 
Geoid height = 48.035 (meters) 
Orthometric height (height above EGM96 geoid which approximates mean sea level) = 93.965 (meters) 

(note: orthometric height = GPS ellipsoidal height - geoid height) 

RC5 has a workaround implemented against these "heavy counterfeit" ICs. The algorithm of EGM96 based altitude adjustment was borrowed from XCSoar. So reported SoftRF RC5 WebUI AMSL altitude should be the same or very close to the value taken from XCSoar's navbox. Due to flash memory space constraints, geo separation value is averaged over 2 degrees lat/lon "square" earth surface. Not perfect, but still acceptable for most aviation applications.

[lyusupov]

I am curious: 1) why are you using 868.2 MHz for P3I ?

have you read this ? : https://github.com/lyusupov/SoftRF/wiki/Settings

2) Which way did get your RC5? Custom built?

It should report more that 4000000 bytes on officially released RC5 running on T-Beam board.

[maehtricks]

Cool, thank you for the fix and the explanations. Is there a special setting to activate the altitude workaround in XCSoar? Right now it's showing the same alt (GPS ellipsoidal) in the alt gps box as in NMEA sentences with no correction.

1. I'm using the legacy protocol normally... so this was some weird setting from last night's testing.

2. I was experimenting as well with the GDL90 alt with my own build... but the screenshots were taken from the same source as your's. But you're right, with your build it shows more than 4000000 bytes. I'll have to check what's wrong with my setup.

[lyusupov]

Is there a special setting to activate the altitude workaround in XCSoar?

I don't know. My T-Beam v06 has "light counterfeit" GNSS module (a clone, but based on genuine Ublox 6-gen. chip)

This is how it works in XCSoar. It seems that there is an option to enforce it by "use_geoid" somehow.

I expect, it should work automatically. But you'd better ask XCSoar guys.

And this is SoftRF's RC5 stuff: https://github.com/lyusupov/SoftRF/commit/21098c66a5c8b9d25d74f2bd54fb4e6431686c29 https://github.com/lyusupov/SoftRF/commit/cd8480db1ce100ac918aa97c097200dbc34ed75e

I'll have to check what's wrong with my setup.

ESP32 source code build instructions are not up to date, see this ticket's comment. You should build against stable release of the Core.

[maehtricks]

Checked this... XCSoar's correction just kicks in if it's not a valid double value. Since 0.0 is valid, no correction will be performed. I saw this in the code and tested it by playing back a modified nmea caputure. If I remove 0.0 the proper altitude is shown.

Switched to the stable core release, but I had to enable PSRAM additionally. For your next gen build guide:

• Select Tools -> PSRAM -> Enabled

[lyusupov]

If you have nothing else to me related to the topic of the ticket - please, close it.

[maehtricks]

Checked GDL90 Ownship Geometric Altitude report successfully with SkyDemon + Avare.

Thank you very much.

[lyusupov]

@maehtricks

XCSoar's correction just kicks in if it's not a valid double value. Since 0.0 is valid, no correction will be performed. I saw this in the code and tested it by playing back a modified nmea caputure. If I remove 0.0 the proper altitude is shown.

Try out this commit: https://github.com/lyusupov/SoftRF/commit/0ef855703d8b2dc505cd97a5cafa68a85c581ebf

[maehtricks]

@maehtricks

XCSoar's correction just kicks in if it's not a valid double value. Since 0.0 is valid, no correction will be performed. I saw this in the code and tested it by playing back a modified nmea caputure. If I remove 0.0 the proper altitude is shown.

Try out this commit: 0ef8557

Works perfect. Thank you again :)

[lyusupov]

@maehtricks

Ok. Good !

Could you, please, take one more screenshot of NMEA sentences in XCSoar's "monitor" window (<=800px) ? I need to take a look at it.

[maehtricks]

Sorry for the delay... had some hardware issues. But here we go with BMP280 attached :)

[lyusupov]

@maehtricks:

Thank you!

I had to make sure that time/lat/lon of re-generated GGA sentence have same or close values & precision (digits after decimal point) as the parameters of pass-through RMC sentence.

[lyusupov]

Although GDL90 spec states that altitude has to be reported as relative to the WGS84 ellipsoid, most of EFBs and portable ADS-B devices are reporting MSL altitude. See this info for details: https://github.com/cyoung/stratux/pull/749 SkyDemon seems to be the only exception (SD is following the specs currently).

I am going to revert my previous change soon. I will sacrifice SkyDemon's altitude accuracy in favour of all other EFBs accuracy.

[maehtricks]

Hm, what do you think about adding it as option to be compatible to almost all EFBs on the market?

[lyusupov]

There is no sense to add the "GDL90 Alt."menu option for the sake of SkyDemon only. Those of SkyDemon users who fly in an areas where geoid separation value is significant (more than VDOP) can terminate GDL90 and operate with NMEA TCP ("AirConnect") connection method instead.

Alternatively, you can push SD team to use the MSL, like all other EFBs do.

[ragflyer]

Summary for other Skydemon users: In SoftRF settings set 'NMEA output' to 'TCP', then in SD settings menu -> Third party devices -> FLARM devices -> FLARM with Air COnnect to 'on', leave the key as is. Altitude should now be shown correctly.