Author Topic: Multiple audio warnings of traffic  (Read 1882 times)

Mach2

Multiple audio warnings of traffic
« on: August 11, 2020, 05:14:06 pm »
Have integrated PowerFLARM data (via USB cable) into PilotAware for display on Skydemon (iPad) via WiFi and have PF, PAW and SKD audio connected directly to my intercom system.  On most occasions this is magic with really accurate traffic calls on gliders and other traffic/airspace.  But recently departing Turweston which was quite busy with traffic, the audio systems seemed to be competing with each other on calling traffic (some seeming duplicate) resulting in bedlam in the headphones.

Originally I had set up the audio systems as auxiliary audio inputs to the VHF COM which are muted when receiving is in process but ATC chatter was blocking traffic information.  So I changed the configuration to remove the muting function but now have bedlam.

Can anyone explain the distribution of traffic source warnings in this case from merged PF, PAW and SKD audio so I can try to find a way to calm the ears?

John

exfirepro

Re: Multiple audio warnings of traffic
« Reply #1 on: August 11, 2020, 06:37:43 pm »
Hi John,

You certainly are a glutton for punishment! But seriously, I am concerned by what you are reporting. I have been speaking to Lee recently about the need to revisit PilotAware's own audio alerts due to what can be a considerable degree of duplication. This is especially noticeable in the vicinity of airfields - with a high degree of both airborne and ground traffic. It also manifests itself when travelling in 'convoy' with other aircraft, when repeating alerts are produced as each aircraft moves out of and back into any of the warning 'cylinders' - through any of their horizontal or vertical surfaces. If you haven't read it, take a look at the explanation of the Known Position and Bearingless PAW audio alerts (from Page 28 on) in the PAW Operating Instructions, here...

https://pilotaware.com/Documents/Operating%20Instructions%2020190621.pdf?_t=1561197960

In addition, SkyDemon has its own traffic alerts, which are completely independent of PilotAware. These are based on anti-collision algorithms. It also has separate alerts for controlled airspace and other hazards, etc.

Sorry, I haven't used PFC for some time, so would need to revisit exactly what type(s) of alerts it produces, but I have no doubt whatever that all 3 together will be quite daunting.

Let me think about this and do a bit more research and I'll get back to you.

Regards

Peter
(PilotAware Development)

Mach2

Re: Multiple audio warnings of traffic
« Reply #2 on: August 12, 2020, 06:48:54 pm »
Having absorbed your advice Peter, and re-read the SKD manual and forum it would appear that as PAW sends its traffic data via WiFi to SKD where audio and visual warnings are generated, I should be able to turn off the PAW audio without loss of capability.  Of course that depends on the PAW and SKD algorithms.

For my installation it also depends on how the PF traffic data that comes in to PAW via USB is treated.  Is it managed just like any other PAW track and sent to SKD via WiFi as just another track?  If so I may be able to turn off the PF audio, subject to a check that its own warning algorithm does not include some critical feature (which for gliders FLARM does).

A while ago Keith described the full suite of EC devices as "the gold standard" but I think that accolade may come with a sensor fusion hub that integrates all the systems and I envisaged PAW is that hub.  When I was involved with Typhoon development, sensor fusion was the emerging key technology and the displays were able to present a single "air picture" but with icon shapes that told you where the data came from (on-board, off-board etc).  And of course being bred in Lancashire we asked for the standard audio warning to be "ay oop, ay oop but that did not survive to production!

Do you know how I can bottom out the way that track data is managed thought the systems?

John
« Last Edit: August 12, 2020, 08:02:24 pm by Mach2 »

PaulSS

Re: Multiple audio warnings of traffic
« Reply #3 on: August 13, 2020, 11:53:13 am »
Quote
I should be able to turn off the PAW audio without loss of capability.  Of course that depends on the PAW and SKD algorithms.

You won't get bearing less target audio warnings. Tim doesn't think bearingless targets are worthwhile and so he's taken his audio ball home, instead of letting us decide whether we would like them or not.

exfirepro

Re: Multiple audio warnings of traffic
« Reply #4 on: August 13, 2020, 01:42:17 pm »
Hi John,

I have just responded to a similar post (presumably from yourself?) over on the SkyDemon Forum. As I said earlier, we still need to do some more work to improve the audio reporting in PilotAware - especially regarding traffic on the ground, around airfields and when flying in groups, however as things stand, the following applies.

Having absorbed your advice Peter, and re-read the SKD manual and forum it would appear that as PAW sends its traffic data via WiFi to SKD where audio and visual warnings are generated, I should be able to turn off the PAW audio without loss of capability.  Of course that depends on the PAW and SKD algorithms.

But with the limitation that SD doesn’t provide any audio alerts for ‘Bearingless Traffic’ on any of its protocols, despite the fact that they are sent to it from PilotAware.

Quote
For my installation it also depends on how the PF traffic data that comes in to PAW via USB is treated.  Is it managed just like any other PAW track and sent to SKD via WiFi as just another track?  If so I may be able to turn off the PF audio, subject to a check that its own warning algorithm does not include some critical feature (which for gliders FLARM does).

Data sent to PAW from PF by the RS232/USB link is ‘parsed’ (compared and combined) in the PAW software, with the resultant ‘combination’ passed via WiFi to whatever EFB is the users’ choice.

In the case of SD, when using the ‘Flarm’ or ‘PilotAware’ Traffic Options, ‘Known Position’ Traffic is displayed visually as moving traffic on screen, (subject to preselected relative altitude filters) and ‘Bearingless’ Traffic is displayed by the system of concentric coloured rings (to indicate probable degree of risk) together with actual relative altitude and Reg ID/Flight ID for Mode S, or a Mode C Code for Mode C Traffic - unless ‘Display Registration has been deselected in SD/Setup/Nav Options. Audio alerts are generated solely from SD’s anti-collision algorithms.

If using the GDL90 protocol, however, no info (visual OR audio) is currently provided by SD for ‘Bearingless’ Traffic.

Quote
A while ago Keith described the full suite of EC devices as "the gold standard" but I think that accolade may come with a sensor fusion hub that integrates all the systems and I envisaged PAW is that hub.  When I was involved with Typhoon development, sensor fusion was the emerging key technology and the displays were able to present a single "air picture" but with icon shapes that told you where the data came from (on-board, off-board etc).  And of course being bred in Lancashire we asked for the standard audio warning to be "ay oop, ay oop but that did not survive to production!

Do you know how I can bottom out the way that track data is managed thought the systems?

John

Interesting info John, but a bit expensive I presume!

My best advice taking account of the limitations above would be.. ‘turn the PF audio off in PF Config and rely on the SD and/ or PAW audio, depending on your viewpoint on ‘Bearingless’ Traffic. If you don’t want alerts from Bearingless Traffic, you could rely solely on the SD audio alerts, which operate via anti-collision algorithms, and include airspace and restricted area warnings.

If, however, you are concerned at not receiving warnings from the ~ 70%+ of traffic at GA levels broadcasting straight Mode-C or Mode-S (with nothing else), then you need to at least ‘mix’ PAW with SD audio - unless, or until we can (between us) come up with a better option.

Best Regards

Peter

Mach2

Re: Multiple audio warnings of traffic
« Reply #5 on: August 14, 2020, 06:33:41 pm »
That is really great info Peter.  My understanding now is that PAW integrates the PAW and ADSB tracks with the FLARM and ADSB tracks sent to it by PF.  I think that is what I see on the traffic page although I do not know how it does that or how it handles 2 sources of ADSB.  Far too clever for me!

But if that traffic data is passed to SD where it is displayed (not hugely attention getting because I am looking outside) and announced (which is attention getting) then I am delighted.  As to bearingless Mode ACS traffic, the head up display on PF fitted on my coaming provides a range ring for the nearest track and that is in my sightline.

Thanks a lot....
John
RV-8 G-RUVE awaiting first permit issue and painting