Mode-S Altitude

[AdePrice]

Ade,

<snip>
I could envisage  a situation where the reverse could occur and the cockpit be at a lower pressure if a Venturi effect is created by airflow passing over the rear of an ill fitting canopy etc.
<snip

Moffrestorer, you are correct and I just came to the same conclusion this morning. I think my cabin pressure is less than ambient (static) pressure because my IAS is overreading   i.e. difference between dynamic and cockpit pressure is greater than dynamic and ambient (static) pressure.

I still think my altimeter is under reading but this must be due to an inaccurate altimeter rather than effects of cockpit  pressure.   I've got some testing to do with GPS and a separate barometric source.

Ade

[Moffrestorer]

Hi Ade,

You can check your altimeter quite easily by setting the current QNH into the Kollsman window sub-scale. The altimeter should then show the airfield height above mean sea level to reasonable accuracy.  Preferably situate the aircraft at the airfield "reference point" for this test as its here that the published height applies.

Regarding the ASI, you could try checking IAS versus GPS speed (speed over the ground) while flying a heading at 90 deg. to the prevailing wind direction at the height you are flying. This should negate the effects of head or tailwinds on your test. You probably need to take into account outside air temperature to calculate the TAS and factor in CAS from your POH for any pitot position errors that might apply. Just doing the first part, IAS versus GPS speed, will give you an idea if your ASI is in the right ball park.

[AdePrice]

I think I've probably got a duff altimeter even though the altimeter reads correctly on the ground.

I'll set QNH on the altimeter; note the difference between QNH alt and average GPS height, climb to 3000' or so in the same locality and measure the difference between QNH alt and average GPS height again.  I know the limitations of using GPS height but it is not too bad provided the GPS antenna has a good view of the sky. (The GEOID undulation is 155' at EGHH and I'm at Newton Peveril)

All Shadow airspeed indicators over-read by about 15% and this is covered by the pilots' manual, mine is not so different in that respect.

P.S. If anyone is interested in checking the GEOID undulation in their locality then consult the AIS web pages for Aerodrome Index - Specific, open the textual data for their chosen airfield and search for "Geoid Undulation" (without quotes), which should be in the "RUNWAY PHYSICAL CHARACTERISTICS" section.

[flying_john]

Lee said:

When comparing relative vertical difference to ADSB traffic, barometric altitude is used, because this is the reference the transponder is using. When comparing to other pilotawares, GPS altitude is used for the comparison, this was an early design decision before the addition of a barometric sensor

My Mode S Txpdr (TRT800) bases its altitude report on 1013 Hp and is fixed. I notice you have a config field to set local QNH. Should this not be set to 1013 permanently rather than altitude referenced to a local QNH value input by the user, since any received ADSB will have Altitude referenced to 1013. - or have I missed something ?

John
EGMF

[Moffrestorer]

Hi John,

If you do not have a barometric sensor in your pilotaware, you can set local QNH in the config field manually. The idea is that this value is number crunched within the unit so that the relative heights from yourself (i.e. from your GNSS height) of ADSB targets (FL based on QNE 1013) and pilotaware P3i targets (their reported GNSS height), are "corrected" (and displayed) using a common "datum". Factored in, is the pressure difference between prevailing QNH and the QNE.

If you have the sensor, the pressure reading is used to achieve this automatically without having to enter the QNH value (I think in this case pilotaware calculates QNH at any height using ambient pressure and your GNSS height. Lee would have to confirm this assumption of mine).

Lee and I did discuss the method of QNH/QNE calculation  via a PM when this thread started. I do not know whether the datum he ultimately uses is GNSS height or QFE (1013.2 hPa).

Its all a bit convoluted and makes my brain ache to think about it!

Regards,

Chris

[efrenken]

...
Regarding the ASI, you could try checking IAS versus GPS speed (speed over the ground) while flying a heading at 90 deg. to the prevailing wind direction at the height you are flying. This should negate the effects of head or tailwinds on your test ...

No, it won't, winds of 000/50 and a heading of 090 with 190 TAS will result in a ground speed of 210 kts.

Regards

Eric

[flying_john]

Lee and I did discuss the method of QNH/QNE calculation  via a PM when this thread started. I do not know whether the datum he ultimately uses is GNSS height or QFE (1013.2 hPa)

Thanks Chris - my thoughts were that it would be better if we all used QNE to align with the reporting from Mode S transponders and there would be no need for a continuous chasing of baro pressure during a flight.


Cheers

John

[Moffrestorer]

No, it won't, winds of 000/50 and a heading of 090 with 190 TAS will result in a ground speed of 210 kts.
[/quote]

Yep Eric, it was pretty daft of me suggesting that. BTW wind speed you chose is replicating the weather outside at the moment!

 Regards,

Chris

[flying_john]

Lee and I did discuss the method of QNH/QNE calculation  via a PM when this thread started. I do not know whether the datum he ultimately uses is GNSS height or QFE (1013.2 hPa).

I would hope he used the same datum as the Mode S transponder - 1013.2 otherwise you would have incorrect height differences reported from conflicting traffic. Likewise it should be normalised for P3i, I think to the same value, otherwise again you have potential for aircraft reporting 200 feet above you but actually at the same height because local pressure difference is 7 Hectopascals.

Anyone know if there is a reason I cant fit an RS232 sub board on the Pi GPIO for connection to my Mode S transponder, instead of using a clumsy lead and adaptor with it built in ?

John

[Admin]

Hi John,

Briefly,
ADS-B Altitude is based upon pressure altitude referenced to 1013.25 hPa
P3I altitude is based upon GPS altitude

For PilotAware we are only interested in relative vertical difference, so .....
if the traffic we compare to is from an ADS-B source, we use our pressure altitude,
alternately when the traffic is from a P3I source we use the GPS altitude.

We are only ever dealing in relative, differences so it does not matter what the source
of the altitude component is, so long as we know its altitude reference

[flying_john]

Aha that's understood, but what is sent to the RunwayHD/Skydemon display to indicate the height of the conflicting aircraft compared with the aircraft I am flying, if it is based on the baro sensor on the PAW then is your reference 1013.2 (same as Mode S).

The way I see it is there are three different heights to consider.
The actual height the aircraft is flying based on its own altimeter set to QNH local aerodrome.
The Flight level broadcast by ADSB based on 1013.2 datum
The altitude based on GPS

How do you normalise all these differing datums so that it makes sense to the pilot i.e if he sees a conflict 200 feet above, how does he know whether this 200 feet is relative to his altimeter the altitude shown by the ModeS display (the TRT shows the FL) or the RunwayHD GPS height.

It only seems to make sense if everyone uses the same reference datum - i.e 1013.2
 
Thankyou

John

[Admin]

Hi John
Confusing isnt it 

Aha that's understood, but what is sent to the RunwayHD/Skydemon display to indicate the height of the conflicting aircraft compared with the aircraft I am flying, if it is based on the baro sensor on the PAW then is your reference 1013.2 (same as Mode S).

As I mentioned, it depends upon what is the conflicting aircrafts reference .
If a packet is received via ADS-B - we compare to the barometric altitude
If a packet is received via P3I - we compare to the GPS altitude

Only the difference altitude is supplied to the navigation device, so it is irrelevent whether we used barometric or GPS for the calculation, so long as we use a common reference. The Navigation device is effectively told +/- nnnnFT relative to our position.

The way I see it is there are three different heights to consider.
The actual height the aircraft is flying based on its own altimeter set to QNH local aerodrome.
The Flight level broadcast by ADSB based on 1013.2 datum
The altitude based on GPS

Well almost, there are in fact only two heights to consider, Barometric and GPS, and for both of these we have a local reference for comparison, from our local Barometric Pressure Sensor, and our local GPS

How do you normalise all these differing datums so that it makes sense to the pilot i.e if he sees a conflict 200 feet above, how does he know whether this 200 feet is relative to his altimeter the altitude shown by the ModeS display (the TRT shows the FL) or the RunwayHD GPS height.

This has already been calculated in the comparison. So if the Navigation reports traffic at +500ft, this was either calculated by comparing Barometric(remote) versus Barometric(local), or GPS(remote) versus GPS(local).
Ultimately, 500ft is 500ft, no matter how it was calculated.

It only seems to make sense if everyone uses the same reference datum - i.e 1013.2

What is important is that when making the difference calculation, ensure you are using the same reference at both ends, whether that is either GPS or Barometric.

Just to confuse things a little further, ADS-B also has the capability to supply GPS altitude in its data stream, although that appears to be rarely used from transmission data I have looked at (so lets not even go there)

Thx
Lee

[flying_john]

Got it.

All makes sense now.

All we need now is a legal way to receive Flarm data too