Garfly

Hey there, SP ... well, at least in the user friendly VFRG the local rule is just as brief but doesn't say quite the same thing. In Oz we don't get that "sparsely populated areas" exception (other than with a low-level endo and a swag of other conditions which do take a couple more pages to clarify). https://www.casa.gov.au/sites/default/files/2022-02/visual-flight-rules-guide.pdf (p.47-50) Minimum height rules – other areas (CASR 91.267) (MOS 12.02) When flying over an area that is not a populous area or public gathering (CASR 91.265), you must not fly an aircraft below 500 ft above the highest feature or obstacle within a horizontal radius of 300 m of the point on the ground or water immediately below the aircraft.

I believe this is the relevant rule in the US: https://www.law.cornell.edu/cfr/text/14/91.119#:~:text=An altitude of 500 feet,vessel%2C vehicle%2C or structure. § 91.119 Minimum safe altitudes: General. (c) Over other than congested areas. An altitude of 500 feet above the surface, except over open water or sparsely populated areas. In those cases, the aircraft may not be operated closer than 500 feet to any person, vessel, vehicle, or structure. /// ..... etc.

Yeah ... hopefully - in post - shots from the chopper will be combined with the static cam stuff plus some on-board angles and then righteous roars will replace those ruined raws.

This near miss was seen as another simple Notam fail (among other failures):

From the Original Post: Last year I wrote to OzRwys support about the way NOTAMs are handled in their SmartBrief feature: "I’m curious about how and by-whom Notams get selected/ordered? Is there a way around having to wade through tons of dross to get to the few morsels that matter?" OzRwys reply: '"This is because NOTAMs are very poorly sorted by the authorities (currently under a big review by CASA) and we are not given geographical information to link them more logically for users." So today's announcement does look like real progress: NOTAMs and Airspace are now smarter than ever! NOTAMs can be filtered and visualised for faster and more accurate briefings. NOTAMs Solved! Introducing OzRunways v12 Graphical NOTAMs. Let’s face it, NOTAMs are broken; too many nonsense ones hiding the ones that matter and impeding flight safety, not enhancing it. We've solved the problem by extracting geolocation data for every NOTAM in Australia & New Zealand. OzRunways iOS Premium subscribers can now visualise, filter, and easily read only the NOTAMs and airspace that actually affect you, making OzRunways the ultimate briefing tool. Key Features Category Filtering Using the buttons on the right of SmartBrief, you can filter out the NOTAM categories that do not affect you, or hide individual NOTAMs completely. Only See What's Route-Specific NOTAMs for plan now only show those that actually intersect your track (+/- 5NM), rather than the entire briefing area, reducing the number to read by around 80%. Trust Restricted Airspaces All restricted airspaces, including NOTAMs, are now intelligently merged onto SmartBrief and the main map. See exactly what you can fly through with confidence in the size, status, and activation time. This airspace information is saved and available offline. Dynamic Activation Times Airspace activation times are now more detailed, including amendments by NOTAM. Use the SmartBrief time slider to work out whether the activation time impacts your flight. Human-readable activation times make them easier to read. Importance Filtering NOTAMs are ranked based on their type and importance. For example: runway or airport closures are automatically assigned as ★★★★★ and are highlighted on the map. Plain-English Translation Using AI text decoding, NOTAMs with unfamiliar acronyms can be translated into human-readable summaries. Update & Upgrade Version 12 is rolling out to devices and if you have automatic updates enabled, it should install within a few days. If you want v12 now, simply locate OzRunways on the App Store and tap update. Make sure you're also running iOS 15+ or above by updating your software in device settings. Droids haven’t been forgotten! We’ve been working hard on RWY for Android adding features such as ScratchPad and Dark Mode for maps recently. We'll be bringing better NOTAMs to RWY as well in 2024. See the latest RWY Release Notes here. VFR Standard subscriber? Upgrade to Premium to access this feature and so much more! If you're mid-way through your subscription, we'll calculate pro-rata - winning! GET PREMIUM © 2023 OzRunways www.ozrunways.com Our mailing address is: OzRunways Pty Ltd PO Box 1374, Castle Hill, NSW 1765 You are receiving this email because you signed up via our website, inside the app, or have a paid subscription. Unsubscribe | Manage Preferences

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.

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

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??)

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,"

Well, Rich has tried to give us SOME idea of what it knows - and what it doesn't (yet). Meanwhile, from today's NYT: At UK Summit, Global Leaders Warn AI Could Cause ‘Catastrophic’ Harm - The New York Times WWW.NYTIMES.COM At a U.K. summit, 28 governments, including China and the U.S., signed a declaration agreeing to cooperate on evaluating the risks of artificial intelligence.

https://www.communityaviation.com/hubfs/Nine Principles - Rich Stowell and ChatGPT - 27Sep2023-1.pdf And starts a new blog (which, he reckons, was written by a human ;- ) Community Aviation WWW.COMMUNITYAVIATION.COM We're building a network of experts in every field of aviation that you can access for knowledge and hands-on training. Rich Stowell. Rich took his first flying lesson in 1982 and began his career as a full-time flight instructor specializing in spin, emergency maneuver, and aerobatic training in 1987. He is a recognized subject matter expert in loss of control in light airplanes, the 2014 National FAA Safety Team Rep of the Year, and the 2006 National Flight Instructor of the Year. A 20-year Master Instructor, Rich is a Charter and Life Member of the Society of Aviation and Flight Educators, and a 35-year member of AOPA, EAA, and IAC. He has logged 10,200 hours of flight time with 9,100 hours of flight instruction given, 34,700 spins, and 25,700 landings.

Deconstructing The Cirrus Hate - AVweb WWW.AVWEB.COM With anti-Chinese sentiment at an all time high, Cirrus takes it on the chin for being owned by the Chinese government. Should it?

And this is Blancolirio's account of yet another professional going down in a GA single. Juan opines that an important safety device we'd do well not to forget is the common credit card.

Yes, according to Juan Browne, it was probably not the turn, per se, that caught them out but coming up short on the glide, which, in this case, meant crashing into near vertical terrain just before the runway; apparently, a kind of plateau, whereas a normal airport layout might have had this episode end with nothing more than a bit of an undershoot in the grass.

YPFT closure is mentioned in "Public Notes" on its info page in OzRwys.

New OzRwys instructional vid:

Two killed in Lake Placid airplane crash identified | News, Sports, Jobs - Lake Placid News WWW.LAKEPLACIDNEWS.COM LAKE PLACID — The two people killed in an airplane crash at the Lake Placid Airport on Sunday have been identified as Russ Francis, a former NFL tight end who Air Safety Institute's Richard McSpadden Dies In Crash - AVweb WWW.AVWEB.COM Richard McSpadden, the senior vice president of the AOPA Air Safety Institute died, along with one other person, in the crash of a Cessna 177RG near Lake Placid Airport in upstate New York Sunday...

More to the point: whatareyou