Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FLARM altitudes are incorrect when parsing GGA NMEA sentences #1425

Closed
twpayne opened this issue May 13, 2024 · 9 comments
Closed

FLARM altitudes are incorrect when parsing GGA NMEA sentences #1425

twpayne opened this issue May 13, 2024 · 9 comments

Comments

@twpayne
Copy link

twpayne commented May 13, 2024

XCSoar versions having the problem

All for at least the last 14 years, including the current master branch (commit b1244d8 at the time of writing).

XCSoar versions not having the problem

n/a

System information

n/a

Steps to reproduce the behavior

These lines:

// need to estimate Geoid Separation internally (optional)
// FLARM uses MSL altitude
//
// Some others don't.
//
// If the separation doesn't appear in the sentence,
// we can assume the GPS unit is giving ellipsoid height
//
if (use_geoid && info.location_available) {
// JMW TODO really need to know the actual device..
geoid_separation = EGM96::LookupSeparation(info.location);
info.gps_altitude -= geoid_separation;
}

state that FLARM uses MSL altitudes and subtract the geoid separation as computed from EGM96.

This is not correct. FLARM always uses elevation above the WGS84 ellipsoid. The subtraction should be removed.

Expected behavior

The altitude is correct.

Actual behavior

The altitude is incorrect by the value of the geoid separation.

Do you have any idea what may have caused this?

n/a

Do you have an idea how to solve the issue?

Remove the else branch of this if statement completely.

@kobedegeest
Copy link
Contributor

According to the flarm data protocol the --GGA and PGRMZ sentences are used and both of these use MSL altitude.
So why do you say it sends out the WGS84 altitude?
(IGC files however do indeed contain the WGS84 ellipsoid elevation but i do not think this is what the flarm sends out)

And either way this is inside a function that parses the --GGA sentence which should use MSL. So if flarm were to abuse this sentence (which i doubt) it should be fixed elsewhere than just removing the else statement.

@lyusupov
Copy link
Contributor

@kobedegeest

it is obviously a PEBKAC type of issue invented by the submitter -

image

@twpayne twpayne closed this as completed May 16, 2024
@twpayne
Copy link
Author

twpayne commented May 16, 2024

If your response to bug reports is ad hominem attacks on the bug reporter ... good luck with your project.

@DanD222
Copy link
Contributor

DanD222 commented May 16, 2024

If your response to bug reports is ad hominem attacks on the bug reporter ... good luck with your project.

The last comment was not from an XCSoar developer (I am not one either), so please don't be offended.

@lordfolken
Copy link
Contributor

@twpayne out of interest, what made you think the altitude indicated in XCSoar to be wrong?

@lyusupov
Copy link
Contributor

lyusupov commented May 17, 2024

@lordfolken

the statement

... FLARM always uses elevation above the WGS84 ellipsoid ...

has actually some sense for FLARM radio data emitted by its built-in sub-1GHz ISM band transmitter.

But it has nothing to do with serial data protocol (FTD-012) that FLARM uses for communication with third-party hardware & software, such as XCSoar.

@lordfolken
Copy link
Contributor

lordfolken commented May 17, 2024

@lyusupov the guy has written a lot of gis and geospatial related tools. I suspect he is quite knowledgeable on the topic. ;-)
He went bug hunting for a reason, and while this particular location probably isn't the cause, i"d like to know what made him hunt for this.

@lyusupov
Copy link
Contributor

@lordfolken

Responsible bug reporters are typically very careful before they can make such statements

All for at least the last 14 years, including the current master branch (commit https://github.com/XCSoar/XCSoar/commit/b1244d8dc61e808a3fab3f9d14668aa777e91835 at the time of writing).

With no arguments at all!

@twpayne
Copy link
Author

twpayne commented May 20, 2024

Note that all FLARM radio communication uses ellipsoid height, i.e. my goal is ensure that all instruments are reporting the correct ellipsoid height.

I raised this issue when debugging an issue in a flight instrument that uses XCSoar as a reference implementation. In this particular case, the instrument was reporting an altitude roughly 100m different to other instruments at my testing location. At my testing location the geoid separation is 47m and I suspect that this was being subtracted when it should be added, which neatly accounts for the 100m difference.

From further reading on GGA NMEA sentences, I understand that the GGA sentence includes both geoid (AMSL) altitude and geoid separation. When both geoid altitude and geoid separation are positive, I believe that things look something like this (excuse the crude ASCII art):

        -oo-+ <----- aircraft
          ^
          :
          : <------- altitude AMSL (i.e. above geoid, say 400m)
          :
          v
----____----____---- geoid (AMSL)
          ^
          : <------- geoid separation (say 47m)
          v
______--------______ elipsoid

So therefore, the aircraft's height above the ellipsoid is 400+47 = 447m.

My understanding of the current XC Soar code is that it subtracts the geoid separation, i.e. reports an ellipsoid altitude of 400-47 = 353m.

Note that I do not have access to the official NMEA specification for GGA sentences. My understanding of the altitudes is based on what I've found online.

@XCSoar XCSoar locked and limited conversation to collaborators May 20, 2024
@lordfolken lordfolken converted this issue into discussion #1435 May 20, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants