-
Notifications
You must be signed in to change notification settings - Fork 273
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
Comments
According to the flarm data protocol the --GGA and PGRMZ sentences are used and both of these use MSL altitude. 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. |
it is obviously a PEBKAC type of issue invented by the submitter - |
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. |
@twpayne out of interest, what made you think the altitude indicated in XCSoar to be wrong? |
the statement
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. |
Responsible bug reporters are typically very careful before they can make such statements
With no arguments at all! |
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):
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. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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:
XCSoar/src/Device/Parser.cpp
Lines 616 to 628 in b1244d8
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 thisif
statement completely.The text was updated successfully, but these errors were encountered: