UK PPL busts airspace • forgets that SE2 sends GPS ALT to EFB (Baro PA only for ADSB)

[Garfly]

 

 

 

[Thruster88]

Only the altimeter should be used for vertical navigation. 

All transponders have a fixed baro setting so they are all on the same page.

I think the SkyEcho2 would only transmit baro information for height and would not use the gps data for that function.  

[Garfly]

Yes, agreed.  I think the revelation of the video story was that whereas SE2 indeed uses baro (Pressure Altitude) for its traffic function ('everyone on the same page') the position info that it's sending your EFB (assuming you enable that function) is all GPS derived - including altitude. It seems that the guy involved was expecting higher quality baro info being sent to his SkyDemon (although that doesn't take into account the difference between Pressure Alt and AMSL) 

 

Anyway, the video makes clear that he accepted full responsibility; that he should have been referencing his plan and his altimeter.  The moral is the obvious one; we should be taking advantage of the safety features of new tech but not be lulled into overconfidence in what it tells us.

 

I was curious about OzRwys position on this issue (pilots developing undue confidence in GPS derived V-Nav guidance) and whether it was feasible to use the baro capabilities of portable devices (QNH adjusted on-the-fly) as opposed to relying on GPS data.  So I sent off this enquiry:  

 

 

"Dear OzRwys support,

I have just watched this interesting video from the UK 

https://www.youtube.com/watch?v=sOT4_cmQLKw

which tells the story of a chap who clipped controlled airspace around London. It seems he did it partly because of over confidence in the altitude information that his SkyEcho device was feeding his SkyDemon app - in particular its V-Nav graphic display.  

Apparently he was assuming that because the SkyEcho uses a proper barometric pressure altitude device for vertical traffic separation that reasonably accurate vertical info was being fed to the SkyDemon.  But as the video explains, it ain’t so; it’s only GPS altitude that’s being sent and that, of course, can be pretty unreliable. 

I suppose it’d the same with OzRwys, right?  And, presumably, when the app is only using the internal GPS it’d be the same - that no baro info is involved. Anyway, it’s a good reminder that with any VNav advice from carry on gear, we have to remember that when it’s GPS altitude that we’re working off, we need to regularly cross-check it with our (QNH adjusted) altimeter.

I guess my question would be: Is there any way for OzRwys to use the barometric data available in portable devices (and adjust it for QNH) instead of GPS derived data for any of the vertical gudance displays?

Thanks for any insights,"

 

 

 

 

  

Edited November 4, 2023 by Garfly

[RFguy]

AND  when route flying, ideally should be flying (with validity period) AREA QNH. 

 

Skyecho does know baro pressure. - IE absolute pressure. just like a normal transponder.  Ozrunways I am pretty sure says GPS altitude. 

 

When I have been flying through busy routes  6k-10k feet with other traffic around, ATC always provides me Area QNH to set my altimeter to (they request) . This way, we're all flying withing 50 feet of where we should be for separation.

 

 

[BurnieM]

Just confirming I have got this right; there was a 1500 ft vertical error in the GPS position sent from the Skyecho ?

 

This appears to be nothing to do with potential errors between baro and GPS attitude and

everything to do with poor satellite spread or number of received satellites and either;

1. the high potential error calculated not being passed to the moving map software

or

2. the moving map software ignoring the potential error and displaying position without a warning.
(apparently Skydemon does display an potential error but not promenently).

 

The UAvionix response in the video is misleading to say the least

.

Edited November 4, 2023 by BurnieM

[IBob]

Assuming you have the flight recorder enabled in Ozrunways, it generates a data file for each flight.
By dumping that out you can access the altitude data, which is what I did following a near miss at the start of a flight a while ago.
I then corrected the data for QNH on the day, and found the corrected GPS data to be very accurate: I know this because, following the near miss I flew a return trip at very precise altitudes (as displayed by my altimeter).

There are various comments about GPS altitude not being very accurate. There are also comments about it being less accurate near ground level.
It would be nice to get a fix on the actual degrees of inaccuracy:
Are we talking about tens, or hundreds of feet?
And how close to ground level should we expect additional inaccuracy?
Anyone???????

 

[RFguy]

""Just confirming I have got this right; there was a 1500 ft vertical error in the GPS position sent from the Skyecho  ?"

 

YES that easily can happen. I have seen up to 500m error.

 

Skyecho can be TERRIBLY inaccurate- the GPS  antenna has a terrible look at the sky in general and can be hundreds of meters out in any direction....

It depends whether the accuracy metrics from the skyecho are interpreted, or not.

Same could be for a tablet GPS

accuracy is transmitted on adsb, but many apps like FLight radar, flightaware  ignore these values, also.

 

 

[BurnieM]

In a previous life I worked for a specialist GPS retailer (not aviation) and took Garmin hiking GPSs on 737/747 flights many times.

Even thru their small windows with earlier model GPS chipsets (15+ years ago) I very rarely saw major errors.

 

I find a 1500 ft error (even a vertical error) on a calculated position with a modern GPS chipset to be troubling.

Edited November 5, 2023 by BurnieM

[facthunter]

It was always my belief that Height was not a GPS strong point. Has anything changed?. This doesn't alter the fact that Altimetry is your level determinant  for separation even IF the GPS figure is more accurate in relation to the ground sometimes. All aircraft should reference the same Baro Data in a specified area and 1013.2 above FL10. Many times i've gotten into a plane and found 1013.2 still on the subscales.  Nev

[BurnieM]

Generally you should see a horizontal error less than 10m and a vertical error less than 20m on a consumer grade GPS.

Consumer chipsets typically calculate position once a second altho for slightly more chipsets that calculate position 5 times a second are available.

 

I would consider a vertical error of 100m to be extreme and in most circumstances would expect moving map software to either ignore the position or display a large warning message.

Depending on what you are trying to do you could display without message or do averaging.

In critical use I would not do either but in aviation I would probably still display it with a very visible warning.

 

Every consumer GPS I have seen calcuates its own potential error.

 

Edited November 5, 2023 by BurnieM

[IBob]

Considering that we are required to have ADS-B in controlled airspace, where it will be used to verify position etc and ensure separation, it would surely need to be quite accurate
BurnieM do you have any insight as to how accurate it is near ground level? Is it less accurate there?

[RFguy]

You're not considering that if the GPS antenna  cant see a considerable portion of the sky, errors can be significant.  200-300m easy. That goes for ANY GPS, doesnt matter how good it is. If it cant get diversity of SVs (spave vehicles) , it will result in  poor transliteration solutions.

 

"Every consumer GPS I have seen calcuates its own potential error" - YES, HDOP and VDOP some only show HDOP, most consumer stuff wont show VDOP, and also, there is a stat associated with this number. Different engines report different stats (IE % confidence that the displayed fix is within xyz) 

 

Edited November 5, 2023 by RFguy

[facthunter]

If an above  allowed altitude tolerance  exists you can be denied airspace clearance and the instrument has to be repaired. Nev

[Garfly]

Uh, oh ... I fear my posting this story has caused more confusion than clarity.

 

Although the "Flying Reporter" was pretty clear in his reporting.

 

For its main traffic avoidance function the SkyEcho is not using GPS to provide altitude, it uses a quite accurate baro sensor set to Pressure Altitude value.

 

But if you use it also to feed position info to your EFB it does not send baro info to your EFB for any altitude value but GPS info only.

 

Which, anyway, is exactly what you'd be using if you decided to rely on the internal GPS chipset in your Tablet/phone and your EFB. 

 

Also, as it happens, most modern phones and tablets do have quite accurate baro sensors in them but these are not (as far as I know) currently used by most EFBs for their various V-Nav displays.

 

Of course, in order for them to be useful enroute the use of these sensors would need to factor in Area QNH.  But, within cell range, EFBs do usually 'know' the current QNH, so I suppose it could be factored in. Thus my question to OzRwys Support, above.  (I'll pass on any answer ... though I think I can see already some practical difficulties.)

 

But basically, no there is no problem (at least that this story suggests) with the way that SkyEcho reports its (baro) Altitude for its normal ADSB function.

 

(And the video reports that UAvionix does stress the importance of placement of the device in the a/c for its GPS position accuracy.) 

 

And in my experience, too, GPS altitude agrees with baro within a couple of hundred feet.  The issue in the video might have been an anomaly (possibly even war related??)

 

 

 

 

[Garfly]

Just in, some high quality info from Rowan:

 

 

 

 

From: OzRunways Support <[email protected]>

Subject: RE: Altitude information from SE2 (and other devices). [Ticket#2514411]

Date: 5 November 2023 at 6:30:14 am GMT+1

To: xxxxx

 

Hi Gary,

 

Yes all of the above is correct but there's a few more variables which is baro devices inside cockpits are inherently unreliable (see: all warnings about using Alternate Static Sources which usually pick up from inside). For most aircraft that's around +/- 200ft, and if you're in a pressurised aircraft, it's dramatically incorrect.

 

It gets more complicated quickly. The GPS ALT your device(s) provide, often give altitude above the WGS84 datum, which is a mathematical shape that very closely approximates earth to within more or less +/- 200 ft. The reason is that some parts of earth are more/less dense, and there are variations in shape at these points. There is a correction model that corrects for these points, and the one we have built into the app is called EGM96 where we store all values in a 1 Degree resolution. (Interestingly, we also need to correct the NASA SRTM data for this too, as they are based on WGS84 datum).

 

OK so it also turns out that the iPad GPS internally already corrects for Geoid corrections using their own high resolution model, similar to EGM96. So the "GPS ALT" your iPad reports, is actually already surprisingly very close to AMSL (i.e. your altimeter with correct QNH set).

 

So for those portable devices that report your altitude based on GPS ALT (WGS84 and/or Baro Alt), we have a very complex set of rules in-app to work out which one yours is based on, try to correct for local QNH (if known), and try to work out if you're in a pressurised aircraft, etc. It's quite complex and hurts my brain whenever I have to look it up again so I won't do it now, but suffice to say, we've factored it all in, so we compare "like for like" with traffic calculations, so "+015" means "1500 ft above you", to within a decent confidence level.

 

The GPS ALT HUD Box at the top will be reporting whatever GPS Source your iPad is using. This is outside of our control or knowledge. If it's using the internal GPS, it's likely fairly close to AMSL. If it's an external GPS, it may be WGS84 Datum altitude (i.e. a little incorrect).

 

Anyway my final comment is you should always use your aircraft panel altimeter, with the correct QNH set, for everything related to your aircraft's flight. Don't use the iPad GPS or any portable GPS for anything other than broad situational awareness as they aren't certified, or accurate (plus, see above for the complexity involved!).

 

Cheers, Rowan 

[BurnieM]

3 hours ago, RFguy said:

You're not considering that if the GPS antenna  cant see a considerable portion of the sky, errors can be significant.  200-300m easy. That goes for ANY GPS, doesnt matter how good it is. If it cant get diversity of SVs (spave vehicles) , it will result in  poor transliteration solutions.

 

"Every consumer GPS I have seen calcuates its own potential error" - YES, HDOP and VDOP some only show HDOP, most consumer stuff wont show VDOP, and also, there is a stat associated with this number. Different engines report different stats (IE % confidence that the displayed fix is within xyz) 

 

Tried to find an old paper (with no luck) that suggested that small sky view could still produce a good fix with low horizontal errors.

Cannot remember what they said about vertical errors.

With the current 31 operational GPS satellites I believe you can get low error positions with less than 50% skyview.

Certainly observation in commercial jets thru a very small window suggests you can get good postions with signifcantly less than this.

Yes, a good spread of satellites is required but with 31 operational this is only rarely not available.

 

I have never opened a SkyEcho but some reported issues surprise me.

Its odd when good quality GPS receiver/antennas can be purchased for less than US$15.

Tried to find the GPS specs but they do not even quote the number of channels.

 

Pulled out an old car GPS (Garmin Nuvi 50) from 2012 with 12 channel receiver.

This is in my front yard with 30 degree shading to the north, 20 degree shading to the east and west and -20 degree to the south (yes I am on a hill).

By shading I mean from horizon to say 20 above horizon is not visible to the receiver.

At my home in northern suburbs of Sydney I am receiving 10 satellites and it is indicating a horizontal error of 4m.

 

The only time I have seen large errors in the last 10 years is when driving thru the Sydney CBD.

[RFguy]

number of satellites is not so important as to where they are in the sky.

 

Think of multiple rubber bands pulling the one item around.  and how biases pull the fix - specifically items like ionospheric delay, sat drift,  height in the sky.  8 sats is fine if they are well distributed. 

....the shading you describe isnt too bad for shading.  and horizontal posititive errors are different to vertical position errors. again, diversity of what you can see.

[tafisama]

An Altimeter is the primary reference instrument for altitude.An EFB is not even a secondary instrument,it`s just for situational awareness.This pilot should have remembered that.He was reckless to reference to his EFB.

[Neil_S]

My AVPlan HUD on my iPad mini has both GPS Altitude and Baro Altitude. In my experience they can be very close (within a few feet) or sometimes disagree by a few hundred feet. So, as others have said, I believe it is best to use your biennially-calibrated altimeter with the correct QNH.

Checking it right now sitting at home they are within a foot of each other.....

 

Cheers,

Neil

[Garfly]

5 hours ago, tafisama said:

An Altimeter is the primary reference instrument for altitude.An EFB is not even a secondary instrument,it`s just for situational awareness.This pilot should have remembered that.He was reckless to reference to his EFB.

Yes, I don't think you'd get much argument there, least of all from the pilot involved who was very willing to share his shame for the common good.

[Jerry_Atrick]

Here's the uk flyer forum where the pilot started a thread on it: 

Flying Reporter - The email no pilot wants to receive

FORUMS.FLYER.CO.UK

---

FLYER Forums

 

[facthunter]

I think we have covered this one haven't we? Use Baro information for height separation. ALL of us are THEN using the SAME reference. If you  want to just miss the tops of Mountains (A silly idea) extra information might give more certainty but your LSALT gives you 1000' plus it you've derived it properly. Nev