ADS-B Traffic Altitude

[Ed L]

I've been using the app for a while now, primarily on my Samsung 4, 7" tab but also on a small LG pay-as-you-go phone I got from WM (and I don't pay as I go; I just use wifi; I have this mounted to the left of my panel in my scan and have no maps on it; I use it just for traffic, radar weather, and obstacles; not bad for $30 with the cheapo WM suction mount!).  I have ADS-B in and out via a FreeFlight RANGR and things have worked very well until recently.  My plane was down for about 2 months for a new engine (a 6" crack in the case!  Glad the A&P found it and not the NTSB!).  Yesterday I was putting time on the new engine and had both inputs running.  The LG didn't have updated Avare software but the SamTab did.  The SamTab CONSISTENTLY showed targets about 1000 ft lower than the LG did and it had a + sign next to the altitude, which I assumed was the height above me, not MSL, and the LG did not.  I updated the software on the LG last night and went flying again today.  Both now show about the same altitudes for targets, both have the + sign - and both are off by about 1500 feet, best I can tell, from "reality", if you take the reading to be MSL and not height above or below me.  Examples: I was at 5000 by the altimeter, 4844 by the tablet GPSs, and traffic at 4500 was called out by ATC and showed as +2688 on the screen.  And it showed blue, which indicated it was well above me (when it was actually 500 below and should have been red, I believe).  Later traffic was showing +368, was 2200 per ATC, and I was still 5000.  Later again one was showing +5500 and was 7000 and another showed +2086 and was 3,500. 

I've looked all through the settings to see how to change how traffic can be displayed (MSL vs. referenced to my altitude) and can't find anything. 

Any insights?  Thanks!

/Ed

[Jon McLin]

Yes, something's awry with reported altitudes in the latest Avare.  I'd intended to report it and life got in the way.

On our Christmas trip to Houston (from Phoenix) I noticed the new traffic display, and that the altitudes did not make sense.  All three of my devices were updated before the trip (we left on the 19th).   We use an iLevil 2 SW ADS-B receiver, and my wife runs FlyQ EFB on her iPad.  FlyQ reports traffic in delta altitude.  For every target I compared between the two, I could make no sense of the Avare-reported altitude (as either relative or absolute).   This was rather disconcerting in busy airspace when FlyQ is showing targets at/near our altitude (and ATCs calling them), and Avare is showing them either 3000' below us (we were at 9500' in the San Antonio area), or 6500 feet above us, depending on how you interpret that + sign.  Either way, it did not match what FlyQ, ATC, or our eyeballs were telling us.

[Zubair Khan]

Thanks for reporting. Next time, could you record the input? Your altitude on altimeter at the time of recording, and weather conditions like pressure and temperature at SL.

The altitude seems like a nagging issue. Not all ADSB providers are treating it same.

The traffic is reported in pressure altitude, and if the ADSB receiver does not provide pressure altitude, then its hard to find altitude difference.

-Z

On Sat, Jan 2, 2016 at 6:54 PM, Jon McLin <av8...@gmail.com> wrote:

Yes, something's awry with reported altitudes in the latest Avare.  I'd intended to report it and life got in the way.

On our Christmas trip to Houston (from Phoenix) I noticed the new traffic display, and that the altitudes did not make sense.  All three of my devices were updated before the trip (we left on the 19th).   We use an iLevil 2 SW ADS-B receiver, and my wife runs FlyQ EFB on her iPad.  FlyQ reports traffic in delta altitude.  For every target I compared between the two, I could make no sense of the Avare-reported altitude (as either relative or absolute).   This was rather disconcerting in busy airspace when FlyQ is showing targets at/near our altitude (and ATCs calling them), and Avare is showing them either 3000' below us (we were at 9500' in the San Antonio area), or 6500 feet above us, depending on how you interpret that + sign.  Either way, it did not match what FlyQ, ATC, or our eyeballs were telling us.

--
You received this message because you are subscribed to the Google Groups "Apps4Av Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to apps4av-foru...@googlegroups.com.
To post to this group, send email to apps4a...@googlegroups.com.
Visit this group at https://groups.google.com/group/apps4av-forum.
For more options, visit https://groups.google.com/d/optout.

--

Zubair Khan
apps4av.com
zk4u.blogspot.com
Sudbury, MA 01776

[Jon McLin]

Sure.  In this case I can get you pretty close.

In all cases, the altimeter settings we were flying with were in the range 29.8 to 30.1.   The specific example I cited was with an altimeter setting right around 30.00 (that was on the 19th, about 2PM local time about 70 miles or so north-east of San Antonio. (Once upon a time I had a photographic memory, but it is not so good in my old age.  But it is still pretty good.)  Temperatures were well about standard, roughly 8C in all cases.  That was a (not relevant) significant temperature inversion on the return flight,   But this represents hundreds of feet of error, not thousands.

iLevil provided me an ICD for the iLevil 2 we were using, which states that in recent versions (which we have) it produces results in MSL (HAE corrected for Geoid) if reported by the traffic.  TIS-B will always report Pressure Altitude (it's reporting the Mode C response), and everything I've read says virtually all aircraft will report Pressure Altitude if available (that's what my transponder does).    All that said, the difference is rarely huge:  MSL vs. Baro altitude should be pretty close, within a hundred feet or so, and the pressure altitude should be within 1000' in any reasonable situation.

From iLevil ICD:   (btw: Pressure altitude is available for Ownship reports by detecting my own call-sign in a Traffic Report. Since we have ADS-B out, we'll always get that.)

* Ownship report and Traffic report in the GDL90 interface specifies Pressure Altitude as
the reported source of altitude. The iLevil does NOT report Pressure altitude on the
Ownship report, instead it sends an invalid code 0xFFFF (pressure altitude is sent using
the AHRS message if such information is available, see section 5.0). For a reliable source
of altitude, developers must use the Geometric Ownship altitude message instead (height
above WGS-84 ellipsoid).
On firmware version 3.1 and up, height above sea level (MSL altitude) reported by the
GPS is included in the Ownship report substituting the invalid code 0xFFFF. Please know
that not all iLevils in the field have version 3.1. For this reason is recommended to use
the Geometric altitude and add the Altitude difference broadcasted in the GPS Status
message (see section 13.0)
** The Traffic report used by the iLevil will contain GPS Geometric altitude (versus
Pressure Altitude) as default unless the aircraft is reporting Pressure Altitude as the only
source of Altitude available.
*** The Geometric Ownship Altitude (or Ellipsoid Altitude) is based on height above
WGS-84-ellipsoid, thus contains irregularities when compared to MSL because of the
difference between the actual shape of the earth and a perfect ellipsoid.

[Jon McLin]

Oh, and for that specific example, we were at 9500', as was most of the eastbound flight.   I didn't memorize similar examples on the return as the weather and other factors demanded my attention.  But I did note similar behavior, flying mostly at 8500 with some time at 6500 and 10500. 

Next time I'll take some pictures.

Jon

[Ed L]

My numbers were as I shared. OAT was about 40F and altimeter was about 30.35.

This was a definite change. It was working fine in the past. Not sure what the + or - sign means (I saw traffic at - altitudes) and assumed it was supposed to be relative to mine by that was definitely not the case. Personally, I'd prefer MSL for traffic but if this can be resolved I could see a user-selectable option of MSL or relative altitude being desirable.

Thanks for looking at this!

/Ed

[Ed L]

Hi Zubair

   I'm new at this.  I tried recording the data on the IO (clicking the "save" button) and took a few screen shots a few times during a flight today.  Not sure if this is what you wanted or if it's helpful. I was at 5000 MSL when the pix were taken. 

   Again today the problem recurred.  ATC called traffic at 4400 and it showed as +2612 on Avare.  Another one was 5500 and showed as 3737.  Basically, at least today, Avare was off by about 1800ft from the pressure altitude seen by ATC.

/Ed

[Zubair Khan]

Thanks Ed

Will take a look.

I read somewhere that for traffic altitude to work properly, the ADSB receiver must have a pressure sensor in it. I doubt the frugal ones have it.

Zubair

[Jon McLin]

I was going to post on this separately, but this is a good time to throw this out there:

ADS-B traffic altitudes *might* be produced against any of four different reference levels.   But, except in extreme circumstances, the differences will be in tens or hundreds of feet; in extreme circumstances, perhaps just over 1000'.  Iirc, the ADS-B messages (over the air, not on the brain-dead GDL-90 interface) indicate which of these is present.  Unfortunately, the GDL-90 interface does not indicate the altitude type, and has unfortunately been extended to an application where it is entirely inappropriate.  That is contributing to this confusion.   But, as noted above, it CANNOT contribute errors more than a few hundred feet typically, and roughly 1000' absolute worst-case.

While altitude can be reported AGL (which is entirely local and useless except for "am I about to land or crash?" info, and of marginal utility even there), or MSL, for the purposes of this discussion we are referring to altitudes which represent *elevation* above (some) reference sea level.  This is how I believe most pilots are trained to interpret altitude as a general rule.   The measures or indicators of reference/scale for these altitudes are:
-   Pressure altitude.  This is the altitude that all transponder equipped aircraft report, determined by barometric pressure *assuming* 29.92 inHg at sea level.  This is what an aircraft encoder will produce, and therefore it is what virtually *all* aircraft should transmit on ADS-B, even though they may have a GPS.  While some portable ADS-B receivers have pressure sensors which might provide this, many/most have no means to know this, unless (a) receiving aircraft is either ADS-B Out equipped or the receiver detects 1090 Transponder transmissions, AND (b) the manufacturer (or software provider) has provided a means for the operator (that's you, the pilot) to enter your tail number so you can scarf the pressure altitude off of the over-the-air Transponder or ADS-B transmissions from your aircraft.   *All* TIS-B transmissions can be expected to use this altitude, because that is required by current ATC regulations globally.  TIS-B does not reproduce ADS-B; it reproduces a signal derived from the XPDR Mode C (or Mode-S equivalent) response.
-   Baro Altitude.  This is simply the pressure altitude corrected for the local, current altimeter setting, to to align a pressure altitude at a particular location with a surveyed actual altitude.  This is what you the pilot read on the altimeter, and is what we in the US are required to use for flight altitude in other-than-Class-A airspace.   I believe it's highly unlikely you'll ever see this  in a traffic report message, since it adds complexity and provides no value.
-   HAE (Height Above Ellipsoid).  This is a GPS geometric altitude derived from (a) the distance from the earth's center and (b) a hypothetical ellipsoid which is a flawless (no local distortion) averaging of how altitudes are actually above the earth.   The "ellipsoid" results from the earth spinning, which causes it to stretch at the equator.  But because the earth's mass is not uniform  (there are big chunks of heavy rock floating on the mantle  in places like the Himalayas), and the gravity derives from mass, height above ellipsoid will vary from
elevation above mean sea level by the degree to which local mass "pulls" the sea level towards the center of the earth, causing it to deviate from that mathematically-perfect "HAE".   An unsophisticated non-certified ADS-B out transmitter might produce such a signal - the ADS-B standards allow for it, but I doubt one could get such an installation past the FAA.
-   MSL, or "Geoid".  Because the distortion of earth's gravity is relatively static and known, it is possible to correct for it.  Some/many GPS apps attempt to perform this correction - they take the GPS HAE, and use the GPS location to lookup a deviation (Geoid) offset to convert to MSL.  I believe I have read (but not verified for this post) that the global extremes of deviation (both + and -) are in southeast Asia, with magnitudes of perhaps 200 feet or less.  I suspect a GPS MSL value so-corrected is the most accurate altitude you can get. 

All of the above differ.  MSL and Baro are probably *reasonably* consistent (tens to hundreds of feet) in most circumstances.    But HAE to Pressure could be off by 1000' or even more, and easily 500' in day-to-day operation globally.    Pressure is almost universal  whereas HAE is easy.   (i don't think, but have made no effort to verify, that the maximum errors for HAE and Pressure altitude could reasonably be expected to coexist.  If they did, errors might approach 1500' or so.)

Summary:
-   in a perfect world, all devices/apps would report a single altitude, such that a simple difference calculation would provide the altitude difference.  That's EXACTLY why surveillance radar uses pressure altitude - by using a fixed reference not affected by individual pilot action, ATC had a common reference plane for assessing where an aircraft was operating.  Unfortunately, there was absolutely no adult supervision during the development of ADS-B, and we got a maximally-dysfunctional system.
-  Altitude errors with ADS-B using GDL-90 can reasonably be expected to be a few hundred feet, but could be much larger, up to 1000' or even a little more as local altimeter settings deviate from 29.92.
-  If a non-GDL-90 interface is available which provides an indication of the altitude type (as is provided by ADS-B) this should be used by the application. 
      -  Pressure altitude is preferred since virtually all meaningful targets will use this. (Notably, TIS-B)
      -  Applications can get pressure altitude on aircraft by capturing ownship outputs (1090 Mode C, Mode S, ES, or UAT will ALL work if the receiver reports it to the application.)
      -  Absent Pressure Altitude, MSL altitude should be used.  This can be derived from GPS HAE using available Geoid models.

[Ed L]

Hi Zubair

First, I kinda doubt the FreeFlight RANGR, a certificated system, is a "frugal" one. Not at $3500 on sale - plus install! ;)

But more importantly, things seemed fine not long ago. I think release 7.1.1 caused the change?

/Ed

[Dennis]

Zubair:
 I try to run an older versions of AVARE on my cellphone, a MOTO G, and a more current version on my N7.  That way, I maintain a known backup until the latest version is stable.  I currently have ver 7.0.2 on my MOTO G, and ver 7.1.0 on the N7.

I also am using FreeFlight's RANGR system, which is a fully compliant 2020 ADSB package.  I have commented in the past about odd MSL altitude reports on my AVARE MAP page.  I was flying yesterday and checked my versions of AVARE against EdL's comment.

I found none of the odd behavior with the altitude reporting that EdL experienced. 

I see the current version is 7.1.2, so the problem must be with 7.1.1 or 7.1.2. 

An additional question.............
I have confirmed with FreeFlight, their system does provide Ownship Pressure Altitude, and Ownship GPS Altitude in the serial feed to displays and the wireless outputs.  My question is, Is it possible that AVARE is pulling the data incorrectly from the serial data stream, or does each manufacturer develop their own "proprietary" serial data stream and thus, make it difficult for software, like AVARE, to find and channel the data correctly?

Thanks for the GREAT SUPPORT.

Dennis

[Zubair Khan]

Hi Dennis
I think I tested with your bin recorded file before submitting changes.
I can use GPS altitude when pressure altitude is not available but that is as much dangerous as it is now.
Are you saying 7.1.2 works for you ?
Thanks
Z

--

[Ed L]

Hi Zubair

To clarify for me, the problem DOES seem to be with 7.1.2. That's what was running on my SamTab when I first noticed the issue - and an older version was running on the LG which didn't have problems. Now both are running 7.1.2 and both have the problem.

I said I think 7.1.1 may be the issue based only on what I saw as the changes with that version. It could also be a problem with the associated update to the IO. Basically there is a problem with the current version. Not sure which version actually caused it (I personally wonder about 7.1.1) but it's still there.

Hope that helps.

/Ed

[Zubair Khan]

Does anyone here having issues have ADSB out? I asked Skyradar and this confirms that you either need ADSB out, or pressure sensor to see correct traffic separation.
This is the response...
___
Hello Zubair, no pressure is being reported.
I use ownship reported altitude and use it as a bias with GPS reported altitude. If system does not have local ADSB out then you out of luck. 
___

I will change the code to use GPS altitude when ownship and out are not available for traffic separation but that will have errors.
Z

[Ed L]

Zubair

Yes, both Dennis and I have ADS-B Out via a FreeFlight RANGR. The RANGR also provides the In.
I did a trip to FL from TX this past week and the problem is still there. For traffic, I simplified things in my mind to "+2, -2": add 2000 to the number on the screen and then subtract 200 as a way to add the 1800ft error that appears to be there. But that's not real convenient, of course.
Come to think of it, I don't recall seeing any radar weather and I was IMC the first leg. Also, winds aloft were missing the whole trip. In fact the long press didn't give much beyond some PIREPs, as I recall. I still have XM Wx on a Garmin 396 so I tend to use ADS-B weather less frequently except winds aloft.
So, this is definitely an issue for planes equipped with Out - at least the RANGR.

/Ed

[Zubair Khan]

Ed  and Dennis

Try 7.1.3 release and let me know.

Thanks

Zubair

/Ed

--
You received this message because you are subscribed to the Google Groups "Apps4Av Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to apps4av-foru...@googlegroups.com.
To post to this group, send email to apps4a...@googlegroups.com.
Visit this group at https://groups.google.com/group/apps4av-forum.
For more options, visit https://groups.google.com/d/optout.

[Chip Curtis]

I was flying with 7.1.3 today and a FreeFlight Rang'r ADSB.  The attitude was still incorrect.  At one point I asked another pilot what his altitude was, he reported 2500' MSL, the same as me.  The display showed blue and about +1500, which was close to the correct altitude AGL.  I was near KDKB and the altimeter was 3012.

[Dennis]

Chip:
The AVARE team is aware of the problem with 7.1.3 and released 7.1.4 yesterday.  I have not been able to try it as my RANGR is at FreeFlight for testing. 

Dennis

On Saturday, January 2, 2016 at 5:14:26 PM UTC-6, Ed L wrote:

[Dennis]

I see there's 7.1.5, now. Thanks to the AVARE team for the rapid response to these bugs.
Dennis

[Zubair Khan]

Thank YOU for helping debug it. Of course with all reports, a recorded ADSB data file is a must or will be guessing here.

Now altitude is set as:

My own altitude = geometric altitude, if geometric altitude not available then = pressure altitude

Traffic delta altitude = pressure altitude, if pressure altitude not available then = geometric altitude, if geometric altitude not available then = tablet's internal GPS altitude

Z

On Wed, Jan 20, 2016 at 10:40 PM, Dennis <n36...@gmail.com> wrote:

I see there's 7.1.5, now.  Thanks to the AVARE team for the rapid response to these bugs.

Dennis

--
You received this message because you are subscribed to the Google Groups "Apps4Av Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to apps4av-foru...@googlegroups.com.
To post to this group, send email to apps4a...@googlegroups.com.
Visit this group at https://groups.google.com/group/apps4av-forum.
For more options, visit https://groups.google.com/d/optout.

[bman]

Is it possible to add the altitude being used to calculate the traffic delta in the dynamic top two lines? It seems my XGPS170 seems to provide data that results in a traffic altitude that is off. If I knew what the My Altitude value was I could do the mental math to make a correction.

[bman]

I was able to test traffic again today with 7.1.5 and using only XGPS170 for GPS...internal switched off.

Traffic reported by I/O was averaging 8400 feet. My Altitude in I/O was 798. Avare showed my altitude correctly at 2617 and traffic at 7593 which I believe was correct.

Switched to internal GPS only with no change in traffic displayed altitude.

[Ed L]

I uninstalled Avare and reinstalled the latest version. Same for the I/O. I went up and appear to still be having issues. I was descending through 11,500 and traffic reported to be "+7500" was at probably 12,000. Earlier, one reported at "+6200", I believe, looked to be at about 4500 vs. my 3000. I'm using the FreeFlight RANGR for ADS-B Out and In and a Samsung Galaxy 4 7" tab and small LG smart phone. Both showed the same. Maybe the way Avare and FreeFlight interact?

I may try reverting to a pre 7.x.x version to see if it all goes back to working.

/Ed

[bman]

If all ADS B receivers receive TIS traffic altitude as MSL(I don't know if that is true), is it possible to simply display that by the target instead of the calculated difference? It seems that may be the root problem.

[Zubair Khan]

Actually traffic is reported in pressure altitude not MSL, according to specifications.

On Sun, Jan 24, 2016 at 10:31 PM, bman <beech...@gmail.com> wrote:

If all ADS B receivers receive TIS traffic altitude as MSL(I don't know if that is true), is it possible to simply display that by the target instead of the calculated difference? It seems that may be the root problem.

--
You received this message because you are subscribed to the Google Groups "Apps4Av Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to apps4av-foru...@googlegroups.com.
To post to this group, send email to apps4a...@googlegroups.com.
Visit this group at https://groups.google.com/group/apps4av-forum.
For more options, visit https://groups.google.com/d/optout.

[Zubair Khan]

Some people are reporting correct operation with latest solution. I guess this is because of incompatibilities between different ADSB solutions.

I cannot do much without recorded data file from IO module.

1. Provide recorded data file

2. Provide pressure in that area (your altimeter pressure setting)

3. Provide call sign of the traffic, its altitude you expect, altitude you saw in the app, your own altitude at that time (from altimeter), your own altitude at that time (from your altimeter)

Thanks

Z

/Ed

--
You received this message because you are subscribed to the Google Groups "Apps4Av Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to apps4av-foru...@googlegroups.com.
To post to this group, send email to apps4a...@googlegroups.com.
Visit this group at https://groups.google.com/group/apps4av-forum.
For more options, visit https://groups.google.com/d/optout.

[Ed L]

(I meant pre-7.1.x; I think 7.1.x is when things stopped looking right for me)

[Doug Ranz]

Jan 25, 2016 @ 1500Z

Alt setting:  30.04

OAT: 29F

Enroute alt:  2300

Avare 7.1.5

Avare I/O:  3.0.6

Nexus 7 w/Latest factory Android

One Plus One w/Latest factory Android

FreeFlight RANGR 978 XVR

All traffic was consistently reported ~1,400' higher than actual altitude.

Also;  in Avare I/O ... the Preferences item no longer displays prefs.

Rather;  it displays:
Avare Connected! ()

---- Output ----

FWIW: ForeFlight was reporting the correct altitude of all traffic.

[Doug Ranz]

I forgot to mention that Avare on the Nexus 7 crashed 4X in 2.5 hours.

[Zubair Khan]

Altitude, we are looking at and should be fixed soon (BTW I think the fore flight software runs with a proprietary receiver, but not with FreeFlight RANGR / others).

Regarding crashes, we need report submitted to be able to fix it.

--

You received this message because you are subscribed to the Google Groups "Apps4Av Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to apps4av-foru...@googlegroups.com.
To post to this group, send email to apps4a...@googlegroups.com.
Visit this group at https://groups.google.com/group/apps4av-forum.
For more options, visit https://groups.google.com/d/optout.

[Doug Ranz]

> BTW I think the fore flight software runs with a proprietary receiver, but not with FreeFlight RANGR / others

Incorrect.

https://www.foreflight.com/connect

-doug

[Ed L]

I THINK the latest release fixed things. Thanks for working this!

/Ed