Inconsistency in GNSS getAltitude

[PaulZC]

I found this while working on the new BaseAssist mode - where the firmware goes from Rover (with RTK Fix) to Fixed Base. I noticed that the altitude reported by Postcard (LG290P) was off by the MSL-Geoidal separation.

Using the RTK mosaic-X5 as my Base:
RTK mosaic-X5 is in Static mode
On its web page, it reports my Height (HGT) as 155.86m
For the RTCM 1006 position it reports to RTK2go, I see the same 155.86m reported at my SNIP::MOUNTPT

155.86m is my Ellipsoidal Height (WGS84)
My Height above MSL is 108.25m
A difference of 47.61m

If I have both a Postcard (LG290P) and a EVK (ZED-F9P) configured as Rovers with NTRIP Client connected to RTK2go
Both get RTK Fix

I have periodic printCurrentConditions enabled

printCurrentConditions calls gnss->getAltitude()

The EVK reports an altitude of 152m. That is correct for Ellipsoidal Height. The antenna is about 3m lower than the mosaic-X5 antenna.

The Postcard reports an altitude of 106m. That is correct for Height above MSL. The antenna is ~level with the mosaic-X5 antenna.

Note the difference of ~46m...

When I go from Rover mode into Fixed Base using the new BaseAssist route:

• The altitude from gnss->getAltitude() is copied across into settings.fixedAltitude
• gnss->getLatitude() is copied into settings.fixedLat
• gnss->getLongitude() is copied into settings.fixedLong
• settings.fixedBase is set true
• settings.fixedBaseCoordinateType is set to COORD_TYPE_GEODETIC

Afterwards:

Postcard reports an altitude of 58.89m
EVK reports an altitude of 154.6m

If I connect one Base then the other to RTK2go:

The reported Postcard altitude on RTK2go is 108.3m
The reporetd EVK altitude on RTK2go is 154.6m

It's a big old mess...

[PaulZC]

Digging into why this happens reveals an inconsistency in the values reported by gnss->getAltitude :

Postcard (LG290P)

getAltitude calls getAltitude in the SparkFun LG290P GNSS Library
This returns pvtDomain.altitude
which is extracted from PQTMPVT
It is the Numeric Meter Altitude above mean sea level (meters)

EVK (ZED-F9P)

getAltitude returns _altitude
_altitude is extracted from NAV-PVT data (ubxDataStruct->height)
height is the Height above ellipsoid (mm)

Torch (UM980)

getAltitude calls getAltitude in the SparkFun Unicore GNSS Library
This returns packetBESTNAV->data.altitude
The BESTNAVB hgt is Height above mean sea level (meters)

Facet mosaic-X5 (mosaic-X5)

getAltitude returns _altitude
_altitude is extracted from SBF 4007 Height
Height is the Ellipsoidal height (metres, with respect to the ellipsoid specified by Datum)

So, we have two reporting MSL and two reporting Ellipsoidal Height!

What should we do?
And how do we best fix this without invalidating a bunch of data collected by users previously?!

Do we change the GNSS libraries so they all match? But that would completely smash backward compatibility...

Are we saved by the fact that:

• Data logged to SD card is logged as GNSS messages (NMEA, PQTM, SBF, etc.) where it is clear what each field represents
• Data passed to (e.g.) SW Maps over Bluetooth is also passed as GNSS messages

Maybe we just need to be really, really careful when we use getAltitude in unusual ways - like copying the lat/lon/alt into the Fixed Base position!

printCurrentConditionsNMEA() might need looking at. That reports getAltitude and so will be different for different GNSS.

For the IM19 and Tilt Compensation, I think we're OK. The IM19 is fed with NMEA. When we call nmeaApplyCompensation, we replace the altitude with tiltSensor->getNaviAltitude which comes from the binary NAVI message. I think that's all OK and self-consistent?

[PaulZC]

The solution:

For Postcard (LG290P), the library already has a getGeoidalSeparation method we can call.

For Torch (UM980), we need to add a getGeoidalSeparation method.

I'm on it!

[PaulZC]

For the Torch (UM980), see: https://github.com/sparkfun/SparkFun_Unicore_GNSS_Arduino_Library/releases/tag/v1.0.10

[PaulZC]

After thinking about this a bit more, I now think the right way to fix this is in the GNSS class within RTK_Everywhere.

Other than adding getGeoidalSeparation on UM980, let's leave the underlying GNSS libraries alone...

[PaulZC]

Note to our future selves:

createSettingsString , printCurrentConditions , printCurrentConditionsNMEA , createDynamicDataString all call gnss->getAltitude(). Once the changes in Add_BaseAssist are merged, the reported altitude will be correct on Postcard (LG290P) and Torch (UM980), and consistent on all four GNSS. But, because it will be different to how it was previously, we should expect questions from users about why the altitude appears to have changed.

[gdt]

The most important thing is for all procedures to have a clear specification, and tthen to have the same semantics on all systems/devices. It seems that the current behavior is a bug, and I would lean to fixing it, rather than elevating to the status of ok and demanding compat.

Everything altitude should be labeled HAE or Orthometric. MSL is really not an ok term in precise height as there is no such thing. There's the further issue of varying datums; with NAD83 one uses NAVD88, and with WGS84 one uses "WGS84 Orthometric Height" and the values for a point differ, just as do the HAE and XYZ.