Garfly

But that's in your RV. If you'd taken your Thruster into town, you'd probably have landed back in 2022.

Ha, ha ... presumably see-and-avoid (esp. by way of ye-olde nav lights) will be long gone by then. ;- )

I guess noise nuisance will be the main fly in the ointment for flying cars; more so than safety and efficiency which are more easily sorted.

Yes, nor in ours. But maybe a century on from Cessna's aerial-car dreaming, something akin might arrive. But it probably won't require, or allow, any hands-on sky-driving as in the 1940's imagining. And it looks like Cessna won't be the one leading the charge. (For the loser now Will be later to win)

The way it was ... and (for General Aviation) the way it's gonna be, just as soon as the war is won: "... this dream of flying-for-the-millions in the Family Car of the Air, is coming true for all of us." Yep ... a pilot in every home.

And, since the YouTube algorithm reckons that too many Constellation films are never enough, this one has just turned up. It's a recently made detailed analysis of the New York midair disaster of 1960. It's the accident that was referred to, in the film above, as the last nail in the coffin of the Connie's illustrious career (despite the fact that the aircraft, itself, was not, in any way, to blame).

And there's this comprehensive (if très romantique) french documentary about the Constellation. (has english Closed Captions) "Imagined by billionaire multi-talented genius Howard Hughes, the Constellation made an impression. A mythical airliner built by the American Lockheed, it remained the emblem of an era when air transport was a real luxury. Requisitioned by the army during the Second World War, it then ensured many transatlantic connections for a very wealthy clientele, ready to pay the equivalent of 10,000 euros for a ticket. The arrival of jet planes, and especially the 707 put into service by Boeing in 1958, marked the abrupt end of the Constellation. Actor Tchéky Karyo lends his voice to tell the story of this “air star”."

'The daily "chores" of Royal Air Force Ground Crews, Flight Riggers, Flight Mechanics and Wireless Electricians needed to keep Supermarine Spitfires operational are detailed in this 1940 instructional film. It features close-up footage of aircraft and crew from 609 Squadron at RAF Northolt undertaking the maintenance schedule required for a Spitfire Mk I's Periodical Inspection Certificate.'

This one has no chopper noise spoiling the audio:

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.