prA Pressure Altitude versus relative altitude

[swede...@gmail.com]

So I have a Stratux  (actually openflightsolutions  https://www.falkenavionics.com/adsb) in and also a panel mounted Appareo adsb - out (1090ES).  In the Stratux I added my ownship Hex Code as I also added it in the AVARE application.  When I fly I do have gps info from the Stratux box, so I expect to have +/- altitude relative to mine on AVARE but I don't I have only absolute Pressure Altitude.  What am I doing wrong, is there another setting I should change...

Peter

[swede...@gmail.com]

I flew today, and it seemed to work after the Stratux box got a gps fix, that seems to be the trigger...

[Jim English]

Re: " it seemed to work after the Stratux box got a gps fix"

When I have something whacky like this happen, I try to remember that many things are Geo-Referenced in Avare, and as such if you haven't yet established your Geo-Location (because you haven't locked on to enough satellites to establish your position on the surface of the globe), how can you expect things that require your specific location as a reference to work since it doesn't know where you are yet. Another example I see in my aircraft is when the ADS-B receiver hasn't yet established my definitive location on the surface of planet earth yet, but has established a wifi connection with my tablet running Avare, I find that the Avare screen seems to flicker and jump all over the place seemingly searching for an appropriate map to display. However, once the GPS lock is established and my position is known the display settles down showing my position correctly on the correct map. I have 2 different ADS-B receivers in my aircraft (a panel mounted Stratus, and a window-mounted StratuX which I built), each with different antenna mounting locations, and I consistently see that one receiver will lock in the satellites very quickly while the other one takes some time. So, the takeaway lesson, for me, is not the jump to too many conclusions about what is, or is not, working until I'm sure I have a good GPS location resolution because a lot of things are referenced from my current location as defined by the GPS.

[swede...@gmail.com]

I think you are missing my point, it should NOT need a gps fix to do relative altitude, why you might ask....  Well if you read my initial part I added My Hex Code for my airplane which my appareo puts out, thus when receiving the data stream it knows which is my aircraft and also position, that is outputted by my Appareo, thus it does NOT need a gps fix right....

[DrLin]

I think I see the issue: Keep in mind there are 4 different "altitudes" at play here. Also this note assumes that Avare has a GPS fix from Stratux and is receiving traffic. Other cases may differ.

1) Avare seems to compare traffic altitude (ADS-B info from Stratux that relays "height above ellipsoid") with own-plane altitude which is "pressure altitude from Stratux". Basically off by 100 feet or so on the ground and worse in the air depending on the lapse rate. I've modified my Stratux to allow Baro corrections. It sends "corrected" Baro altitude to Avare which is the "Altitude a pilot sees on their sensitive altimeter with local pressure set in the Kollsman window". I can change the barometric setting and see it affect the traffic altitude comparison (it shouldn't, ergo possible feature enhancement request).

2) On the Avare Map page - the "MSL ft" height shown is "height above geoid". This is a GPS derived altitude from a modeled earth "sea level" - not the ellipsoid. This is not used anywhere in aviation.

3) On the PFD page, the altitude tape shows the "baro" altitude reported by Stratux. Unmodified Stratux will send "pressure altitude" seen by ATC but only seen by pilots if you set baro correction to 29.92.

Suggested corrections would be to have traffic height comparisons done apples-apples using "GPS height above ellipsoid" and have the Map page showing "pressure" altitude from Stratux "status message, not height above geoid".

Without a GPS lock, the data is missing to determine traffic relative altitude, distance, closure rate, etc.

DrLin

[Jeffrey Ross]

I'm not 100% sure what problem you are seeing but see my comments in line

Jeff

On 6/5/22 2:42 PM, DrLin wrote:

I think I see the issue: Keep in mind there are 4 different "altitudes" at play here. Also this note assumes that Avare has a GPS fix from Stratux and is receiving traffic. Other cases may differ.

1) Avare seems to compare traffic altitude (ADS-B info from Stratux that relays "height above ellipsoid") with own-plane altitude which is "pressure altitude from Stratux". Basically off by 100 feet or so on the ground and worse in the air depending on the lapse rate. I've modified my Stratux to allow Baro corrections. It sends "corrected" Baro altitude to Avare which is the "Altitude a pilot sees on their sensitive altimeter with local pressure set in the Kollsman window". I can change the barometric setting and see it affect the traffic altitude comparison (it shouldn't, ergo possible feature enhancement request).

Stratux does not receive a pressure altitude, as it does not have a pressure transducer.  IF you have a GPS signal on on your Stratux unit, and I would suggest you set your table to use the GPS from the Stratux as well so they are on a common source, Avare will report your distance from other targets based upon your and theirs GPS derived altitude, if you do not have a GPS or don't have a valid signal you'll see the altitudes listed as "PrA" which means you are just receiving their reported pressure altitude.

2) On the Avare Map page - the "MSL ft" height shown is "height above geoid". This is a GPS derived altitude from a modeled earth "sea level" - not the ellipsoid. This is not used anywhere in aviation.

This is why you do not use a GPS derived altitude in place of your aircraft's altimeter, there are databases that allow you to adjust the GPS altitude to a MSL altitude, but those are only as accurate as the database.

3) On the PFD page, the altitude tape shows the "baro" altitude reported by Stratux. Unmodified Stratux will send "pressure altitude" seen by ATC but only seen by pilots if you set baro correction to 29.92.

Again the Stratux does not have a pressure transducer so this is based upon a GPS derived altitude.

Suggested corrections would be to have traffic height comparisons done apples-apples using "GPS height above ellipsoid" and have the Map page showing "pressure" altitude from Stratux "status message, not height above geoid".

This is currently done, again set your tablet to use the GPS from your Stratux

Without a GPS lock, the data is missing to determine traffic relative altitude, distance, closure rate, etc.

Agreed, you must have a valid GPS position source to determine you relative position from other traffic.  I am not sure how the FAA sends the information for none participating aircraft (those without ADS-B out) via TIS-B and how it is displayed, in my area of the country were I am primarily flying it would be very unusual to find an aircraft that is not ADS-B out equipped as I'm flying in the north east corridor, based 13 miles from EWR and routinely fly through Boston, New York, Philadelphia, and Washington DC which cover 8 airports surrounded by a Class B and a handful of Class C airports....lucky me :-(

DrLin

On Tuesday, May 10, 2022 at 10:57:10 AM UTC-7 swede...@gmail.com wrote:

I think you are missing my point, it should NOT need a gps fix to do relative altitude, why you might ask....  Well if you read my initial part I added My Hex Code for my airplane which my appareo puts out, thus when receiving the data stream it knows which is my aircraft and also position, that is outputted by my Appareo, thus it does NOT need a gps fix right....

On Thursday, April 21, 2022 at 1:56:01 PM UTC-4 jengl...@gmail.com wrote:

Re: " it seemed to work after the Stratux box got a gps fix"

When I have something whacky like this happen, I try to remember that many things are Geo-Referenced in Avare, and as such if you haven't yet established your Geo-Location (because you haven't locked on to enough satellites to establish your position on the surface of the globe), how can you expect things that require your specific location as a reference to work since it doesn't know where you are yet. Another example I see in my aircraft is when the ADS-B receiver hasn't yet established my definitive location on the surface of planet earth yet, but has established a wifi connection with my tablet running Avare, I find that the Avare screen seems to flicker and jump all over the place seemingly searching for an appropriate map to display. However, once the GPS lock is established and my position is known the display settles down showing my position correctly on the correct map. I have 2 different ADS-B receivers in my aircraft (a panel mounted Stratus, and a window-mounted StratuX which I built), each with different antenna mounting locations, and I consistently see that one receiver will lock in the satellites very quickly while the other one takes some time. So, the takeaway lesson, for me, is not the jump to too many conclusions about what is, or is not, working until I'm sure I have a good GPS location resolution because a lot of things are referenced from my current location as defined by the GPS.

On Wednesday, April 20, 2022 at 3:26:06 PM UTC-4 swede...@gmail.com wrote:

I flew today, and it seemed to work after the Stratux box got a gps fix, that seems to be the trigger...

On Wednesday, April 20, 2022 at 10:38:29 AM UTC-4 swede...@gmail.com wrote:

So I have a Stratux  (actually openflightsolutions  https://www.falkenavionics.com/adsb) in and also a panel mounted Appareo adsb - out (1090ES).  In the Stratux I added my ownship Hex Code as I also added it in the AVARE application.  When I fly I do have gps info from the Stratux box, so I expect to have +/- altitude relative to mine on AVARE but I don't I have only absolute Pressure Altitude.  What am I doing wrong, is there another setting I should change...

Peter

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/apps4av-forum/1a5e5e67-2220-4285-978d-a7b3c9e6a76bn%40googlegroups.com.

[DrLin]

Thanks for the quick reply Jeff,

I would like to mention a few things: Stratux does/did have a pressure sensor. It's on a $15 component called "Stratux AHRS 2.0 - Sensors and Fan Controller/Raspberry Pi ICM-20948+BMP280". The BMP280 is a very sensitive pressure transducer and Stratux code supports it. Maybe your statement could be "not all Stratux units have a pressure transducer". 

When I use my Stratux with Avare, the statements I made earlier are correct.

My pressure altitude supplied from the Stratux is being used by Avare to compare altitude of ADS-B reported traffic, including TIS-B traffic. (I will double check the parsing and retransmitting of the messages in the Stratux app to verify whether there is a way to know if the reported altitude of traffic is GPS based or Altitude encoder based. Ideally, altitude comparisons would be using the same references.)

My pressure altitude (corrected with local pressure in my case) is being shown on the PFD altitude tape.  (good thing)

My "GPS altitude above geoid" is being shown on the map page even though pressure altitude is available to Avare. (not a good thing IMO)

My tablet is and has been set to use the GPS info from the Stratux.

BTW- TIS-B messages showing non-ADS-B traffic are broadcast over ADS-B and they would likely be showing encoder altitude since that's what their mode-S or, gasp, mode-C transponders report. ADS-B altitudes reported by "FlightAware" don't match the altitudes I see in the cockpit since they show GPS derived height about ellipsoid AFAIK. 

DrLin

[mcso...@gmail.com]

I've found the most recent exchanges interesting, and it's stimulated comments and questions.

1st, I'm confused by all the talk about ADSB (on the FAA's side) reporting GPS altitudes to anyone; aircraft, FlightAware, or anyone else. Mode C, Mode S, and ADSB-out all require an atmospheric pressure transducer-encoder to report altitude. I realize that a GPS outputs computed altitude (as long as it's seeing at least 4 satellites), but I've never seen any reference in FAA docs indicating that ADSB uses anything other than pressure altitude. Did I miss a memo?

2nd, this does raise a question about Avare's traffic altitude display. Since Avare itself doesn't have pressure altitude available to it, does this mean that any traffic altitude  displayed by Avare will be off by the difference between pressure altitude and local GPS-derived altitude? It would seem that it does. I've flown with a Stratux in the past, but I'm currently flying with a uAvionix Echo (does both out & in), which feeds traffic via serial port to the EFIS, and via wifi to a tablet running Avare. I've never thought to compare displayed altitudes of the same traffic on the EFIS & the tablet. That's a task for my next flight, I suppose. I might expect my setup (since I've got in/out) to show correct traffic altitudes on both displays, but if using a Stratux for 'in', I don't see how Avare could display accurate traffic altitude.

Last, on DrLin's modified Stratux using pressure altitude: DrLin is likely aware of this, but just in case... unless the Stratux pressure sensor is plumbed into the a/c static system, it's unlikely that it will report the same altitude as the a/c altimeter (or transponder encoder), and the error will likely change with airspeed, cabin ventilation settings (assuming the Stratux is in the cabin), etc. Errors might be insignificant, but in some cases, can be very significant (50-100 feet or more, in some cases).

[DrLin]

I did a little more digging and want to share my findings, plus I'll provide simple explanations and pointers.

For my original question/concern #1 - I read the code that Stratux uses and the code Avare uses and can say pretty confidently that the altitude difference that is shown on Avare's main page (Location View a.k.a "moving map") is the target plane's reported Baro altitude against the "own plane's" reported Baro altitude.  At least for my Stratux which has the AHRS/Fan add-in.  Boring details follow, feel free to skip down:  ADS-B broadcasts may show Baro pressure-altitude or they can show GPS derived altitude. There are different ADS-B message headers, and messages #17, #18, TIS-B, Transponder Mode C and Mode S messages all have "Baro" altitude in the message. Messages #22 - #24 contain GPS derived altitudes.   ADS-B messages are converted to GDL90 messages when being sent from Stratux to Avare.  The GDL90 messages report altitude as "Baro" - so that's what Avare deals with.  The best "memo" I've seen describing the ADS-B message contents and evolution from the days of Mode A transponders is "The 1090 MegaHertz Riddle" by Junzi Sun.  The GDL 90 protocol messages are in a Garmin document, "GDL 90 Data Interface Specification."  Both are easy to find online.

For concern #2, the Location View of Avare has "Corner Text" on the top of the page showing "MSL ft".  Although my "own plane" information is available and accurate, when Avare prepares the text for the "infolines", a fresh altitude is fetched from GPS parameters. So, Avare is showing a GPS derived altitude MSL.  I would recommend to the Avare developers to use the baro altitude when available instead since that's what pilots can see when they fly, and the traffic altitudes are also "baro". Boring details: you can see the additional fetch of altitude in the "infolines" JAVA under "utilities" - around line 445 you will see mAltitude being reassigned to a GPS value - getGPSparams().getAltitude .... I would rather have the baro altitude shown on that location view as it would match the PFD page reducing confusion.  Or at least change the text to be "MSL ft baro", "MSL ft Geoid", or "MSL ft WGS-84" depending on its source.

For concern #3, The PFD page is showing Baro altitude on the tape. That's fine, leave it as-is. Boring details:  My Stratux has the AHRS/fan controller add-in card, which many other people may have too. With this card installed, there is more information than just traffic being provided to the Avare. Additional info includes Baro and GPS altitude at finer resolution, orientation in 3D space, etc.  I added the ability to "set the altimeter"  on my Stratux so the Baro altitude will match my sensitive altimeter's display. I can reset to 29.92 inches to get back to "pressure altitude" at any time.  Yes, I know that without a good static pressure source and calibration I should continue to rely solely on my IFR cert sensitive altimeters when necessary.

And as for Avare's display of altitude as "PrA" - I like to think of it as a reminder that my altitude isn't know to Avare at that moment. Altitudes shown are directly from the ADS-B/TIS-B messages which are Pressure Altitude. When my altitude is available to Avare, the display changes to show the "difference" in altitude above or below me with a + or - sign and at least two digits of altitude in "hundreds".  See the code in the "Traffic.Java" file around line 167.   

DrLin

[RV7 Builder]

Great info! Thanks for doing all the research; quite helpful for those of us who's programming skills hearken back to flipping rows of switches.

I can see how the Stratux can listen to own-ADSB-out to get pressure altitude (as long as Avare knows own-ID). What about the guys that only have the Stratux for -in?

Thanks for the education. :-)
Charlie

You received this message because you are subscribed to a topic in the Google Groups "Apps4Av Forum" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/apps4av-forum/RhQ203ejUs4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to apps4av-foru...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/apps4av-forum/d5f581a5-9571-49ba-b945-5fbb88a4a0dan%40googlegroups.com.

Virus-free. www.avast.com