PilotAware
British Forum => General Discussion => Topic started by: davemgill on October 24, 2015, 04:43:45 pm
-
I am in the process of getting all the parts I need to build a device. By entering my ICAO code in the config of PilotAware will it receive the transmission from my own Mode-S transponder and use that altitude? If it did I see no advantage in getting a barometric module.
Regards
David
-
Hi Dave,
See Altitude Accuracy thread regarding necessity of the barometric module.
I believe if you set your aircraft ICAO code in the config page (rather than the auto generated one) it stops you from displaying as 2 plane symbols one on top of each other, generated from the P3i and the other from your ADSB, (assuming you have a GPS connected to your mode S for ADSB out. The P3i one is suppressed.
PAW utilises your GPS altitude for transmission. Anything it receives from a target is displayed as a relative height compared to your altitude. Your own ADSB transmission will be recognised by PAW and not be displayed on your device.
If any of this is wrong, I'm sure someone will put us both straight.
Chris
-
I am in the process of getting all the parts I need to build a device. By entering my ICAO code in the config of PilotAware will it receive the transmission from my own Mode-S transponder and use that altitude? If it did I see no advantage in getting a barometric module.
Regards
David
Hi Dave,
Entering the ICAO code is used for 2 things
1. The ID code sent over P3I
2. Filter your own Transponder from display.
PilotAware has 2 sources of Altitude
1. GPS
2. Barometric
If you do not fit a barometric sensor, then you need to enter the QNH value in the web interface, otherwise vertical height differences to ADS-B traffic will not be accurate.
Hope this makes sense.
Thx
Lee
-
Hi Lee,
It does make sense. However as my transponder will be transmitting the altitude based on true static and not internal cockpit pressure and this using the same reference altitude (1013) that other transponders are transmitting in their ADS-B outputs surely it would make sense to use this information. It would also allow a the option of a less complex PAW unit as the barometric module would not need to be included.
Regards
David
-
Hi Dave,
I'm guessing only a low percentage of GA has a mode S transponder, even fewer have ADSB-out that will give a position that can be plotted by PAW. Mode C cannot be plotted either, even though QNE height is broadcast, because of no GPS position info.
The primary benefits of PAW, as I see it are that all GA can potentially see and be seen, using the P3i air-air transmissions, at low cost. Most of GA carry GPS and it seems sensible to use GPS height as a reference for PAW, because few will have encoding altimeters on board referencing 1013 hPa. Even if you have mode C and can be seen by ATC, simply by carrying PAW as well, the rest of us with PAW will be able to see you and your height relative to GPS height, plus you will be able to get the same info yourself regarding my trajectory.
As far as I'm aware, the whole reason for QNE (1013) was so airliners don't have to keep changing their altimeter pressure settings every few miles to take account of regional pressure settings, to maintain ATC vertical separation instructions.
Incidentally, I cheated and bought J. Curtis's shield with baro. module already fitted.
-
BTW Dave,
Do you fly a pressurised aircraft?
If not, I doubt whether the pressure difference between static line and cockpit pressure at the speeds most GA travel at will be very significant in terms of relative height for PAW purposes.
-
It would also allow a the option of a less complex PAW unit as the barometric module would not need to be included.
Hi David,
Unfortunately not, because not all A/C using PAW will have a Mode S transponder fitted, in fact may not have a transponder at all. These A/C will need a Pressure Altitude reference in order to calculate relative vertical height difference to the surrounding ADS-B traffic
Thx
Lee
-
Do you fly a pressurised aircraft?
If not, I doubt whether the pressure difference between static line and cockpit pressure at the speeds most GA travel at will be very significant in terms of relative height for PAW purposes.
Moffrestorer,
There can be a significant difference between the cabin altitude and the true altitude in some GA aircraft. The CFM shadow usually has no static system and shadow pilot manual warns the IAS over reads by about 15%. I own a Streak Shadow but did not realize straight away that the altimeter is also affected and it under reads by about 300' at 2500'. I found out when I did some airborne trials with another a PA28, thinking I had 500' separation but the cold reality was that it was less than half that.
A bit of experimenting with a couple of PA28s showed there is little difference between cabin alt and static alt on a PA28.
-
Ade,
I find the situation with the Shadow quite surprising. If the altimeter under-reads, the cockpit must presumably be at a higher pressure than surrounding air, if it's getting its pressure source from the cockpit rather than a static line. I can imagine the cockpit can pressurise if for example, cabin heat is turned on, on some aircraft, or a fresh air vent is opened, and the air has no ready means of escape. 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. I imagine most GA aircraft are not so well sealed so pressure equalises readily with ambient exterior air pressure, even when descending or climbing.
I guess in your installation, the PAW pressure sensor module (baro) could be engineered to be in a separate sealed box and be vented to the outside via poly tubing exiting at 90 degrees to the airflow, the electrical connections being made via plug and socket mounted on the PAW.
-
This is one area where I don't see the logic. Can someone help me? The PAW receives GPS data, either from the ipad/android, an external GPS or it's own which surely includes altitude. Why isn't this used instead of a baro? I'm just asking for clarification, I'm happily adding a barometer sensor as that will work for me.
-
GPS altitude is not as accurate as long/Lat positions. it is also with reference to the GPS model of the world, which is imperfect and not the same as the pressure altitude used by transponders. So that we can make a valid comparison between aircraft at different altitudes, we need to sing from the same sheet, hence we fit a baro.
-
...we need to sing from the same sheet, hence we fit a baro.
I was expecting something more like "Yes it's possible to use GPS/transponder Mode S but it's not at the top of the todo list/we've got more important stuff to do" -or- that's not possible because... -or- we chose to do it this way
-
GPS Altitude Readout > How Accurate? (rev. 2/10/01)
New GPS buyers are frequently concerned about the accuracy (or lack of it) of the altitude readout on their newly purchased GPS. Many suspect their equipment may even be defective when they see the altitude readout at a fixed point vary by many hundreds of feet. This is NORMAL.
With most low cost GPS receivers, the horizontal error (without SA now that it is off) is specified to be within about +/- 15 meters (50 feet) 95% of the time. Most users find this is a conservative specification and that their modern GPS receivers routinely perform better than this worst case specification. But.. Users should expect that SOMETIMES they may see the error approach the specification limits. AND.. 5% of the time, the error may be "any value" from zero to whatever". Note: Unless you have a CLEAR AND UNOBSTRUCTED view of the sky (on your dash or looking out of an airplane window with no externally mounted antenna, or similar obstructed view does not count!) you can count on your error excursions to be much greater than the above numbers. Your GPS <depends> on this clear and unobstructed view or it cannot make accurate range measurements to the satellites.
Generally, Altitude error is specified to be 1.5 x Horizontal error specification. This means that the user of standard consumer GPS receivers should consider +/-23meters (75ft) with a DOP of 1 for 95% confidence. Altitude error is always considerably worse than the horizontal (position error). Much of this is a matter of geometry. If we (simplistically) consider just four satellites, the "optimum" configuration for best overall accuracy is having the four SVs at 40 to 55 degrees above the horizon and one (for instance) in each general direction N, E, W, and S. (Note: You will get a very BAD DOP if the SVs are at the exact same elevation. Luckily, this is a rare occurrence.) See: DOP demonstration site by Norris Weimer> How SV geometry affects GPS accuracy(Java Required).. The similar "best" arrangement for vertical position is with one SV overhead and the others at the horizon and 120 degrees in azimuth apart. Obviously, this arrangement is very poor from a signal standpoint. As a result, of this geometry the calculated solution for altitude is not as accurate as it is for horizontal position. Almost any calibrated altimeter will be more stable at reading altitude than a GPS.
GPS altitude measures the users' distance from the center of the SVs orbits. These measurements are referenced to geodetic altitude or ellipsoidal altitude in some GPS equipment. Garmin and most equipment manufacturers utilize a mathematical model in the GPS software which roughly approximates the geodetic model of the earth and reference altitude to this model. As with any model, there will be errors as the earth is not a simple mathematical shape to represent. What this means is that if you are walking on the seashore, and see your altitude as -15 meters, you should not be concerned. First, the geodetic model of the earth can have much more than this amount of error at any specific point and Second, you have the GPS error itself to add in. As a result of this combined error, I am not surprised to be at the seashore and see -40 meter errors in some spots.
DGPS operation (where available) will dramatically improve the performance of even low cost GPS receivers. Horizontal accuracy of +/- 5 meters and altitude accuracy of +/- 10 meters (relative to the WGS-84 geode) with suitable DGPS receivers and low cost GPS receivers such as the Garmin GPS-12XL can be expected.
In any case, it is extremely unwise to overly depend on the altitude readout of a GPS. Those who use GPS altitude to aid in landing their small plane should have their insurance policies paid up at all times.
Joe Mehaffey
-
Just to give clarification on this....
Firstly, remember the altitude reported on your navigation device, will be GPS based, not barometric.
PAW, uses 2 references, it uses GPS and Barometric.
The barometric could be calculated automatically if you have a sensor fitted, or manually, by dialling in the QNH figure on the config page
When comparing relative vertical difference to ADSB traffic, barometric altitude us 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 sensir
Thx
Lee
-
That is outstanding feedback, thankyou both (and Joe Mehaffey). I forgot to ask about the Mode C/S altitude encoding, I suppose we're not listening to our own squawk.
-
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
-
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.
-
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.
-
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
-
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
-
...
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
-
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
-
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
-
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
-
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
-
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
-
Hi John
Confusing isnt it :o
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
-
Got it.
All makes sense now.
All we need now is a legal way to receive Flarm data too ::)