search

cyoung / stratux

Aviation weather and traffic receiver based on RTL-SDR.
BSD 3-Clause "New" or "Revised" License
1.06k stars 362 forks source link

Altitude Discrepancies #132

Closed mooneyflier closed 8 years ago

mooneyflier commented 8 years ago

I may be the only one experiencing this but let me describe what I am observing and see if someone can tell me what is going on. While sitting static in one location on the ground in view of anywhere from 8 to 12 satellites acquired from the GSP/AHRS circuit board, Avare indicates an altitude of 430 ft. If Avare is indicating MSL, that indication is within 10-15 ft. of what a USGS elevation map shows for my location. Naviator has three choices for altitude 1) Altitude, 2) Approximate AGL, 3) Barometric Altitude. When Avare indicates an altitude of 430 ft., Navitator's Altitude indicates 510 ft., Approximate AGL 120 ft. and Barometric Altitude is 580 ft. The Stratux WebUi indicates the P-alt as 350 ft. I have noticed these differences with the latest stable release (v0.4r4) and now with v0.5b1 as well. (Edit) one thing I failed to mention is that Naviator is showing my GPS accuracy as 18,520m.

skypuppy commented 8 years ago

GPS elevation, even with WAAS, is not perfect, even if you have 4 or more sats in sight. There is a technique coming from the Air Force real-soon-now to make it a lot more accurate. (Don't hold your breath in our defense budget cuts era.) Baro altitudes are extremely dependent upon temperature, then how they are dealt with mathematically within the application's algorithm. Some algorithms do a wonderful job; some not so much. Further, when you get one algorithm happening within Stratux, feeding a tablet app with a completely different algorithm, you get the cluster you're seeing now. Stratux, from what I can tell (which isn't much yet) has a very good method, but the downstream apps mangle it up.

Skypuppy

On 12/01/2015 10:37 PM, mooneyflier wrote:

I may be the only one experiencing this but let me describe what I am observing and see if someone can tell me what is going on. While sitting static in one location on the ground in view of anywhere from 8 to 12 satellites acquired from the GSP/AHRS circuit board, Avare indicates an altitude of 430 ft. If Avare is indicating MSL, that indication is within 10-15 ft. of what a USGS elevation map shows for my location. Naviator has three choices for altitude 1) Altitude, 2) Approximate AGL, 3) Barometric Altitude. When Avare indicates an altitude of 430 ft., Navitator's Altitude indicates 510 ft., Approximate AGL 120 ft. and Barometric Altitude is 580 ft. The Stratux WebUi indicates the P-alt as 350 ft. I have noticed these differences with the latest stable release (v0.4r4) and now with v0.5b1 as well.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/132.

mooneyflier commented 8 years ago

Thanks for your comment. This situation may be unique to the Naviator app. If it continues, I may forward my concern to their developers.

cyoung commented 8 years ago

Can you enable "Record Logs" and see http://192.168.10.1/log/stratux-gps.log? Search for the GPS alt in the GNGGA sentence, it should be the tenth field. Compare with what Avare and Naviator show. Have had altitude display issues with Naviator once before.

mooneyflier commented 8 years ago

I connected to stratux, enabled the logging and then ran both apps but no log data appeared on the log screen of the WebUi. Not sure why. The apps ran normally receiving traffic etc. On Dec 3, 2015 7:56 PM, "cyoung" notifications@github.com wrote:

Can you enable "Record Logs" and see http://192.168.10.1/log/stratux-gps.log? Search for the GPS alt in the GNGGA sentence, it should be the tenth field. Compare with what Avare and Naviator show. Have had altitude display issues with Naviator once before.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/132#issuecomment-161849041.

cyoung commented 8 years ago

You'll have to go to the above link and refresh it every so often

mooneyflier commented 8 years ago

Is the link correct? I keep getting 404 page not found On Dec 3, 2015 9:00 PM, "cyoung" notifications@github.com wrote:

You'll have to go to the above link and refresh it every so often

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/132#issuecomment-161858426.

cyoung commented 8 years ago

http://192.168.10.1/logs/stratux-gps.log

http://192.168.10.1/logs/

Connected to stratux WiFi

mooneyflier commented 8 years ago

Second link worked. Got into the log. Avare logged first. Data at the top showed average around 154.4m. Naviator ran next. Way down the log file where I think it's data started showed 117.7m or so. I tried to save the page through the browser but can't find it. If I do, do u want to look at it? On Dec 3, 2015 9:24 PM, "cyoung" notifications@github.com wrote:

http://192.168.10.1/logs/stratux-gps.log

http://192.168.10.1/logs/

Connected to stratux WiFi

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/132#issuecomment-161863411.

cyoung commented 8 years ago

So the GPS is showing 117m, Avare is displaying 154m, and Naviator is displaying what?

mooneyflier commented 8 years ago

Stratux GPS is showing P-Alt of -140 ft, From the log file, Avare is showing 154m, and Naviator is showing 117m the best I can interpret it. I may have the two app's numbers turned around. Here is a clip of several lines from the top of the log. I had Avare activated when I started. Don't know why the date is incorrect. I formatted the card when I loaded v0.5b1: START,Sat Nov 21 23:49:44 +0000 UTC 2015,Sat Nov 21 23:49:44 +0000 UTC 2015 PAUSE,74780572 START,Sat Nov 21 23:49:30 +0000 UTC 2015,Sat Nov 21 23:49:30 +0000 UTC 2015 PAUSE,104152187 START,Sun Nov 22 00:17:10 +0000 UTC 2015,Sun Nov 22 00:17:11 +0000 UTC 2015 PAUSE,156214687 UNPAUSE,495090083145 495222751530,$GNRMC,022643.50,A,3611.51690,N,09027.96171,W,0.783,,041215,,,A_7D 495423097884,$GNRMC,022643.70,A,3611.51689,N,09027.96161,W,0.801,,041215,,,A_73 495423666321,$GNVTG,,T,,M,0.801,N,1.484,K,A_3D 495423757155,$GNGGA,022643.70,3611.51689,N,09027.96161,W,1,06,1.88,153.9,M,-30.4,M,,_76 495423856634,$GNGSA,M,3,32,03,26,23,16,,,,,,,,4.50,1.88,4.09_1D 495423963561,$GNGSA,M,3,65,,,,,,,,,,,,4.50,1.88,4.09_1E 495425153092,$GPGSV,4,1,13,03,50,246,19,09,08,309,,14,03,121,,16,71,169,32_71 495629407259,$GNRMC,022643.90,A,3611.51685,N,09027.96158,W,0.633,,041215,,,A_74 495629892103,$GNVTG,,T,,M,0.633,N,1.173,K,A_3F 495632186790,$GNGGA,022643.90,3611.51685,N,09027.96158,W,1,06,1.88,153.7,M,-30.4,M,,_70 495831379134,$GNRMC,022644.10,A,3611.51683,N,09027.96157,W,0.859,,041215,,,A_70 496020599030,$GNRMC,022644.30,A,3611.51680,N,09027.96157,W,0.992,,041215,,,A_77 496023142155,$GNVTG,,T,,M,0.992,N,1.837,K,A_32 496023530592,$GNGGA,022644.30,3611.51680,N,09027.96157,W,1,06,1.88,153.5,M,-30.4,M,,_75 496205100488,$GNRMC,022644.50,A,3611.51680,N,09027.96161,W,1.125,,041215,,,A_71 496205665488,$GNVTG,,T,,M,1.125,N,2.083,K,A_33 496205767727,$GNGGA,022644.50,3611.51680,N,09027.96161,W,1,06,1.88,153.7,M,-30.4,M,,_74 496205891738,$GNGSA,M,3,32,03,26,23,16,,,,,,,,4.50,1.88,4.09_1D 496206931946,$GNGSA,M,3,65,,,,,,,,,,,,4.50,1.88,4.09_1E 496207358925,$GPGSV,4,1,13,03,50,246,20,09,08,309,,14,03,121,,16,71,169,32_7B 496521373352,$GNRMC,022644.80,A,3611.51687,N,09027.96158,W,0.694,,041215,,,A_7D 496522715019,$GNVTG,,T,,M,0.694,N,1.285,K,A_38 496525422831,$GNGGA,022644.80,3611.51687,N,09027.96158,W,1,06,1.88,154.1,M,-30.4,M,,*75

cyoung commented 8 years ago

Okay, so the raw GPS output says the GPS detects you at 153.9m. So Avare is receiving this data correctly. Will try to reproduce this tomorrow with Naviator.

duecedriver commented 8 years ago

GPS altitude is absolute MSL not corrected for barro but absolute.. remember that the earth is not perfectly round so there are errors.. the USAF has secret sauce that corrects for some of that..

you could be experiencing multipathing which most military grade and commercial airliner grade GPS INU units could figure out and drop that offending satellite .. satellite geometry will sometimes affect the altitude accuracy but that was in the early days and in locations that had poor coverage like the poles.. basically if you only see like 3 sats and the are widely spread apart.. altitude precision drops..

PDOP VDOP AND DHDOP can shift wildly based on geometry, atmospherics, RF interference, multipathing, incorrect of conflicting use of datum, etc

I have never seen gps alt off by hundreds of feet though....

mmiller84 commented 8 years ago

I stumbled upon this issue and might have an explanation... It looks like the altitude in the 'ownship geometric altitude' message sent by Stratux is referenced to MSL, but according to the GDL90 spec it should be referenced to the WGS84 ellipsoid (HAE):

The Geo Altitude field is a 16-bit signed integer that represents the geometric altitude (height above WGS-84 ellipsoid), encoded using 5-foot resolution

Relevant Stratux code: https://github.com/cyoung/stratux/blob/master/main/gen_gdl90.go#L336

Naviator gets the ownship altitude from this message whenever an ADS-B receiver is connected. Naviator is also applying the geoid correction to the received value because it assumes the altitude is HAE. So it seems the geoid correction is being done twice, which might explain the error.

I've only briefly looked at the Stratux code, so let me know if I'm off base here.

-Mike (Naviator developer)

mooneyflier commented 8 years ago

Thanks Mike for your input on this subject. I'm not a programmer but maybe someone will notice your comment and take a closer look at your findings. I know on two other android apps I've used, the altitude is very close to the actual AGL but Naviator has always been between 90 - 100 ft. higher than the other apps. Also the AHRS they have been working on is much more stable than before. As I understand it apparently the display on Naviator and other apps has been showing a straight level climb when actually in a banking turn. I haven't been able to personally verify that. I have also noticed that recently iFlyGPS has apparently worked with Chris and others to test and pretty much refine the AHRS for that App. Hopefully your team will follow suit if not already. Again Thanks for your input into this project.

Nokomis449 commented 8 years ago

Mooneyflier, the work that iFly and others have done is to put the hooks in the code that interprets the data being sent. With these hooks in place, the apps are ready when Stratux starts sending accurate data. But as for now, the data is inaccurate and the AHRS data being displayed is, as it was put, "poisoned". There is no app out there that can display good AHRS data from Stratux, until Stratux gets that part of the code working. Just wanted to clear that up.

mmiller84 commented 8 years ago

And to add to Nokomis449's post, Naviator has had these "hooks" in place since August. Naviator will fully support the AHRS as soon as it's ready.

mooneyflier commented 8 years ago

Thanks guys. Nice to see the broad array of applications interested in the progress of this project.

mooneyflier commented 8 years ago

mmiller84, Here are some links to some screen shots I took this morning within just a few minutes apart that further show the differences in altitude between the Stratux WebUi, Naviator and Avare. Please notice the accuracy of the GPS which is pretty darn good in my opinion. I'm using the Vk-172 G-mouse USB GPS on this particular unit. http://imgur.com/nBgStTT http://imgur.com/qYYO1NC http://imgur.com/UIzLw4Y http://imgur.com/cWMX7kN

mmiller84 commented 8 years ago

Thanks, mooneyflier. The geoid separation at your location is -30 meters (~100 feet). This corresponds with the approx. 100ft difference in altitude between Naviator and Stratux/Avare.

ghost commented 8 years ago

@mmiller84 -- This seems to be a case where we're doing something nonstandard because everyone else is.

I've tested several other tablet EFBs on the current Stratux codebase, and they seem to interpret the GPS altitude in the 0x0B GDL90 message as feet MSL, rather than feet HAE. I even see the same results if I comment out the Stratux-specific heartbeat and status messages, so they don't seem to be Stratux-specific tweaks put in by the various other EFB vendors.

Unfortunately, this doesn't leave us with a great short-term solution from the Stratux point of view. Changing output to HAE will give a wrong altitude in every other app. Adding a configurable toggle or command-line flag could be confusing for end-users.

That said, we have been reading and interpreting the geoid separation since 799a247 (included in v0.5b4). It is now one of the global parameters that's reported as a getSituation statistic. If you wanted to use your own geoid model, it should be possible to read the value of GeoidSep and back-calculate HAE. Longer-term, geoid separation and the GPS altitude reference could be candidates to include in the "SX" Stratux status message.

mmiller84 commented 8 years ago

@AvSquirrel, thank you for your analysis. This is definitely an unfortunate situation to be in. My opinion is that these other apps contain a bug, and are misrepresenting HAE as MSL (assuming that the altitudes they are displaying are obtained via GDL message ID 0x0B).

I have analyzed the data from my iLevil unit, and it is correctly adhering to the GDL90 spec. With the iLevil, I do see the correct MSL altitude for my location when using Naviator (altitude obtained via 0x0B). The MSL altitude from the iLevil also matches the MSL altitude value derived from the internal GPS receiver on my phone.

In light of this, we cannot simply remove the geoid correction from Naviator without adversely affecting the users of other ADS-B receivers. If the Stratux devs are unwilling to conform to the GDL90 spec, we will have to add a special case for Stratux and skip the geoid correction.

Either way, I don't see a clear solution for you. If you keep the code as is most apps will show the correct MSL altitude when using Stratux, for now. However, if an app developer decides to conform to the spec at some point in the future Stratux will break without warning, and without any indication to users that the wrong altitude is being displayed (with errors in some cases being > 300ft).

skypuppy commented 8 years ago

http://www.ngdc.noaa.gov/geomag/WMM/newsoft.shtml

reflects the "new" model that NOAA has committed to.

HOWEVER, even though the WGS84 model can differ from HAE MORE than 200 meters, I believe it is incumbent upon groups (private and corporate) to deliver the standard that today's GPS receivers deliver, with is WGS84. It is up to the flight app software vendors, to decide what they want to do with it from there. I cannot say with certainty, but I think FAA apps and equipment still conform to the WGS84 model. All flight software (and their data suppliers) must conform to the FAA requirements; not for legal reasons but for safety reasons. When the FAA changes their standards, we should too. We cannot be reporting altitudes willy nilly based on whatever feels good at the moment.

See pages 6 and 7: https://www.faa.gov/air_traffic/flight_info/avn/flightinspection/onlineinformation/pdf/06-27_Official_Final_Report_Body.pdf

Skypuppy

On 01/18/2016 09:38 AM, Mike wrote: > @AvSquirrel https://github.com/AvSquirrel, thank you for your > analysis. This is definitely an unfortunate situation to be in. My > opinion is that these other apps contain a bug, and are > misrepresenting HAE as MSL (assuming that the altitudes they are > displaying are obtained via GDL message ID 0x0B). > > I have analyzed the data from my iLevil unit, and it is correctly > adhering to the GDL90 spec. With the iLevil, I do see the correct MSL > altitude for my location when using Naviator (altitude obtained via > 0x0B). The MSL altitude from the iLevil also matches the MSL altitude > value derived from the internal GPS receiver on my phone. > > In light of this, we cannot simply remove the geoid correction from > Naviator without adversely affecting the users of other ADS-B > receivers. If the Stratux devs are unwilling to conform to the GDL90 > spec, we will have to add a special case for Stratux and skip the > geoid correction. > > Either way, I don't see a clear solution for you. If you keep the code > as is most apps will show the correct MSL altitude when using Stratux, > for now. However, if an app developer decides to conform to the spec > at some point in the future Stratux will break without warning, and > without any indication to users that the wrong altitude is being > displayed (with errors in some cases being > 300ft). > > — > Reply to this email directly or view it on GitHub > https://github.com/cyoung/stratux/issues/132#issuecomment-172563822.
mmiller84 commented 8 years ago

@skypuppy, the WMM is used for something else entirely (namely, conversion between magnetic headings and true headings). It doesn't really have anything to do with GPS altitudes.

Everyone is in agreement that WGS84 should be used, and in fact it is being used by everyone. The problem is that there are two "references" for WGS84 altitudes: height above the ellipsoid, and height above the geoid. What pilots call "MSL" is basically the same thing as height above the geoid.

Think of the WGS84 ellipsoid as a very simplistic model of the surface of the earth. It doesn't accurately represent sea level over the entire surface of the earth. This leads to deviations from the true MSL altitudes. The EGM96 geoid model provides corrections for this and enables the GPS altitude to be converted to a more accurate value relative to the true MSL.

At the end of the day, pilots only care about seeing MSL altitudes- and that is what we are trying to achieve.

capnrash commented 8 years ago

I'm a bit "late to the party" here, but mooneyflier, you're not the only one seeing something like this. I have a perhaps unique setup: I'm not using the RY chip that most are using (nor any of the other popular ones) - I modified the v0.5b5 ry835ai.go code (very, very slightly) to correctly read NMEA data from an old Garmin 296. The Garmin unit & the Stratux WebUI both report the same altitude, but Naviator is indicating an altitude about 100 feet higher. I can't recall exactly which NMEA messages the Garmin is sending (all my stuff is at the airport right now), but it's sufficient for Stratux to properly know location, altitude, speed, heading, # satellites, etc. (If it'd be helpful for debugging to share more details - log file(s), etc., let me know; I'd be happy to do so...)

I've been following the recent discussions here about the different "types" of altitudes. Thank you to all the developers for their work; hopefully we can collectively figure out a way to get everything to "agree"!

skypuppy commented 8 years ago

@capnrash, Stratux gets the most accurate data it can, following some (mostly) established protocols. It is the flight applications software that mangles the real data, because their programmers made some assumptions that are not necessarily real or correct, then they put that in their code, and we have the mess we see now.

On 01/18/2016 03:09 PM, capnrash wrote:

I'm a bit "late to the party" here, but mooneyflier, you're not the only one seeing something like this. I have a perhaps unique setup: I'm not using the RY chip that most are using (nor any of the other popular ones) - I modified the v0.5b5 ry835ai.go code (very, very slightly) to correctly read NMEA data from an old Garmin 296. The Garmin unit & the Stratux WebUI both report the same altitude, but Naviator is indicating an altitude about 100 feet higher. I can't recall exactly which NMEA messages the Garmin is sending (all my stuff is at the airport right now), but it's sufficient for Stratux to properly know location, altitude, speed, heading, # satellites, etc. (If it'd be helpful for debugging to share more details - log file(s), etc., let me know; I'd be happy to do so...)

I've been following the recent discussions here about the different "types" of altitudes. Thank you to all the developers for their work; hopefully we can collectively figure out a way to get everything to "agree"!

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/132#issuecomment-172654436.

mmiller84 commented 8 years ago

@skypuppy, I somehow get the feeling that you are insinuating that we are "mangling" the data coming from Stratux, and I really don't appreciate your tone. To set the record straight, we are following the GDL90 specification to the letter. We are not making "assumptions". The Stratux devs are the ones who are deviating from the standard. You can read it for yourself here (section 3.8, page 28.): https://www.faa.gov/nextgen/programs/adsb/wsa/media/GDL90_Public_ICD_RevA.PDF

Note the following line:

The Geo Altitude field is a 16-bit signed integer that represents the geometric altitude (height above WGS-84 ellipsoid), encoded using 5-foot resolution, as follows...

See how it says "height above the WGS-84 ellipsoid"? That is exactly what Naviator is interpreting the data as. Stratux is sending the height referenced to the geoid. Hence the error.

We will be adding a special case to our code to handle Stratux properly. I simply wanted to point out that the Stratux devs might run into issues down the road if they continue to deviate from the standard.

skypuppy commented 8 years ago

There are more apps out there than yours. And actually, if the (Garmin?) gdl-90 spec does not agree with what the tower wants, then the spec is wrong.

skypuppy

On 01/18/2016 04:57 PM, Mike wrote: > @skypuppy https://github.com/skypuppy, I somehow get the feeling > that you are insinuating that we are "mangling" the data coming from > Stratux, and I really don't appreciate your tone. To set the record > straight, _we_ are following the GDL90 specification _to the letter_. > We are not making "assumptions". The Stratux devs are the ones who are > deviating from the standard. You can read it for yourself here > (section 3.8, page 28.): > https://www.faa.gov/nextgen/programs/adsb/wsa/media/GDL90_Public_ICD_RevA.PDF > > Note the following line: > > ``` > The Geo Altitude field is a 16-bit signed integer that represents > the geometric altitude (height > above WGS-84 ellipsoid), encoded using 5-foot resolution, as > follows... > ``` > > See how it says "height above the WGS-84 ellipsoid"? That is exactly > what Naviator is interpreting the data as. Stratux is sending the > height referenced to the geoid. Hence the error. > > We will be adding a special case to our code to handle Stratux > properly. I simply wanted to point out that the Stratux devs might run > into issues down the road if they continue to deviate from the standard. > > — > Reply to this email directly or view it on GitHub > https://github.com/cyoung/stratux/issues/132#issuecomment-172675857.
mmiller84 commented 8 years ago

OK, @skypuppy. I'm not sure why you have such a bone to pick. Clearly you do not understand the concepts I'm trying to explain to you.

And actually, if the (Garmin?) gdl-90 spec does not agree with what the tower wants, then the spec is wrong.

That's funny, considering the PDF is hosted on an FAA server.

I'm bowing out of this thread. I've said my piece, we'll be adding a special case to our code for Stratux. There is nothing left to discuss here.

duecedriver commented 8 years ago

@mmiller84

Nope he doesn't umderstand, won't listen, won't back it up with sources or solutions but he will piss in your Cheerios all day long...

I have been posting lots of source material around here in an effort mostly to move the ahrs forward but for every post I get like 10 opinions but nobody willing to read and understand the source material or to constructively weigh in on it most of the time....

I feel your pain

duecedriver commented 8 years ago

The tower never wants gps altitude only barometric.

skypuppy commented 8 years ago

Apparently deuce and Mike did not read my post. What i said was that not all the commercial apps are applying the same rules for elevation data. Last year, I conducted a simple test between five (5) [that's all the fingers on one hand] different commercial and free apps. Two (2) of those five showed elevations consistently 100 feet below actual. This test was conducted at an airport with known, official elevation. Occasionally, a third of the 5 apps gave +- 200 feet of actual. This is with the tablet lying on a mat on the ground and NOT moving at all (relative to the Earth surface.)

Errors that large really bother me (and quite a few other pilots.) Especially in non-free apps.

Skypuppy

On 01/18/2016 09:24 PM, duecedriver wrote:

The tower never wants gps altitude only barometric.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/132#issuecomment-172726943.

duecedriver commented 8 years ago

I dont know why I am even going to bother.. since you won't listen to it or read the sources but here it goes..

The GDL90 spec is TSO - PERIOD... therefore.. it does it right in the FAAs eyes... and manufacturers, software and hardware, that stick to this spec will be in compliance with what the FAA (you tower example) is expecting as a performance standard.

If you bother to read relevant or published TSO and AC documents authored by the FAA you will find that in aviation there are a myriad of different 'altitudes' in aviation. Even with barometric altitude, there are several different types, transition altitudes, etc. that the pilot must be aware of.

QNH: a barometer setting than when set would have the altimeter matching the airport surface elevation measured agains MSL... so if the airport is 400, the altimeter is 400 +- 75

QFE: if you are given this altimeter setting, your altimeter would read 0 in the same location as above. it reads height above field elevation..

and there are others, then there is the transition level, 18,000 here in the US but it can be different in other countries and it was in Europe when I flew international. its there so fast moving aircraft that transition different pressure areas are on the same sheet of music can get the most accurate separation because their altimeter is not set to a local pressure but a common one.

Now you come to GPS.. which is not barometry but mathematical modeling.. again with several altitudes as possible presentations and these have been explained to you already above so I will not bother to type the info or links to the specs again.. and I am sure you have not read them anyway..

for those that need addl spoon feeding...

AC No: 20-163 Subject: DISPLAYING GEOMETRIC Date: 07/09/2009 AC No: 20-163 ALTITUDE RELATIVE TO MEAN SEA LEVEL

a. This advisory circular (AC) shows you how to gain a type certificate (TC), supplemental TC (STC), amended TC (ATC), amended supplemental TC (ASTC), or technical standard order (TSO) authorization for systems incorporating the presentation of geometric altitude relative to mean sea level (MSL) on electronic displays.

however here are some GEMS... so as I stated to you tower never wants gps alt.

quote:

a. Barometrically derived altitudes are required for pilot compliance with published and air traffic controller-issued altitudes within the National Airspace System. The coexistence of barometric and geometric altitudes in the flight deck may confuse pilots, due to their similarity. For example, corrected barometric altitude and geometric altitude relative to MSL represent height above MSL, even though they differ by how they’re derived.

b. Pilots reading geometric altitude relative to MSL could reduce their vertical separation from other aircraft, because geometric altitude sometimes differs from the barometrically derived altitudes that other aircraft are using.

c. It’s important, therefore, to make geometric altitude relative to MSL clearly identifiable and distinguishable from barometric altitude, so pilots won’t confuse them and risk a reduction in vertical aircraft separation.

Now I posted a topic on the main page gps application formluas

now YOU were the first to bash that thread as well...

in that thread I tried to explain to the dense and uneducated that baro correction to gps derived sources is pretty much the way FMS (you know the million dollar INS/GPS) systems that people flying big iron use.. as well as baro aided TSO GPS units work.. BAROMETRY CORRECTION and it is still not what is displayed on their altimeter or PFD tapes.. it (gps) sources are used internally for comparator checks, aiding the ring laser or solid state gyros in the INS, autopilot aiding, etc. but its not the MSL presented to the pilot.

pure GPS altitude is rarely displayed purely, in a TSO environment, because 1, its not (yet) a nav source that the controllers separate traffic with, and 2. guys like you would not use it right and fly into a mountain

CONCLUSION

If Chris is providing the GPS alt from stratux IAW the GDL-90 spec than its the specific EFB that is presenting it in a way that is confusing you into thinking its MSL.. which it will never truly be..

if mike and his product use a GDL-90 spec gps altitude input correctly, and since he is conversant on this topic compared to you, I would take his word for it.. than you are barking up the wrong tree and yet again mouthing off at someone wiser on the topic that is trying to straighten you out with whom you are picking yet another argument.,

jzeevi commented 8 years ago

Pizza. This is valuable, but needs to be about the facts, not made about the people.

Josef Sent from a phone with a tiny screen

On Jan 19, 2016, at 8:27 AM, duecedriver notifications@github.com wrote:

I dont know why I am even going to bother.. since you won't listen to it or read the sources but here it goes..

The GDL90 spec is TSO - PERIOD... therefore.. it does it right in the FAAs eyes... and manufacturers, software and hardware, that stick to this spec will be in compliance with what the FAA (you tower example) is expecting as a performance standard.

If you bother to read relevant or published TSO and AC documents authored by the FAA you will find that in aviation there are a myriad of different 'altitudes' in aviation. Even with barometric altitude, there are several different types, transition altitudes, etc. that the pilot must be aware of.

QNH: a barometer setting than when set would have the altimeter matching the airport surface elevation measured agains MSL... so if the airport is 400, the altimeter is 400 +- 75

QFE: if you are given this altimeter setting, your altimeter would read 0 in the same location as above. it reads height above field elevation..

and there are others, then there is the transition level, 18,000 here in the US but it can be different in other countries and it was in Europe when I flew international. its there so fast moving aircraft that transition different pressure areas are on the same sheet of music can get the most accurate separation because their altimeter is not set to a local pressure but a common one.

Now you come to GPS.. which is not barometry but mathematical modeling.. again with several altitudes as possible presentations and these have been explained to you already above so I will not bother to type the info or links to the specs again.. and I am sure you have not read them anyway..

for those that need addl spoon feeding...

AC No: 20-163 Subject: DISPLAYING GEOMETRIC Date: 07/09/2009 AC No: 20-163 ALTITUDE RELATIVE TO MEAN SEA LEVEL

a. This advisory circular (AC) shows you how to gain a type certificate (TC), supplemental TC (STC), amended TC (ATC), amended supplemental TC (ASTC), or technical standard order (TSO) authorization for systems incorporating the presentation of geometric altitude relative to mean sea level (MSL) on electronic displays.

however here are some GEMS... so as I stated to you tower never wants gps alt.

quote:

a. Barometrically derived altitudes are required for pilot compliance with published and air traffic controller-issued altitudes within the National Airspace System. The coexistence of barometric and geometric altitudes in the flight deck may confuse pilots, due to their similarity. For example, corrected barometric altitude and geometric altitude relative to MSL represent height above MSL, even though they differ by how they’re derived.

b. Pilots reading geometric altitude relative to MSL could reduce their vertical separation from other aircraft, because geometric altitude sometimes differs from the barometrically derived altitudes that other aircraft are using.

c. It’s important, therefore, to make geometric altitude relative to MSL clearly identifiable and distinguishable from barometric altitude, so pilots won’t confuse them and risk a reduction in vertical aircraft separation.

Now I posted a topic on the main page gps application formluas

now YOU were the first to bash that thread as well...

in that thread I tried to explain to the dense and uneducated that baro correction to gps derived sources is pretty much the way FMS (you know the million dollar INS/GPS) systems that people flying big iron use.. as well as baro aided TSO GPS units work.. BAROMETRY CORRECTION

pure GPS altitude is rarely displayed purely, in a TSO environment, because 1, its not (yet) a nav source that the controllers separate traffic with, and 2. guys like you would not use it right and fly into a mountain

CONCLUSION

If Chris is providing the GPS alt from stratux IAW the GDL-90 spec than its the specific EFB that is presenting it in a way that is confusing you into thinking its MSL.. which it will never truly be..

if mike and his product use a GDL-90 spec gps altitude input correctly, and since he is conversant on this topic compared to you, I would take his word for it.. than you are barking up the wrong tree and yet again mouthing off at someone wiser on the topic that is trying to straighten you out with whom you are picking yet another argument.,

— Reply to this email directly or view it on GitHub.

duecedriver commented 8 years ago

@jzeevi

do you see a name in my post... ?

and I think I provided yet again a wealth of ACTUAL FACTUAL INFORMATION

and lets not forget the BIGGEST thing here... the GDL-90 standard is for a ADS-B box that is designed to

quote from mfg: receive and decode Automatic Dependent Surveillance-Broadcast (ADS-B) messages via onboard datalink. It broadcasts your aircraft's position, velocity, projected track, altitude and flight identification to other equipped aircraft in your vicinity, as well as to ground-based transceivers maintained by the FAA.

it is not and air data computer (ADC) but it takes its altitude input from one

its not an altitude encoder, but it takes inputs from it

its not designed nor will it provide altitude data to any PFD in the altimetry box

there are several message formats in the GDL-90 spec and the own ship Geo altitude message is just one

there are others that use the encoded (baro) altitude as well... thats if you have actually read the spec: 3.5.1.4 ALTITUDE GDL 90 Data Interface Specification 560-1058-00 Rev A The Altitude field "ddd" contains the pressure altitude (referenced to 29.92 inches Hg), encoded using 25-foot resolution, offset by 1,000 feet. The 0xFFF value represents that the pressure altitude is invalid. The minimum altitude that can be represented is -1,000 feet. The maximum valid altitude is +101,350 feet.

ALL of the altimetry functions in the GDL spec are designed for TRAFFIC messages NOT for presenting a FAA TSO primary flight display ALTITUDE (MSL or equiv) for you to operate and aircraft by... PERIOD

altimetry data designed for primary fight go over the ARINC 429 bus (or equiv) and its the only one to be used for controlling the aircraft.

all these portable ADS-B/GPS manufacturers and EFB companies are providing a BACKUP altitude based off a SECONDARY source (GPS) that has several designed DATUMS of which none are TSO to be displayed as primary information.. so there are bound to be differences.. THE GDL-90 SPEC only STANDARDIZES the traffic functions and uses of the ADS-B data.

that is why WIngX and others provide a way for you to set the GPS alt to match your altimeter or current known ground elev to get it close...

jzeevi commented 8 years ago

So, I’ll put out a plea for everyone engaged in this to 

  1.  Take a deep breath.
  2.  Read the post you’re replying to again to make sure you are responding JUST to any facts that are in disagreement
  3.  Type up your response – DO NOT SEND
  4.  Re-read it to make sure it addresses the facts in disagreement, not what you think of the poster
  5.  Then hit send.

J

Note: I have no dog in this hunt. You guys are far more connected to the “tech” at this time than I am. But it’s just not productive for X to say that Y isn’t listening or stupid or whatever. Either directly or by inference.

Come on, let’s focus on this brilliant idea, not our individual “eccentricities”.

josef

From: duecedriver [mailto:notifications@github.com] Sent: Tuesday, January 19, 2016 9:52 AM To: cyoung/stratux Cc: Josef Zeevi Subject: Re: [stratux] Altitude Discrepancies (#132)

@jzeevi https://github.com/jzeevi

do you see a name in my post... ?

and I think I provided yet again a wealth of ACTUAL FACTUAL INFORMATION

and lets not forget the BIGGEST thing here... the GDL-90 standard is for a ADS-B box that is designed to

quote from mfg: receive and decode Automatic Dependent Surveillance-Broadcast (ADS-B) messages via onboard datalink. It broadcasts your aircraft's position, velocity, projected track, altitude and flight identification to other equipped aircraft in your vicinity, as well as to ground-based transceivers maintained by the FAA.

it is not and air data computer (ADC) but it takes its altitude input from one

its not an altitude encoder, but it takes inputs from it

its not designed nor will it provide altitude data to any PFD in the altimetry box

there are several message formats in the GDL-90 spec and the own ship Geo altitude message is just one

there are others that use the encoded (baro) altitude as well... thats if you have actually read the spec

ALL of the altimetry functions in the GDL spec are designed for TRAFFIC messages NOT for presenting a FAA TSO primary flight display ALTITUDE (MSL or equiv) for you to operate and aircraft by... PERIOD

altimetry data designed for primary fight go over the ARINC 429 bus (or equiv) and its the only one to be used for controlling the aircraft.

all these portable ADS-B/GPS manufacturers and EFB companies are providing a BACKUP altitude based off a SECONDARY source (GPS) that has several designed DATUMS of which none are TSO to be displayed as primary information.. so there are bound to be differences.. THE GDL-90 SPEC only STANDARDIZES the traffic functions and uses of the ADS-B data.

that is why WIngX and others provide a way for you to set the GPS alt to match your altimeter or current known ground elev to get it close...

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/132#issuecomment-172895214 . https://github.com/notifications/beacon/APJ34YGM-6TdJnTNdYA0QNBwL_wfKP8Hks5pblMkgaJpZM4Gs26G.gif

duecedriver commented 8 years ago

I will put out a different plea...

  1. the only way Chris and the other CODERS here are going to get this even close to right is if they are fed FACTS.. not opinions so post FACTS..
  2. the EFB developers here.. and they are here.. are going to get frustrated since Stratux is just one of many boxes they have to try and make their products work with

3 which leads me to the statement I made weeks ago.. stratux needs to publish the standard that they will code to and use it and document how, where, and why they are deviating if they have to so that the developers of the EFBs can keep their software in sync.. we still dont have a page up with this documentation.. and even though the GDL-90 spec as written could work here, they modified it a bit already for the overly verbose heartbeat message for WingX.. but that is trivial

4 that people here have to realize their IPAD is never going to be a primary flight display regardless of how cool they think that might be.. it will just never happen and to trust it or any portable system as a primary reference is foolhardy.. you must learn and understand the limitations of GPS navigation, backup AHRS capabilities and what it can and cant do.

  1. if you are posting ask yourself if the question has already been answered and have I really searched, if you are posting a reply and it doesn't contain FACTS, give it a second thought, if you are posting a criticism are you including an alternate solution based on FACTS.... otherwise just keep it to yourself

problems need solutions, solutions need to be solved based on FACTS

it sounds like Mike packed it in.. and he IS a DEVELOPER by the sound of it.. how many more does this community want to run off.....?

Stratux is just a box.. it still relies on the EFB manufacturers to support it.....

cyoung commented 8 years ago

@mmiller84 has made a recent change to deal with our non-standard altitude reporting.

@mooneyflier or @mmiller84 , are you able to confirm that the issue has been resolved?

mooneyflier commented 8 years ago

It looks like Naviator's altitude now matches what is reported through Stratux. I also checked it using Avare and all three, Naviator, Avare and the Stratux WebUi are reporting the same altitude. Thanks! On Jan 26, 2016 11:35 AM, "cyoung" notifications@github.com wrote:

@mmiller84 https://github.com/mmiller84 has made a recent change to deal with our non-standard altitude reporting.

@mooneyflier https://github.com/mooneyflier or @mmiller84 https://github.com/mmiller84 , are you able to confirm that the issue has been resolved?

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/132#issuecomment-175133853.

cyoung commented 8 years ago

Thanks for checking back.

mooneyflier commented 8 years ago

I forgot to mention that Naviator appears to be reporting pressure altitude. If u tap on a traffic target a balloon pop out provides various flight info and has the words "pressure altitude" beside the altitude number. I also notice on the 3D screen there is a choice to select pressure altitude on the display.