EFB altitude handling in Ownship reports

[cyoung]

1. Stratux version: v0.8r2

2. Stratux config:

   SDR [ ] single [X] dual

   GPS [X] yes [ ] no type:

   AHRS [X] yes [ ] no

   power source: wall wart

   usb cable: y-cable

3. EFB app and version: all
4. Description of your issue:

Need help characterizing EFBs and how they deal with "ownship" altitude. For the ownship (0x0A) report, http://www.faa.gov/nextgen/programs/adsb/wsa/media/GDL90_Public_ICD_RevA.PDF says on p.20 that the altitude in this report should be pressure altitude. The following apps INCORRECTLY interpret this altitude as:

1. FlyQ - MSL altitude.
2. WingX - MSL altitude.
3. AerovieReports - MSL altitude.
4. Naviator - couldn't even figure out how to use this.

The following apps CORRECTLY interpret this altitude as pressure altitude, and use "Ownship Geometric" (0x0B) as:

1. ForeFlight - MSL altitude.
2. Avare - MSL altitude (calculated with a 0.15% rounding error).
3. DroidEFB - MSL altitude (calculated with a 0.05% rounding error).
4. FltPlan Go - MSL altitude.

(testing): heartBeatSender():

mySituation.Lat = 44.00
mySituation.Lng = -85.00
mySituation.HeightAboveEllipsoid = 500
mySituation.LastFixLocalTime = stratuxClock.Time
mySituation.Alt = 2000
mySituation.NACp = 11
mySituation.Pressure_alt = -100
mySituation.LastTempPressTime = stratuxClock.Time

[skypuppy]

iFlyGPS also uses GPS altitude. I'd rather use that than baro from inside the cockpit. Baro from pitot tube (or equivalent) is what should be used. There are some pressure-sensing chips that have barbs on them, making them ideal for connecting to the pitot-static system.

I used them about a thousand years ago. Back then, they were Freescale (?) 5V chips and they were temperature compensated on the chip (for possible chip induced errors) like these: http://www.mouser.com/ProductDetail/NXP-Freescale/MPXM2053GS/?qs=sGAEpiMZZMtiz6SYu%2fjtS%2fyORoCsh51bdxjJH%252bkoPT8%3d

and especially these: http://www.mouser.com/ProductDetail/NXP-Freescale/MPX5100DP/?qs=sGAEpiMZZMtiz6SYu%2fjtS%2fyORoCsh51bVcL0NsZGl90%3d

Skypuppy

On 03/23/2016 08:47 AM, cyoung wrote:

1. Stratux version: v0.8r2 2.

   Stratux config:

   SDR [ ] single [X] dual

   GPS [X] yes [ ] no type:

   AHRS [X] yes [ ] no

   power source: wall wart

   usb cable: y-cable

EFB app and version: all

4.

Description of your issue:

Need help characterizing EFBs and how they deal with "ownship" altitude. For the ownship (|0x0A|) report, http://www.faa.gov/nextgen/programs/adsb/wsa/media/GDL90_Public_ICD_RevA.PDF says on p.20 that the altitude in this report should be /pressure altitude/. The following apps /INCORRECTLY/ interpret this altitude as:

1. FlyQ - MSL altitude.
2. WingX - MSL altitude.
3. AerovieReports - MSL altitude.
4. Naviator - couldn't even figure out how to use this.

The following apps /CORRECTLY/ interpret this altitude as pressure altitude, and use "Ownship Geometric" (|0x0B|) as:

1. ForeFlight - MSL altitude.
2. Avare - MSL altitude (calculated with a 0.15% rounding error).
3. DroidEFB - MSL altitude (calculated with a 0.05% rounding error).

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/348

[Ergonomicmike]

AFAIK, iFly doesn't accept altitude info from ADS-B yet (that is, I don't believe that iFly is looking at 0x0A data yet). Instead, as Skypuppy said, iFly uses GPS altitude in its built-in "Ghost Filter" to eliminate ownship.

Not to be contrarian, but I don't have any concern about using pressure altitude from inside the plane for ADS-B own ship filtering. In 35 years of informal sampling of GA aircraft, the worst I've seen is a 100 foot delta between static and alternate static. Even with vents full open. I expect that EFB manufactures allow a generous plus or minus for this, especially since they have GPS data to pretty much say "I know that that's you." Clearly iFly allows a fairly good margin for altitude in its built in Ghost filter, since it filters me out even on days when there's a 500 ft difference between GPS altitude and PA.

[cyoung]

Ownship detection is a topic for another day. This is concerning the primary altitude display. The EFBs in the first list take in PA and show it as if it were "GPS altitude" (MSL).

[Ergonomicmike]

Okay. I referred to iFly's detection simply to demonstrate that iFly isn't using PA yet, but GPS alt instead. (Which, of course, makes delta altitudes of traffic incorrect most of the time.) I expect that iFly will offer two Instruments when they start accepting PA - one labeled GPS Alt, the other ???.

[skypuppy]

Maybe Baro Alt, or BA, or...

On 03/23/2016 02:41 PM, Ergonomicmike wrote:

Okay. I referred to iFly's detection simply to demonstrate that iFly isn't using PA yet, but GPS alt instead. (Which, of course, makes delta altitudes of traffic incorrect most of the time.) I expect that iFly will offer two Instruments when the start accepting PA - one labeled GPS Alt, the other ???.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/348#issuecomment-200513906

[jpoirier]

Using PA as a source for primary altitude seems problematic at best and using GPS over PA for primary altitude would seem like the better choice. Surely the apps in the first list use GPS for primary altitude when there are no PA values, and do they really select PA over GPS when both messages are available, or do they blend the two values, with others, when PA can be calibrated?

[cyoung]

No blending that I've found.

[skypuppy]

The problem comes with integration with the rest of the FAA system. Remember, at first, the only instrument available in the plane was baro, so all the FAA reporting systems were built around that and they still use it today. So to operate with the rest of the FAA system, baro is needed. However, for me and my little plane, I'd MUCH rather know the actual height above ground, hills, towers, guy wires, cables, and etc. :) But when I have to rely on FAA reporting of others in the system, I need that too, so I know where I am relative to the other planes who (theoretically) reporting baro altitudes.

Skypuppy

On 03/23/2016 04:07 PM, Joseph Poirier wrote:

Using PA as a source for primary altitude seems problematic at best and using GPS over PA for primary altitude would seem like the better choice. Surely the apps in the first list use GPS for primary altitude when there are no PA values, and do they really select PA over GPS when both messages are available, or do they blend the two values, with others, when PA can be calibrated?

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/348#issuecomment-200543829

[jpoirier]

I wouldn't expect an EFB to do it but it would be ideal. Something similar to the way an EGPWS system would calculate geometric altitude, blending calibrated values weighted based on their accuracy.

[ghost]

Two more apps (data current as of a couple months ago):

• FltPlan Go: Interprets GPS altitude from ownship 0x0B geo alt message as MSL GPS altitude; interprets pressure altitude from ownship 0x0A message as MSL pressure altitude.
• Naviator: Used to interpret ownship 0x0B geo altitude as WGS84 HAE, in accordance with GDL90 spec; recently changed to MSL for compatibility purposes. This is (was?) the only EFB app I'm aware of that implemented its interpretation of the GDL90 messages 100% consistent with the spec.

Keep in mind that the GDL90 was a UAT transceiver, developed for Phase II Capstone in the early 2000s. The protocol we use was developed so this box:

could send traffic and weather information to this box:

over a 38.4 kbps serial connection. Since ADS-B and TIS-B traffic is transmitted with pressure altitudes 99.999% of the time (exceptions are encoding altimeter failures), ownship pressure altitude was the primary altitude reference on this device -- and for its first two revisions, the only reference. (Geometric altitude wasn't added until v2.1.)

The subsequent use of the protocol over anything other than a serial connection, or to send 1090 traffic, or to transmit a 3D position to an EFB on a tablet computer goes well beyond what Apollo / UPS-AT / Garmin designed the hardware to do. Nevertheless, I believe that the well-documented nature of the GDL90 protocol implies that we deviate from it only under exceptional circumstances, when it is clear that not deviating will cause significant operational difficulties, and even then only after clearly documenting why we deviate. For anything beyond that, we should remind EFB developers that Stratux has a very full-featured JSON output that can be read for anything and everything they would ever need to display in their apps.

As of the current Stratux builds, I am aware of two exceptions to "strict" GDL90 handling:

• 0x0B Geometric Altitude is sent with MSL altitude. The GDL90 protocol specifies that geometric altitude is the height above WGS-84 ellipsoid (HAE), not height above mean sea level as Stratux reports. Over most of North America, the difference is about -100' (HAE is below MSL). This is one area where we have intentionally deviated from the spec because most EFBs (save for Naviator) had implemented this incorrectly, and doing the "right thing" would mean that Stratux indicated 100 feet low.
• 0x0A Ownship Report is sent with the GPS altitude, rather than "invalid (0xFFF) if pressure altitude is unavailable. This is to deal with a ForeFlight bug that causes it calculate traffic altitude as if ownship altitude was 0' MSL. (@cyoung, I'll take an action to verify against FF 7.6.)

For posterity, these are the GDL90 definitions / encodings for pressure altitude in the 0x0A Ownship message, and geometric altitude in the 0x0B Geometric Altitude message.

Pressure altitude:

Geometric altitude:

[cyoung]

Yep! I remember the 0xFFF ForeFlight bug. I don't want to address that here and just want to use this issue as testing request for documentation purposes. The 0x0B/WGS-84 issue is different. Almost 100% of EFBs were interpreting it one way. The issue addressed here is about 50/50.

[Ergonomicmike]

I will send the Sr. developer at iFly the link for this discussion.

[cyoung]

Tried testing iFly this morning, couldn't make the 5 minute trial period.

[Ergonomicmike]

Your trial timed out. Perhaps email Shane and ask if he can give you a complimentary VFR subscription for Stratux testing purposes.

[cyoung]

OK got it, yes there is no GPS source from GDL90. Guess it wouldn't be iFly GPS without GPS.

[skypuppy]

Re iFlyGPS, I compared the baro/gps readings from the webui page to iFly and the iFly was using the gps reported altitude as their altitude on their instrument setting. (My unit has a baro sensor.)

[welbo97]

All of the planes I currently fly are pressurized so a baro sensor would be inaccurate for me. If you are looking for an alternative source of altitude data, why not take the mode C data straight out of the transponder replies? It is generated from on board encoders which are required to have current calibration and always referenced to 29.92". I was under the impression the WGS-84 ellipsoid had significant error in parts of the world. Positive in some and negative in others. Not a constant -100' difference.

[bsdcat]

@AvSquirrel I am tracking the bug with ForeFlight's handling of 0xFFF pressure altitude in ownship reports.

[cyoung]

@bsdcat - any change in 0xFFF pressure altitude handling in FF?

[bsdcat]

Oops, I guess I did not update this thread. This was addressed in the ForeFlight 7.7 release in July.

[bsdcat]

@cyoung ^

[cyoung]

Ref #655. Re-check ForeFlight and WingX.