[TLRippon]

This is not an avoidance service it is an alerting service. It gives traffic at 12:00 1mile 200’ above, it doesn’t go on to say “Turn Right and descend 300’”, that’s up to you.

I can’t see a problem with this. I get traffic reports from ATC with a clock position and by the time I acquire them they are at a totally different clock position.

Great job again Lee, look forward to activating it when it’s available.

[dublinpilot]

Thanks Exfirepro for the explanation.

Almost all of the complaints seem to relate to the audio message giving potentially misleading clock references, particularly when traffic is one side of the aircraft and the message seems to indicate it's the other side.

If I understand exfirepro correctly, then the data for ambiguity circles is still being delivered, even if some people don't like how it's being delivered. I think I understand from here that Lee is looking into how the protocol call might be extended, but in the mean time the data continues to be delivered to the nav software.

Then it seems there are potentially some simple solutions.

Where the data suggests that there is some degree of ambiguity about the traffic's position, then the problem isn't the data, but rather the attempt to give the user a precise location by way of spoken alert, when precise data isn't being delivered to the nav software. The answer is surely to look at the ambiguity data, and if the position isn't sure enough, then don't call out the clock face. Say something like "Caution Traffic 200ft above". The pilot still gets a prompt to look, but isn't given any potentially misleading info.

No doubt the argument will then move onto the display of that position on the map, and the fact that it's potentially misleading. It seems to me that the circles of ambiguity is a good solution for that. As I understand from here, Tim didn't like those, and some turned out to be too big. Tim seems to be happy with the idea that this data is turned off now by default.

But that seems a waste to me. The thing is that pilotaware& radar360 *knows* that there is traffic in the vicinity, it just can't be 100% certain that it's location is correct. Instead of getting rid of this data because of a dislike of the circles, perhaps a better idea is that if the ambiguity suggests that the data is less than 100% accurate (or 99% or whatever Tim deems fit), then treat the target as a bearingless target instead. Surely knowing that something is there, even if you can't be 100% sure of the location, is better than not knowing anything is there. Surely bearingless is better for the pilot than turning the data off.

Personally, I'd prefer that the ambiguity circles are displayed, and I hope that EasyVFR stays that way.

Rather than criticising each other, if we all work constructively together we'll get a better solution than just turning the data off.

[Dave W]

Rather than criticising each other, if we all work constructively together we'll get a better solution than just turning the data off.

Spot on. Investigating options and offering them up to the real world to see if there is a practical solution to a technical opportunity is what innovation is all about. The user gets to benefit and as in this case sometimes gets to comment on pros and cons during development too - which is what's happening here with PAW.

Hey, if it was easy, pilots could do it.

[T67M]

My recollection of the previous discussion about ambiguity circles was that a (small) number of GPS-based ADS-B installations were unduly pessimistic about their accuracy and were transmitting NACp values which gave them a "circle of ambiguity" of several miles. During testing, visual observations suggested that these aircraft were in fact very close to the centre of that circle. This means that the "problem" observed in the position report is a reflection of the implementation of ADS-B out in those specific aircraft/transponders/GPS sources, and by discounting the use of NACp by properly implemented ADS-B or MLAT/Radar360 systems, we have effectively thrown out the baby with the bathwater. Maybe a proper review of the use of NACp is called for, with incorrect/unrealistic values being discounted rather than discounting the vast majority of cases where NACp is providing useful information.

[TLRippon]

A few pages back Lee explains how that occurred and how it was resolved.

[Tim Dawson]

Dublinpilot, you are I are very nearly in agreement!

The uncertainty circles do not work because they’re based on ncap and ncap has been shown not to be suitable for use by PilotAware, because of the many existing examples of problematic data coming through that value.

As I understand it, even the values PilotAware have been sending so far are based on the age and estimated drift of the mlat result and do not incorporate the original accuracy data passed to PilotAware from 360radar, hopefully Lee will correct me if I’m wrong.

Trying to squeeze mlat data into the “here is some adsb traffic whose position is known” gdl90 message isn’t going to work. Come up with a new message, one specifically for mlat traffic. I can help or advise with this. Then we can start from the ground up, offering the best possible visual representation and aural alerts for something we all know isn’t as good as adsb but is potentially a lot better than nothing/bearingless.

[leemoore1966]

...The uncertainty circles do not work because they’re based on ncap and ncap has been shown not to be suitable for us...

That threw me for a while there whilst I went googling for ncap
You mean NACp right ?

I will go back and reread gdl90 for the user defined data

Thx
Lee

[Balliol]

Did a IMC test on a C172 with PAW and traffic audio through SkyDemon this morning which was my first airborne experience of both - we had to turn off the audio at multiple points due to the incessant warnings which was quite different to my normal experience with Avidyne TAS audio.

Some of it seemed to be saying ‘traffic noticed’ - is that a thing or did I hear incorrectly?

Is the amount of warnings and speech due to having parameters set incorrectly or something? It was unusable to be honest.

My candidate also said you get a lot of nuisance warnings from traffic that just has a high speed vector but isn’t actually a threat - think we saw that with heavy traffic at Brize that was turning inbound for Brize as we departed Oxford on the missed approach. Is that a thing?

Range of detection and display seemed to be very impressive

Thanks - helps my understanding (sorry if this is inappropriate thread?)

[exfirepro]

Hi Baliol,

We’re you using the PAW Audio, SkyDemon Audio or both?

Not really the right thread, but A quick explanation. Traffic Notice (plus Relative Altitude) is the lowest level (in terms of risk) PilotAware Warning for Bearingless Aircraft. We are aware that there are issues with the number of audio alerts from the current (20180520) version of PilotAware. A considerable amount of work has been done on this since last May as a result of which PAW’s audio warnings have been significantly improved in the forthcoming software.

Regards

Peter

[gaznav]

At Halton Microlight Club, we disabled the audio warning from the PilotAware unit installed into our EV97 Eurostar SLs. The high number of warnings in the circuit, that were never a threat, made it quite unworkable. However, with PilotAware, FLARM and Mode S ES with ADS-B Out, they are very well served for EC

[Tim Dawson]

Apologies, yes I meant NACp.

[exfirepro]

Hi All,

I thought you might like to see a couple of screenshots taken from SkyDemon during MLAT testing on Friday using the latest pre-release PilotAware and SkyDemon Software.

The screenshots - taken a couple of seconds apart - show a couple of local ‘ADSB’ equipped aircraft, plus three ‘pure Mode-S’ Aircraft (at bottom-centre and bottom-right of the screen) whose positions were rebroadcast via MLAT from the OGN-R station at East Fortune, some 10 / 20 miles away. The rebroadcast is also supported by overlapping broadcasts from other local stations at Edinburgh West and Balerno.





The screenshots clearly indicate how PilotAware can now differentiate between Rebroadcast MLAT traffic and ‘traditional’ known position (ADSB) traffic by alternately displaying the Aircraft Reg (+ Relative Altitude) and ‘M - for MLAT’ (+ Relative Altitude).

A later flight that day shows further Mode-S/3D and FLARM traffic (Denoted by ‘-G’ + Relative Altitude) received at in excess of 20 miles from the nearest of the 3 Rebroadcast Stations.



Of particular significance is the fact that (as with known-position ADSB traffic) this traffic was received at a range of between 5 and 30 miles, which clearly allows the pilot to monitor approaching aircraft well before the proximity of that traffic would present any danger to their own aircraft. If, of course you DON’T want to see traffic at that range, it’s a simple matter to zoom in your screen to show a smaller area, and of course PAW audio alert ranges are user selectable on the ‘Configure’ Screen.

@Tim Dawson

Tim,

I have been out again today specifically testing SkyDemon visual position reports and SkyDemon audio position warnings from MLAT aircraft against their visual acquisition and am happy to report that in every case, the aircraft appeared right where the visual and audio prompts told me they would be. OK, these tests were ‘subjective’ rather than scientific, but I have been testing Mode-S Rebroadcast for over 6-months now and - far from the ‘worst case scenarios’ being mooted on this Forum - I have never been notified of an aircraft which was found to be at any significant distance from its reported position.

Taken together with the fact that we aren’t looking at ‘tracks on a screen’, but are being prompted to carry out a visual scan for an aircraft approaching from outside visual range, I personally have no concerns whatever with the Rebroadcast system, though that doesn’t of course mean we will rest on our laurels and will continue to refine and improve the accuracy of our reporting as already advised by @leemoore1966

Best Regards

Peter

[Shoestring Flyer]

I am sorry but I personally find the clarity on those screen shots very poor!
Yes after looking closely I can work out what is happening, but no way if that was installed in my aircraft where the screen is at least a couple of feet from eyes could I quickly assimilate, search the sky and react to any potential traffic.
I still say that to quickly assimilate traffic and transpose that to an outside scan needs a dedicated traffic display and not a Nav screen!

[RobertPBham]

Looks fantastic and I like the idea of the (M) for MLAT!

Out of interest, what was the thinking behind (G) for FLARM - I'm assuming Glider or OGN maybe?

I can see the screen is quite busy - as I stated previously in this thread, it'll be interesting to see how practical having all known traffic reported in busy areas actually is and if you can decipher anything. That's nothing on PAW's side, it won't matter what standard is used, the issue is still slowly going to arise - especially when anything flying including drones are displayed - it could make for one busy map!

Looking forward to applying the update!

Thanks
Rob

[RobertPBham]

Thinking on a bit further (and I should probably post this in the PAW forum), if you can distinguish between FLARM and MLAT, and you going to add configurable options for range and altitude detection?

Also, is Mode C/S detection still an option or is it replacing by MLAT?

The reason I ask is and assuming Mode C/S detection is still an option, I might want to set this for short range and only anything within say 1000ft as an emergency backup for anything MLAT misses or does place incorrectly, but then have PAW, MLAT, ADSB and OGN at further ranges as I would be avoiding that traffic at much greater distances.

I’m not sure if this is sensible or truly useful but just trying to think of how I may want to detect/display traffic in different scenarios. Maybe one setting for everything is safer.... I don’t know.