Altitude Accuracy

[Moffrestorer]

Hi Lee,

I think your Pilotaware Initiative is brilliant, especially as visibility of non-transponder equipped aircraft will at last be possible if your device gains wide acceptance.

My question concerns altitude accuracy of "targets" on the GPS display.  If the displayed target is from an ADS- B transponder, the encoding altimeter is referenced to QNE (1013mPa), and the data relates to Flight Level (FL). If the target is transmitting via P3I, then the altitude will be derived from the GPS unit. This depends on the user dialling in an offset, such as altitude of departure airfield in Easy VFR, to "calibrate" the GPS altitude against the WGS84? geoid. As such, both targets altitude display will be independent of air pressure changes that will affect altimeter settings.
Does your software convert FL to altitude without taking into account the barometric pressure e.g.FL 25x100ft is taken simply as 2500'altitude? Or is it the GPS software that converts this? The P3I targets should presumably be on the same reference as each other, the geoid. Do GPS and Glonass and whatever Europe comes up with, use the same geoid?
If the altitudes from the various targets sources cannot be directly related, caution will need to be used when interpreting the display. At least we will know that there is something out there,in which direction to look, and an approximation of height differences!

Regards,

Chris

[Admin]

Hi Chris,
Interesting, I may need to think on this a little ...

For now, altitude is taken directly from the Location Services API on the iOS device, so it is completely independant of PilotAware.
The data is basedupon whatever iOS uses as its reference, this could be the internal GPS, or it could be an external GPS, such as Garmin Glo or BadElf.

I would hoped that the engineers at Apple (and indeed Google/Android) would have taken this into account when interfacing the GPS information through their Location Services API.

In the case of ADS-B, I am not sure how this would relate I have to be honest.
Just to clarify, are you saying that If I connect my GPS source to my transponder, then the altitude component is filtered out, and replaced by the altitude calculated by the transponder, and therefore some mismatch can occur - I think this is what you are saying ?


Thx
Lee

[tj80]

I think what Chris is saying is that the altitude reported by Mode-S will be based on the standard pressure of 1013hPa.  If the real pressure is different (more likely than not!) then altitude will not be accurate unless adjusted based on 78ft per hPa (if I remember my Met correctly).  GPS altitude should not be affected by pressure.  So the scenario could be that an ADS-B target is shown as above/below when in fact it is at the same level as you.

Cheers,
Tim

[Alan Walker]

One hectopascal is about 30 feet

[tj80]

Oops, you're absolutely correct of course!     For 78ft read 28ft!

[Moffrestorer]

Hi  Lee,

I think it's most likely regarding ADS-B, that the altitude component will be filtered out.

Our Becker mode S has an encoding altimeter that is connected to the aircraft static port, and provides serial data to the unit. This data will be transmitted to ground stations and other aircraft. I'm certain that whether Mode C or S, the output of any transponder will be relative to QNE pressure setting i.e. Flight Level. The GPS input seems to relate solely to airborne/surface position messages, airborne velocity message and extended squitter aircraft status message (this will be the unique aircraft identifier code).

For every 1mPa difference in regional pressure there will be 30 feet error. Assuming a QNH of 1030mPa then this is an altitude difference of 500 feet.

Maybe this isn't too significant in the overall scheme of things, because for my own purposes, I want to know which area of sky I need to look at to see conflicting traffic. (I have a Zaon MRX that gives target alerts based on timing transponder and Flarm transmissions to give relative height, distance and whether target is climbing descending, but crucially it doesn't give azimuth or bearing info. I believe the more expensive XRX model only gives quadrants of azimuth as a bearing.)

Regards,

Chris

[Admin]

Found this description
http://www.faa.gov/nextgen/programs/adsb/faq/

In fact, ADS-B reports two kinds of altitudes: barometric and geometric. Barometric or pressure altitude is the one pilots know best – this is the altitude that is displayed on the altimeter in the aircraft. Geometric altitude is calculated by GPS (Global Positioning Satellites) as the height of the aircraft above the earth ellipsoid. These two altitudes are not the same, but having both allows for applications that require one or the other as an altitude source and provides a means of verifying correct pressure altitude reporting from aircraft.

SBS1 allegedly reports the Geometric, so this would seem to be the same value used at both ends
Although I think this requires further investigation
Thx
Lee

[Andy Fell]

I have never found GPS GEOID altitude to be hugely different to QNH, it's usually within about 200ft. Although quite rightly altitude isn't something that GPS is good at unless using WAAS/EGNOS correction (DGPS).

I suppose one of the interesting points is that if you are reporting FLs back to SD (as you'd be receiving from ADS-B transponder altitude encoder - pressure referenced to 1013mB), then you need to have a way of correcting it for QNH (just like NATS do with their radar)... because on SD you'd be comparing a FL (not QNH) to a GPS GEOID (a psuedo QNH).. this could introduce considerable error, especially on days with exceptionally low or high pressure.

If ADS-B has Geometric altitude available, this would be the one to take and feed back to the tablet.

Very good point Chris!

although I suppose at the end of it all, pilotaware is there to give a reasonable early warning... you should have either spotted it by eye or with the help of pilotaware by then (otherwise time for a new pair of specs!)

rgds
Andy

[Admin]

Hi All,

Having read up on this I believe this to be the current position.

ADS-B transponders can supply Barometric and GNSS altitude, in other words the altitude
based upon QNE 1013.25mb, and also altitude reported by the GNSS.

In many cases it appears that the GNSS component is missing from the data, BUT the QNE is always
present.

I have provided an entry in the http interface to allow you to enter the QNH, this is then used to translate
the barometric altitude reported by ADS-B to the equivalent GNSS altitude.
This is a first step solution.

In parallel, I am in the process of adding a barometric pressure sensor to my Prototype board, so that
this calculation can be managed without the user having to dial in the QNH.

The http interface can be maintained to provide backwards compatibility to early versions without a
pressure sensor.

Thx
Lee

[trapdoor]

Bad Elf Pro+ allows you to use either GPS derived height or barometric using it's on-board sensor, but it's a bit convoluted to calibrate it each time so I tend to stick with GPS.

Certainly be keen to see a bar sensor on the PilotAware and with the 'Slice Prototype board' there is plenty of space and pads to add things like this, and depending how it's interfaced to the Pi, the connectivity is already there.

[Admin]

Hi All,

OK, Solution implemented for this issue, I now have a version of PilotAware with a Barometric Pressure Sensor fitted, and just completed the software/kernel modifications.

So height from PilotAware -> ADS-B traffic will use the Pressure altitude based upon 1013.25mb. This can either be calculated by the use of the builtin Barometric Pressure Sensor, or if no pressure sensor is available, it will use the QNH value (entered through the web interface) to calculate the Pressure Altitude based upon the QNH/GNSS

Height calculations from PilotAware -> PilotAware is always done using GNSS

Pressure sensor used is this one


Thx
Lee

[falcoguy]

Hi Lee

I am presuming there is no room in the existing box to fit the additional barometric pressure sensor - that is the curvy side one pictured.  I guess it will need new headers etc?  I don't think we have much room in our boxes anyway!

I see there are 'standard' barometric units for use in arduino and Raspberry Pi on the net - I think one is BM180?

dave t

[Admin]

Hi Lee

I am presuming there is no room in the existing box to fit the additional barometric pressure sensor - that is the curvy side one pictured.  I guess it will need new headers etc?  I don't think we have much room in our boxes anyway!

I see there are 'standard' barometric units for use in arduino and Raspberry Pi on the net - I think one is BM180?

dave t

This will easily fit in the standard box, it is tiny

[falcoguy]

Stupid question

Does this mean that if you have an ADSB equipped transponder already fed by an Altitude Encoder the barometric pressure sensor isn't needed - because it is only used if feeding data from pilotaware into a mode s transponder, or is the situation as below

In order for altitudes shown on Skydemon to be comparable with a received ADSB signal the pilotaware will require a barometric sensor (or the QNH updated manually in the web page)?

Dave T

[falcoguy]

Lee
Spoken with the boss (John Parker) - we are going to add the barometric sensor into all our boxes - when you are able to give us the pin outs etc.  We have ordered the magic bit (x10)!!!!!!!
Dave t