Tim,

That’s what I was trying to explain above - I wasn’t in any way trying to be negative about SkyDemon Audio - quite the reverse in fact, I am a fan and I am well aware from recent customer comments and personal experience that we still need to do more work on our own audio alerts.

Having been instrumental in the development of PilotAware’s Mode C/S reporting system, and flown with it for the last 5 years (not to mention 6 years previous experience with the Zaon PCAS MRX System), I am well aware of the limitations involved in reporting ‘Bearingless Traffic’, but in truth the limitations are miniscule, compared to the advantages and to the risk we run without this type of detection and alerting, with a reported estimate of 70%+ of GA aircraft currently still running solely Mode C or Mode S transponders - which SkyDemon, (seemingly reluctantly), reports on Flarm and PilotAware settings, but doesn’t recognise or report when using GDL90.

To simply say...

‘there is traffic close to your level (when we have an accurately reported relative barometric altitude based on direct transmission from the aircraft’s transponder) possibly close by (when proximity is determined and reported at 3 separate points based on a combination of received signal strength and rate of change, and only where the aircraft breaks an initial preset reporting level, determined by the user’s selected reporting ‘Range’) but we don’t know where’

...is IMO at best disingenuous, and at worst actively misleading.

As I have reported elsewhere, to know that there is an otherwise unseen aircraft approaching, within your chosen notification ‘Range’ and that it is ‘X feet above or below you, or at the same level, is instrumental in assisting and focussing visual scan or influencing potential action to increase separation (by changing altitude) and thereby reduce risk of collision.

You are of course correct, that this is nowhere near as good as having a positive position report, but with the best will in the world, it will be a long time before we persuade all those Mode C or Mode S aircraft owners to convert to ADSB, and while increased availability of MLAT positions from the PAW ATOM-GRID network is significantly improving the situation, it can’t as you know help when outside the range of Ground Station Coverage, or with Mode C.

I also acknowledge that there is an issue due to the existence of high-power CAT transponders, which can trigger alerts at greater range than expected, but with the increased uptake of commercial ADSB (and the demise of flyBe) the number of aircraft generating these high-power alerts has reduced considerably away from commercial airports (where ground radar still elicits high-power Mode-S responses from CAT aircraft on the ground). In either case, however, these high-power alerts present a specific ‘signature’ where the warning generally goes straight to ‘Danger’ rather than through the normal ‘Notice’ / ‘Alert’ / ‘Danger sequence which is triggered as ‘normal’ ‘GA’ aircraft approach. I have given considerable thought to this problem, and while we could apply a ‘compensating factor’, this would be extremely complex to achieve safely and could easily work against the existing system which if anything ‘fails safe’ by reporting the odd aircraft which is never likely to hit us, rather than delaying the report of an aircraft which might.

Yourself and Lee are to be congratulated on your recent work to improve co-operation and reporting between our respective systems, but we mustn’t ignore such a huge elephant in the room as unreported Mode C or S.

I realise we have more work to do to improve the reporting of Bearingless traffic, but if we can achieve simple audio alerts from SkyDemon, for example - ‘Bearingless Traffic - Notice/Alert/Danger - X-feet Above/Below or ‘Level - No Direction Available’, on GDL90, I’d be happy to fly with SkyDemon using GDL90 without associated visual warnings for the Bearingless Traffic.

I’m sorry to harp on about this, but until you accept the reality and work with us to achieve a solution to the Bearingless traffic issue, I genuinely fear that this will be the beast that will come back to bite us, if we continue to ignore it.

Very Best Regards as always

Peter
(PilotAware Development Team, but the views expressed here are principally my own)

Thanks Tim and Peter for helping me understand what the systems are doing so that I can configure my aeroplane to make best use and to recognise what it is telling me.

I don't mind the lack of range rings for a bearingless target, IF there was an audio call that would be more suitable. 
When I receive bearingless warnings from PAw I know that there are circumstances that can generate a bearingless warning which aren't an imminent threat, and I developed a personal processing protocol which allows me to hear the warning and react to it accordingly. For the sake of simplicity I could just turn it off, but I would rather have the info and make a judgement rather than not be informed.

I haven't yet had the time to properly compare what SD says vs the straight PAw speech, but I'll get there.
Either way SD passing this information through is a great benefit. Often more beneficial than a LARS service

Peter, I do not think that we are failing to "accept the reality" of anything. We are simply not willing to introduce spoken warnings into SkyDemon's system that do not meet our quality requirements.

I agree that 70% of traffic is bearingless, and at the altitudes I am operating at probably more like 90%.

Until SD introduces spoken warnings for bearingless targets (which could of course be muted in setup for users who don’t want this ‘distraction’) the way I am dealing with this is to put a separate tablet straight in my line of sight. Running SD in track-up mode to show the alert rings for conflicting bearingless traffic, plus the little traffic radar window for TCAS style representation of targets.

Apart from having the option to also get spoken warnings for bearingless traffic, there are a number of possible improvements that partly have been discussed here under their own topics:

- Allow to resize and position the traffic radar window-in-window

- Allow to independently adjust the font size for vertical separation

- Change of notation of vertical separation (from for example “+0.7” to “7” in line with international best practice)

- Within SD there already is frequent ‘double transmission’ between spoken airspace warnings and spoken traffic alerts:
-> Allow allocation of different voices (eg male and female) to the different types of spoken alerts
-> Allow option for incoming traffic alert to mute a parallel airspace alert
-> Use psychoacoustics to spatially separate the two (eg traffic from the right, airspace warnings from the left, assuming that the incoming radio transmissions remain to appear from centre)