Primarily for general aviation discussion, but other aviation topics are also welcome.
  • 1
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
#1699048
Shoestring Flyer wrote: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!


OK, I agree it can look congested at that zoom level - I had my screen on 1:500,000 - but you can zoom it to whatever level suits your setup (and vision).

The point of the post was to illustrate that we can easily differentiate between traditional ‘known’ (e.g. ADSB or FLARM) and MLAT-derived aircraft positions.

Regards

Peter
Smaragd liked this
#1699049
RobertPBham wrote: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?


Paragraph Edited: This type of traffic used to report as ‘OGN-UP’ (for ‘OGN Uplink’) but the Glider Guys said it made the screen far too crowded and we agreed, so Lee changed it to ‘G’ for Glider, but as everything from balloons and paragliders to Tocanos can be found using FLARM (or FLARM-compatible OGN Trackers), I now prefer to think of it as ‘(FLARM) ‘Ground Uplink’.

RobertPBham wrote: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?


Lee would need to confirm, but I’m pretty sure that being ‘Known Position’ MLAT is treated the same as ADSB or Flarm, with user configurable Settings in both PilotAware and most Proprietary Nav Systems.

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.


Mode C/S will continue to provide cover outside the areas covered by OGN-R.

Regards

Peter
RobertPBham liked this
User avatar
By Cub
#1699050
Peter

I am a little confused by your screenshots. I had the opportunity to check another source of surveillance data for the time related to your first two screenshots. You say that G-HAMR and G-BYUS are both being MLAT'd which may be true but at the time of your screenshot, G-HAMR was squawking 7402 with Mode S AND ADS-B out. G-BYUS was also squawking 7412 with Mode S, no ADS-B and a FLID of UAA102. Of more concern to me is that the position of G-HAMR is just as depicted in your screenshot, just crossing the coast just south of Crail but at that point, UAA102 (G-BYUS) is tracking EastNorthEast as indicated but approximately 1.5 miles further north of G-HAMR than indicated in your screenshot.

G-VDOG squawking 7402 with Mode S, no ADS-B is accurately depicted north of Leuchars as is G-RVEM, squawking 7000 overhead Glenrothes with Mode S and ADS-B out.

Finally, I was pleased to see that both you and your colleague in the two Quiks, G-TPAL and G-CMDG were both emitting ADS-B out and I am interested to know if that is via a transponder utilising PAW as a position source?

I will take a look at your afternoon flight, tomorrow but in the meantime, I would be interested in your thoughts about the above.
gaznav liked this
#1699063
Hi Cub,

Thanks for the feedback.

These were simply ‘in-flight screenshots’ taken during testing on Friday and posted to try to help allay some of the fears expressed on here and show how PilotAware are endeavouring to address the concerns expressed by yourself, Tim and others that we must be able to determine and differentiate clearly between ‘Known Position’ ADSB or FLARM and MLAT sources when passing information to the Nav Systems and their users.

I wish I had the benefit of access to your data sources, but have to rely on the data collected by my PilotAware and by the OGN-R (and 360Radar) receiving stations. I haven’t yet had time to carry out an analysis of the source data from the flights concerned, but will do so as soon as possible and will let you know what we find.

For the record, I run ADSB-Out from a Trig TT21 transponder, installed back in 2015 to take part in the Project EVA trials, (though my involvement was subsequently limited by lack of local ATC infrastructure to the trials run up here in Scotland by Trig). As this installation was ‘pre-PilotAware’ it is driven by a dedicated (and so far reliable) ‘Byonics 4’ (uncertified) GPS source integrated directly to the TT21, though I now have a Trig TN72 (with certified antenna) awaiting installation. I also run an advanced PilotAware Prototype (though this makes no significant difference to what we are testing here) plus a FlarmMouse, which can be directly integrated through the PilotAware, but for current testing purposes is deliberately running ‘in parallel’ - with its own dedicated FLARM display.

G- CMDG has a full certified TT21 / TN72 ADSB-Out installation with TN70 Type antenna together with a separate PilotAware.

As I say, I have been running ADSB out (Mode S-ES) together with PilotAware since 2015 and before that ran a Zaon PCAS from 2009 and dabbled with PowerFLARM Core. Since the inception of PilotAware however, I have noted a significant increase in the awareness of the positive benefits of Electronic Conspicuity amongst GA Pilots and that more and more go on to add a Transponder and connect it to their PilotAware (or as in my case an alternative GPS data source) to add Mode S-ES (ADSB Out). At least 10 of the 40+ flexwings at East Fortune have already gone down this route, as have many other GA aircraft I know of throughout the UK and beyond. So in my experience, far from being ‘anti-ADSB’, the inception and development of PilotAware has been significantly and directly responsible for the extremely positive increase in the take up and installation of ADSB throughout the UK and beyond. Hence my repeated requests on here and elsewhere to stop the infighting and work together for the benefit of us all.

Best Regards

Peter
Last edited by exfirepro on Mon Jun 10, 2019 6:40 am, edited 1 time in total.
ivor.phillips, PaulSS, Stu B liked this
User avatar
By Cub
#1699065
One further thought, G-BYUS/UAA102. Does this mean you are using the aircraft registration from some relational database associated with the Hex Code for your multilaterated contacts rather than using the emitted Mode S FLID?
#1699067
@Cub

An inbuilt database within each PilotAware is used to display aircraft Reg from received Hex ID. We deliberately don’t display the FLID to avoid breaching Flarm’s privacy rules. I would need to ask Lee / Phil about the effect of a dual transmission from a FLARM device not transmitting the aircraft ICAO Hex code.

Regards

Peter
Last edited by exfirepro on Mon Jun 10, 2019 7:34 am, edited 2 times in total.
User avatar
By Cub
#1699069
exfirepro wrote:@Cub

An inbuilt database within each individual PilotAware is used to display aircraft Reg from received Hex ID. We deliberately don’t display the FLID to avoid breaching Flarm’s privacy rules, but I would need to ask Lee / Phil about the effect of a dual transmission from a FLARM device not transmitting the aircraft ICAO Hex code.

Regards

Peter


More importantly you must surely use FLID in any operational deployment? If I am looking out for a contact that ATC are referring to as UAA102 it is going to be extremely confusing to be displaying G-BYUS.
#1699070
@Cub

I’m confused. Surely if the aircraft is dual transmitting, ATC would use the ‘Official’ designator from the ICAO - or just refer to ‘Traffic’ - how would they know we have a traffic display, let alone what type?

Peter
#1699072
Shoestring Flyer wrote:I am sorry but I personally find the clarity on those screen shots very poor!


I think you're being deliberately difficult!

1) As explained numerous times - you don't need to look at it at all if you don't want to - there are audio alerts

2) What could possibly be clearer than the inset traffic display (the bit with the black background)
johnm, Smaragd, ivor.phillips and 1 others liked this
#1699074
Hi Peter, thanks for posting those screenshots and for your detailed test.

It’s great that on the PilotAware side you have the ability to distinguish between adsb and mlat and ognr traffic but unfortunately we don’t on the SkyDemon side, because of the protocol issues already raised.

You mentioned one of the reasons for your test was to allay fears about the accuracy of mlat traffic that had been mooted on this thread, but they haven’t just been mooted, they have been demonstrated. I know I probably sound really picky and I acknowledge that most of the time, the mlat traffic is going to be just about exactly where 360radar says it is. But clearly that isn’t always the case so I would very much like to know everything that you know about the accuracy in those cases, so I can opt to display it differently or annunciate it differently.

It is a good thing that the mlat traffic data is available from so far away. However SkyDemon does not issue verbal information about traffic until it’s within visual range (as there’s no point) (an exception being fast jets) so one would have to be regularly monitoring one’s screen to have that sort of information in their brain.

I share concerns about your cluttered display on SkyDemon but your setup is up to you :D I’d like to mention that display of callsign is off by default in SkyDemon though. It isn’t considered particularly relevant for traffic avoidance, though can be nice for “spotting” obviously.
johnm, gaznav liked this
#1699075
stevelup wrote:
Shoestring Flyer wrote:I am sorry but I personally find the clarity on those screen shots very poor!


I think you're being deliberately difficult!

1) As explained numerous times - you don't need to look at it at all if you don't want to - there are audio alerts

2) What could possibly be clearer than the inset traffic display (the bit with the black background)


Well I don't think I am being difficult at all. Just trying to face up to what is useful and practical whilst flying a small aircraft. A a busy and already cluttered Nav screen is not the place to superinpose traffic IMHO.

1. Even exfirepro admits there are issues with audio alerts, especially in a busy circuit!
2. A tiny inset radar display in the corner of an Ipad tablet to view at 2-3ft away. Get real!
#1699077
Cub wrote:...Of more concern to me is that the position of G-HAMR is just as depicted in your screenshot, just crossing the coast just south..;

Hi Cub
Perhaps you could share your data for us to compare ?
As the screenshot only shows rounding to 60 seconds (the minute display), it would be preferable to show the minutes before and after

Thx
Lee
#1699081
Cub wrote:
exfirepro wrote:@Cub

An inbuilt database within each individual PilotAware is used to display aircraft Reg from received Hex ID. We deliberately don’t display the FLID to avoid breaching Flarm’s privacy rules, but I would need to ask Lee / Phil about the effect of a dual transmission from a FLARM device not transmitting the aircraft ICAO Hex code.

Regards

Peter


More importantly you must surely use FLID in any operational deployment? If I am looking out for a contact that ATC are referring to as UAA102 it is going to be extremely confusing to be displaying G-BYUS.


That’s a RAF Tutor - we have Mode S (where we set FLID of which UAA is a UAS/AEF callsign) and FLARM in/out if that’s any help
exfirepro, gaznav liked this
#1699088
Balliol wrote:
Cub wrote:
exfirepro wrote:@Cub

An inbuilt database within each individual PilotAware is used to display aircraft Reg from received Hex ID. We deliberately don’t display the FLID to avoid breaching Flarm’s privacy rules, but I would need to ask Lee / Phil about the effect of a dual transmission from a FLARM device not transmitting the aircraft ICAO Hex code.

Regards

Peter


More importantly you must surely use FLID in any operational deployment? If I am looking out for a contact that ATC are referring to as UAA102 it is going to be extremely confusing to be displaying G-BYUS.


That’s a RAF Tutor - we have Mode S (where we set FLID of which UAA is a UAS/AEF callsign) and FLARM in/out if that’s any help


Thanks @Balliol ,

That will help when analysing the track files.

Regards

Peter
gaznav liked this
#1699089
Shoestring Flyer wrote:1. Even exfirepro admits there are issues with audio alerts, especially in a busy circuit!

If audio alerts don't do it for you in a busy circuit the very last thing you should then be doing is being head's-in looking at a tablet!
  • 1
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21