GDL90 Ownship Geometric Altitude about softrf HOT 18 CLOSED

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.

from softrf.

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

from softrf.

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 cf5d37e
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.

from softrf.

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.

from softrf.

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.

from softrf.

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: 21098c6 cd8480d

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.

from softrf.

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

from softrf.

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

from softrf.

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

Thank you very much.

from softrf.

@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

from softrf.

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

from softrf.

@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.

from softrf.

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

from softrf.

@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.

from softrf.

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: cyoung/stratux#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.

from softrf.

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

from softrf.

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.

from softrf.

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.

from softrf.