Circuit collision in USA.

[red750]

What could happen if you turn base too soon.
A Cirrus SR22 flown by a private pilot certificated PIC and a Cirrus SR20 with a CFI and his student aboard were performing touch and goes at 28J. The CFI testified that while on downwind he thought he saw the aircraft he was following turn final. The SR20 turned base then final and collided with the SR22 on the runway. The NTSB faulted the CFI for failing to maintain a safe distance from the aircraft he was supposed to follow.
Takeaway: the FAA Airplane Flying Handbook instructs us to extend the upwind or downwind until we are abeam the aircraft to follow before turning the next leg of the pattern. It is recommended we add extra distance for slower traffic to follow (extending an additional 10 seconds before turning is usually sufficient).

 

 

[Area-51]

Looks like the SR23 will be arriving some time around spring.

 

How did the following aircraft on final for touch n go not see there was an aircraft already on the runway? 

[turboplanner]

It really doesn't matter whether someone turned early or late, on Final you're supposed to be scanning ahead and on short final you're checking the runway to see if the traffic ahead has vacated it. If not, you do a go round. Aside from this incident, a favourite trick by second rate pilots is to be so overcome that they managed to land it, that they sit there on the runway doing their clearance checks, or for all I know ringing the gf, but whatever they do, until they clear the runway they have priority over you.

[RFguy]

that's an expensive pile up.

[Thruster88]

10 hours ago, Area-51 said:

Looks like the SR23 will be arriving some time around spring.

 

How did the following aircraft on final for touch n go not see there was an aircraft already on the runway? 

It most likely happened like this one, one aircraft above the other, neither pilot would be able to see the other aircraft due to structure. Look at the propeller slashes in the roof of the cirrus, nothing on the tail, both aircraft travelling at same speed, scary stuff.

 

 

Edited July 7, 2023 by Thruster88

[RFguy]

No excuse now not to have ADSB TCAS.

I'm muttering about doing somethhing, have been experimenting with my zero spare time on using multiple basic GPS receivers to get a good position fix with distributed antennas, since the SkyEcho GPS position fixes can be terribly poor if they dont have a good view of the sky,

SKyecho can be improved-  Certainly worthwhile also doing an active dual antenna >> skyecho adaptor- needs two patch antennas on each side of the aircraft that can see out the window, and uses a basic RF combiner (a $5 tv-sat one works) , and a 3d printed cosy sits over the top of the skyecho GPS antenna and couples the combined signals into the skyecho GPS antenna. That works OK. Needed to remember how to use my 3d printer...  needs to be a metalized plastic because needs to shield the re-radiating antenna so the aux antennas dont feedback. 

 

but standalone ADSB-TCAS wuld be triple GPS , triple antenna , to use multiple low cost cheap looks at different areas of the sky. avoids RAaus aircraft havign to put GPS-35 antenna in the top of their aircraft skin.  just take average of the fix works OK by various literature (been done many times) .  Step up from that is use a couple of high performance GPS receivers and use raw data from each combined in a central CPU to produce a high performance fix from the raw data from each antenna (IE you get distance and direction for each satellite from the Nth receiver, and use the combined set to produce the fix externally. There's a few ways to generate sanity checks which is well covered in literature. 

 

Target is 10m accuracy in XY and Z.  Good Z axis requires some sats overhead. X and Y need low angle sats distributed around the azimuth.

anyone not having ADSB in their aircraft , which includes the flying school aircraft  I will treat as persona non gratia . IE. "XYZ do you mind if we  backtrack with you down to the end of 33 ?" " NO , I do mind." . what happened at YCWR the other day is BS and it's not been taken seriously.

 

Edited July 7, 2023 by RFguy

[facthunter]

Unfortunately you may get regarded as Just a stirrer.  Nev

[RFguy]

yes, true. Best to lead by good example instead of spite.

[aro]

1 hour ago, RFguy said:

No excuse now not to have ADSB TCAS.

Cirrus probably does have ADSB and traffic information.

[Student Pilot]

6 hours ago, Thruster88 said:

It most likely happened like this one, one aircraft above the other, neither pilot would be able to see the other aircraft due to structure. Look at the propeller slashes in the roof of the cirrus, nothing on the tail, both aircraft travelling at same speed, scary stuff.

 

 

Looks like they were doing beatups or flybys, the 170 previously did a flyby. The Pacer or Tri appeared to be slowed up landing and the Six was coming in hot for a beatup. 

[Area-51]

17 hours ago, RFguy said:

No excuse now not to have ADSB TCAS.

I'm muttering about doing somethhing, have been experimenting with my zero spare time on using multiple basic GPS receivers to get a good position fix with distributed antennas, since the SkyEcho GPS position fixes can be terribly poor if they dont have a good view of the sky,

SKyecho can be improved-  Certainly worthwhile also doing an active dual antenna >> skyecho adaptor- needs two patch antennas on each side of the aircraft that can see out the window, and uses a basic RF combiner (a $5 tv-sat one works) , and a 3d printed cosy sits over the top of the skyecho GPS antenna and couples the combined signals into the skyecho GPS antenna. That works OK. Needed to remember how to use my 3d printer...  needs to be a metalized plastic because needs to shield the re-radiating antenna so the aux antennas dont feedback. 

 

but standalone ADSB-TCAS wuld be triple GPS , triple antenna , to use multiple low cost cheap looks at different areas of the sky. avoids RAaus aircraft havign to put GPS-35 antenna in the top of their aircraft skin.  just take average of the fix works OK by various literature (been done many times) .  Step up from that is use a couple of high performance GPS receivers and use raw data from each combined in a central CPU to produce a high performance fix from the raw data from each antenna (IE you get distance and direction for each satellite from the Nth receiver, and use the combined set to produce the fix externally. There's a few ways to generate sanity checks which is well covered in literature. 

 

Target is 10m accuracy in XY and Z.  Good Z axis requires some sats overhead. X and Y need low angle sats distributed around the azimuth.

anyone not having ADSB in their aircraft , which includes the flying school aircraft  I will treat as persona non gratia . IE. "XYZ do you mind if we  backtrack with you down to the end of 33 ?" " NO , I do mind." . what happened at YCWR the other day is BS and it's not been taken seriously.

 

After one more recent near miss have upgraded the situational awareness by taking out a paid subscription with AvTraffic ADSB in, which now allows that data to be overlaid onto OzRunways' screen (so no longer need to switch between apps and miss critical information); and its paid dividends. The first flight afterward saw almost the exact same scenario with the very same other aircraft, however this time was able to see the situation unfolding well in advance, so simply turned away.

 

A second dedicated wifi slave screen for AvTraffic will be installed to add additional layer of situational proximity visual and audio warning cues.

 

Cockpit workload has been reduced.

 

The positional receive/transmit latency on both app servers is a few seconds, and works great providing there is cellular signal reception.

[aro]

6 hours ago, Area-51 said:

The positional receive/transmit latency on both app servers is a few seconds

Anywhere between a few seconds and about a minute, at which point traffic disappears. At 90 knots, 5 second latency is a position error of over 200m - for each aircraft.

 

Traffic displays are always showing you the situation from a time in the past. In this collision, each aircraft would have seen the other aircraft as behind them on a traffic display - not a collision course. How far behind? That depends, it's impossible to know. The only time you can be sure is if you are passing behind displayed traffic. Even then it becomes difficult if the other aircraft e.g. turns.

 

I use a traffic display, they're great, but the most important skill is knowing when you need to be looking out the window and managing separation visually. Anything closer than about 1 mile, you need to separate visually and should be worried if you can't see them.

[RFguy]

yeah. I am was concerned, but I was looking for them late base.... down to my lower left. not out the window to my right. I shoul;d have been able to see them late base since that's a white aircraft over green pastures. Looking to the right is looking into the town and beyond into the hills. 

I dont understand you mention of trafdfic displays showing the situation in the past- certainly the past but no more than a few seconds

 

Which brings me to a defficiency with looking at traffic in OZRWYS - there isnt a time stamp or time delay shown  for that fix.  

[aro]

26 minutes ago, RFguy said:

the past but no more than a few seconds

A few seconds is equal to a few hundred metres, because we are always moving.

 

But it can be more. I have ADSB traffic from a Stratux plus the internet traffic on my ipad. Initially it tends to show both, until it figures out which internet traffic corresponds to ADSB traffic. There is frequently up to a mile difference in the displayed positions between traffic from the internet and the ADSB receiver (internet behind... usually).

 

My understanding is ADSB frequencies are easily blocked by aircraft structure, so depending on antenna position if there's an aircraft below you (especially low wing) you might not receive it's ADSB. So when an aircraft turns base and descends, you might stop receiving its ADSB. In that case the ipad displays the last received position - for up to a minute I think. High end ADSB installations have an antenna on both top and bottom of the aircraft for this reason. ADSB as installed in GA aircraft is designed for air-ground not air-air.

Edited July 8, 2023 by aro

[Area-51]

49 minutes ago, aro said:

Anywhere between a few seconds and about a minute, at which point traffic disappears. At 90 knots, 5 second latency is a position error of over 200m - for each aircraft.

 

Traffic displays are always showing you the situation from a time in the past. In this collision, each aircraft would have seen the other aircraft as behind them on a traffic display - not a collision course. How far behind? That depends, it's impossible to know. The only time you can be sure is if you are passing behind displayed traffic. Even then it becomes difficult if the other aircraft e.g. turns.

 

I use a traffic display, they're great, but the most important skill is knowing when you need to be looking out the window and managing separation visually. Anything closer than about 1 mile, you need to separate visually and should be worried if you can't see them.

Correct, a pilot in command always needs to continue using the primary flight instrument of the "windscreen" to maintain visual awareness around the aircraft at all times.

 

The other query regarding lack of "time stamp" on OzRunways traffic, again, from the app Developers of both AvTraffic and OzRunways, its a few seconds.

After watching a Youtube video of a fatal WX in the US due to Latency of a few minutes at the user end it prompted me to ask both app developers what their latency was for Traffic. OzRunways had that data published already, AvTraffic updated their FAQ immediately upon presentation of my  question being asked.

 

Onscreen Traffic is a great tool if used affectively within its limitations. It allows a pilot to see approaching aircraft at a radius between 1-80nm. For the type of flying I do 8nm works well and provides ample time to divert and monitor. I do no use it in the circuit.

Edited July 9, 2023 by Area-51

[RFguy]

good points on delays. lot sof poor / suboptimal implementations out there

 

there isnt complete blocking  by wings at least for close proximity - signals conduct and bend around wings , there is re radiation from the airframe etc.   

At least up to about 1000m above or below  it is going to be pretty bulletproof.  It does open you up to the ADSB semi-blocked transmission getting stomped on by another in busy airspace , but that's a low likelihood with 120uS bursts and position being transmitted at ~ 2Hz.

 

My production ADSB-TCAS implementation will be real time.  and it is predictive.  I have ordered 30 sets of raw data capable GPS modules for my project to start with. 

 

 

 

[RFguy]

agreed on nice to see say, inbound traffic 8nm the other side of the airport when inbound, gives you some think time to decide your intentions.

[facthunter]

There will always be people you could get cranky about, justifiably.. IF I started to list them for you, I'd start to get cranky...  Another stuck and resurrected. post from me. Nev

Edited July 9, 2023 by facthunter

[Garfly]

5 hours ago, aro said:

Traffic displays are always showing you the situation from a time in the past ...

I use a traffic display, they're great, but the most important skill is knowing when you need to be looking out the window and managing separation visually.

Anything closer than about 1 mile, you need to separate visually and should be worried if you can't see them.

It might sow confusion if we throw around term "traffic display" without being clear that we're talking about cellular network based traffic systems and not about proper ADSB-IN displays.  Sure, any internet lags become clear on your EFB screen if you're running proper ADSB-IN at the same time. The position delay seems, in my experience, to vary from zero to several seconds.

 

But just to be clear, there is no latency issue with true ADSB-IN traffic displays (like SkyEcho2 or better).

 

And usually, when we're discussing the use of traffic displays in the circuit - for or agin - we're talking proper ADSB-IN

 

That being said, Area-51's story, a few posts up, shows that even laggy cell based traffic (like his AvTraffic/OzRwys integration)

can sometimes work better than any amount of "managing separation visually" :   "After one more recent near miss, have upgraded the situational awareness by taking out a paid subscription with AvTraffic ... it paid dividends. The first flight afterward saw almost the exact same scenario with the very same other aircraft, however this time was able to see the situation unfolding well in advance, so simply turned away."

 

OzRwys is clear about the limitations of its cell-based display of traffic information.  As they put it "OzRunways traffic is great

but it's not the whole picture" before going on to urge customers to invest in a proper ADSB-IN solution. But short of one of those, an AvTraffic/OzRwys (cell based) set-up does have a few plusses of its own, combining OzRwys targets with all other traffic supplied by the 'ADSB-exchange' (most ADSB-OUT equipped aircraft - depending on local coverage) and presenting it all on the familiar (already in use) OzRwys main map page - without need of other devices. Plus AvTraffic has aural traffic alerts. And while those alerts are probably very useful enroute, I can't see how they'd help much in the circuit; wouldn't Bitchin' Betty be having constant conniptions even in a mildly crowded circuit area? 

 

I suppose time stamps could overcome lag issues in internet traffic displays (as long as pilots didn't have to do any maths in their heads, when only a glance may be spared) but wouldn't it just be putting lipstick on a pig?   ADSB is here - it's an amazing aircraft-to-aircraft tech which just works, is user friendly and is heaps cheaper than it used to be.  The problem remains that it's far from universal in VFR land. Too bad the proposal before government years ago for supplying devices free for all VFR aircraft wasn't taken up.  

 

 

 

 

 

 

 

 

Edited July 9, 2023 by Garfly

[RFguy]

traffic that is 'OLD" or "out of date " (say 3 seconds)  needs to be put into a different colour traffic bubble .  I dont like anything with a cellular or third party network that does not deliver time definite in the way.... 

Edited July 9, 2023 by RFguy

[Garfly]

34 minutes ago, RFguy said:

traffic that is 'OLD" or "out of date " (say 3 seconds)  needs to be put into a different colour traffic bubble . 

 

I agree.

 

The problem with AvTraffic's internet based "ADSB" targets in OzRwys is that they show up in the same dark blue that's used for direct ADSB traffic such as supplied by the SkyEcho2.  OzRwys traffic (its own participating customers, via internet) is, of course, distinguished by showing as light blue.  A couple of years back I had an email exchange with OzRwys support suggesting that direct ADSB targets might be better displayed as a different colour (as opposed to just a darker shade). I was told that they felt the distinction was clear enough and that since "traffic is traffic" it's better, for a consistent iconography, to keep the two types the same basic hue.   

 

But as you suggest, Glen, traffic ain't traffic when lag is involved.  So I reckon it's time to move to a different colour for true ADSB (real time) traffic.

[RFguy]

correction : my 1000m up and down if shielded should read 1000'  . feet not meters.

 

[Area-51]

So today during a check flight the AvTraffic OzRunways solution was given another run. For now it is an immediate stop gap solution, and fully agree, it is not able to supersede or replace the accuracy of realtime ADSB live signal observation equipment, or Visual when proficiently scanning the circuit in VFR.

 

The OzRunways screen was showing a Jetstar RPT on departure climb and there was visual on the aircraft tracking perpendicular also; so it was a good opportunity to observe actual Latency. The Jetstar RPT was also displaying both an AvTraffic ADSB and OzRunways bubble simultaneously.

 

The observed positional Latency was about 10 seconds.

 

Eventually the AvTraffic solution will be replaced by a Uavionix Ping or similar real time ADSB-IN solution.

 

 

[RFguy]

I intentionally prevent my Ozrunways from showing any mobile-data derived traffic due to the lag. I just use the SE2 for my traffic reception on the wifi connection.

 

 

[pmccarthy]

48 minutes ago, RFguy said:

I intentionally prevent my Ozrunways from showing any mobile-data derived traffic due to the lag. I just use the SE2 for my traffic reception on the wifi connection.

 

 

That means you are missing two thirds of the traffic, the ones without ADSB but with OzRunways..