Primarily for general aviation discussion, but other aviation topics are also welcome.
  • 1
  • 17
  • 18
  • 19
  • 20
  • 21
User avatar
By Cub
FLYER Club Member  FLYER Club Member
#1699105
exfirepro wrote:@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


I have obviously not explained myself properly; The UAS Grob will be talking to ATC and using it's callsign (FLID), in this case UAA102. If I were on the same frequency, perhaps joining the circuit behind UAA102, I will be listening to ATC's interaction with UAA102 and trying to correlate that with a target on my device, in this case SkyDemon. That though, would not be possible because PAW is processing and passing for display an aircraft registration G-BYUS which would mean nothing to ATC and potentially nothing to the pilot of UAA102 who probably has only noted the aircraft registration, to fill in his/her logbook, after the flight.

I am suggesting it is an unnecessary confusion which would be unacceptable in a deployed version when clearly the single point of truth is the FLID. I trust this is not another field in the GDL 90 protocol which is being 'bastardised' by PAW?
gaznav liked this
#1699119
I can't help thinking, reading through the thread again, that many of the polarised views coming out are largely dependant on which EC solution you originally invested in. It also strikes me that a lot of the concern about the clutter of the screen comes from those who don't fly with Pilot Aware on their SkyDemon and are simply looking at non-dynamic screen shots and making up their minds.

I would assert that like most things in aviation, currency makes using any piece of equipment more intuitive and natural. I was lambasted a few days ago on Facebook for showing a picture of stacks of gliders on SD with PAW via the OGNr in a 20 mile zoom out as you would never use that zoom level because it would be confusing. A few spotted that it was useful to be able to replan on the fly with the knowledge of where the hotspots are located.

Frankly I don't care which EC system shows me the best picture of traffic, I have them both, I also don't care which moving map displays the information, their parallel development over the last decade has made them much of a muchness.

I do know whichever system displays the most traffic, however generated and the moving map which cooperates with this development will be the one I spend my money with. I have a feeling I'm not alone in this.

It's probably not my place to give advice I'm just a consumer but I think the market will decide which EC system wins. Right now, I think this may be a primary driver for uptake of whichever moving map displays it best.



.... and another thing:

Switching off data by default is not ideal. For example: When SD switched off the registration number next to the traffic, we lost the ability to work with other aircraft's position reports to build picture of the intentions of the traffic around us. It's not just for spotting as is often mentioned.
Last edited by TLRippon on Mon Jun 10, 2019 11:48 am, edited 1 time in total.
chipmeisterc, kanga, ivor.phillips and 1 others liked this
#1699139
Dave W wrote:
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!


Absolutely agree and that is why I am advocating a dedicated means of viewing Traffic, on a screen if we must, but ideally a dedicated instrument of some kind! We need something with a simple view that is quick and easy to assimilate the traffic threat.
I am very concerned that what is being created is just going to give more heads in time !
There is also a degree of commercial interest being played out with some of the things being said on this subject!
Last edited by Shoestring Flyer on Mon Jun 10, 2019 11:28 am, edited 2 times in total.
gaznav liked this
User avatar
By Tim Dawson
SkyDemon developer
#1699140
There is a school of thought that says the more "stuff" you have showing on your screen, the better.

It is a school of thought that is tempting and many people fall for, but one I personally reject. Luckily a lot of people seem to have moved beyond it.
Cub, gaznav, Flyin'Dutch' liked this
#1699157
Cub wrote:I am suggesting it is an unnecessary confusion which would be unacceptable in a deployed version when clearly the single point of truth is the FLID. I trust this is not another field in the GDL 90 protocol which is being 'bastardised' by PAW?

Cub, its a configuration option, User selectable in both PilotAware and SkyDemon.
The choice can be made to display TailReg, FlightID or nothing - and this is possibly unrelated to GDL90, as it may have been using FLARM protocol, would need to check with @exfirepro regarding what method was selected.
User avatar
By Cub
FLYER Club Member  FLYER Club Member
#1699167
Shoestring Flyer wrote:
Dave W wrote:
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!


Absolutely agree and that is why I am advocating a dedicated means of viewing Traffic, on a screen if we must, but ideally a dedicated instrument of some kind! We need something with a simple view that is quick and easy to assimilate the traffic threat.
I am very concerned that what is being created is just going to give more heads in time !
There is also a degree of commercial interest being played out with some of the things being said on this subject!


Have you looked at or used SkyDemon Traffic? An exceptionally clever conflict processing algorithm with a very simple, easy to assimilate display and of course, can be run as a standalone display on your phone or second tablet using your original subscription.
gaznav liked this
#1699170
Tim Dawson wrote:There is a school of thought that says the more "stuff" you have showing on your screen, the better.

It is a school of thought that is tempting and many people fall for, but one I personally reject. Luckily a lot of people seem to have moved beyond it.


One of the key challenges of electronic conspicuity is that it's difficult to predict precisely how it will be most useful across the spectrum of applications to which it will be put. The filtering is an important aspect of that -- it would seem to make sense to make it configurable but default to inclusive to start with, and then converge on some sensible defaults as operational experience grows. Different applications and environments (e.g. enroute vs aerodrome, conflict alerting vs tactical deconfliction vs strategic deconfliction) will have different needs.

But that operational experience has to come from somewhere, which is why we need to get it out there by encouraging everyone to transmit something, whether via a CAP 1391 device, PilotAware, FLARM, a GPS source connected to a Mode S transponder. Thanks to all of you who contribute to making this happen.
PaulB, Keith Vinning, kanga liked this
User avatar
By Tim Dawson
SkyDemon developer
#1699180
I couldn't agree more, but that doesn't mean that blatting everything onto the screen without giving it some thought first is the best strategy. There are some things which are very hard to undo once they've been done sub-optimally.
Cub, PaulB, Shoestring Flyer and 4 others liked this
#1699199
leemoore1966 wrote:
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

@Cub
Hi Cub, can you please share your data reference ?

In the meantime, exfirepro supplied his flight data recorder information
This contains records of both the ADS-B position reports and mlat position reports
The ADS-B update for G-HAMR was very sporadic, I have no idea why this is the case, but the MLAT reports were frequently updated.
I have reduced the report to comparing positions to the ADSB, (when provided) against the next MLAT record

**edit** I was calculating the position error to the Receiver, not to each other, this is corrected

Summary, the average distance error is 0.28nm
- That is pretty good I think, here is the full listing
in the flight recorder we use an extended syntax for the PFLAA records attempting to (pessimistically) predict the NACp(Navigational Accuracy Parameter) and HFOM(Horizontal Field of Merit)

Code: Select all$PFLAA,0,15011,-24469,642,1,405051!G-HAMR,37,-0.5,49,3.8,14*14
$PFLAA,0,14836,-24600,642,1,405051!G-HAMR,38,0.0,46,3.8,14,6,NACp,0.30,HFOM*26
Error = 219M 0.12NM

$PFLAA,0,17849,-23615,569,1,405051!G-HAMR,20,1.0,52,6.1,14*3E
$PFLAA,0,17475,-23693,571,1,405051!G-HAMR,19,0.0,47,0.0,14,6,NACp,0.30,HFOM*29
Error = 382M 0.21NM

$PFLAA,0,18835,-23158,460,1,405051!G-HAMR,44,-7.5,45,4.4,14*11
$PFLAA,0,18363,-23451,466,1,405051!G-HAMR,59,0.0,53,4.4,14,5,NACp,0.50,HFOM*29
Error = 556M 0.30NM

$PFLAA,0,23516,-21742,232,1,405051!G-HAMR,55,0.1,62,0.0,14*30
$PFLAA,0,22698,-22390,246,1,405051!G-HAMR,54,0.0,59,0.0,14,5,NACp,0.50,HFOM*29
Error = 1044M 0.56NM

$PFLAA,0,25138,-19340,7,1,405051!G-HAMR,65,0.5,88,0.0,14*34
$PFLAA,0,24841,-20074,8,1,405051!G-HAMR,64,0.0,83,0.0,14,4,NACp,1.00,HFOM*27
Error = 792M 0.43NM

$PFLAA,0,24398,-18388,-52,1,405051!G-HAMR,126,12.2,14,0.0,14*22
$PFLAA,0,24980,-17804,-52,1,405051!G-HAMR,65,0.0,86,0.0,14,5,NACp,0.50,HFOM*33
Error = 824M 0.44NM

$PFLAA,0,23666,-14796,-172,1,405051!G-HAMR,75,-2.0,54,0.0,14*38
$PFLAA,0,23630,-15022,-169,1,405051!G-HAMR,79,0.0,66,0.0,14,6,NACp,0.30,HFOM*01
Error = 229M 0.12NM

$PFLAA,0,24651,7601,-229,1,405051!G-HAMR,325,-3.0,70,0.0,14*17
$PFLAA,0,24473,7769,-231,1,405051!G-HAMR,331,25.9,69,0.0,14,6,NACp,0.30,HFOM*15
Error = 245M 0.13NM

$PFLAA,0,26487,5657,-169,1,405051!G-HAMR,293,-0.7,79,0.0,14*1B
$PFLAA,0,26175,6148,-170,1,405051!G-HAMR,297,-0.5,82,0.0,14,5,NACp,0.50,HFOM*0D
Error = 582M 0.31NM

$PFLAA,0,30385,2452,-21,1,405051!G-HAMR,306,-0.5,59,0.0,14*29
$PFLAA,0,29931,2901,-33,1,405051!G-HAMR,308,-0.3,60,0.0,14,6,NACp,0.30,HFOM*35
Error = 639M 0.35NM

$PFLAA,0,35970,-5275,257,1,405051!G-HAMR,232,-2.7,64,0.0,14*13
$PFLAA,0,36589,-4409,256,1,405051!G-HAMR,256,0.0,58,0.0,14,5,NACp,0.50,HFOM*2C
Error = 1064M 0.57NM

$PFLAA,0,34217,-12230,398,1,405051!G-HAMR,276,0.0,66,0.0,14*07
$PFLAA,0,34104,-11443,397,1,405051!G-HAMR,273,0.0,55,0.0,14,6,NACp,0.30,HFOM*16
Error = 795M 0.43NM

$PFLAA,0,34230,-12302,405,1,405051!G-HAMR,274,0.3,66,0.0,14*00
$PFLAA,0,34240,-12204,401,1,405051!G-HAMR,276,0.0,66,0.0,14,8,NACp,0.05,HFOM*16
Error = 99M 0.05NM

$PFLAA,0,35373,-14470,493,1,405051!G-HAMR,287,0.0,60,0.0,14*05
$PFLAA,0,35207,-14084,517,1,405051!G-HAMR,287,4.6,69,0.0,14,6,NACp,0.30,HFOM*15
Error = 420M 0.23NM

$PFLAA,0,39114,-19755,765,1,405051!G-HAMR,304,-1.0,59,0.0,14*25
$PFLAA,0,39051,-19634,763,1,405051!G-HAMR,306,0.5,60,0.0,14,7,NACp,0.10,HFOM*1C
Error = 136M 0.07NM

$PFLAA,0,39279,-20227,786,1,405051!G-HAMR,296,-2.5,54,3.8,14*20
$PFLAA,0,39261,-19813,744,1,405051!G-HAMR,301,-1.0,54,-3.8,14,7,NACp,0.10,HFOM*1C
Error = 414M 0.22NM

$PFLAA,0,39597,-22232,886,1,405051!G-HAMR,284,-4.0,52,4.4,14*23
$PFLAA,0,39519,-21765,886,1,405051!G-HAMR,292,0.0,59,4.4,14,5,NACp,0.50,HFOM*1A
Error = 473M 0.26NM

$PFLAA,0,39982,-23150,886,1,405051!G-HAMR,289,0.5,58,4.4,14*06
$PFLAA,0,39870,-22916,886,1,405051!G-HAMR,288,0.0,54,4.4,14,6,NACp,0.30,HFOM*12
Error = 259M 0.14NM

$PFLAA,0,40295,-24188,855,1,405051!G-HAMR,280,-3.0,47,0.0,14*25
$PFLAA,0,40233,-23727,855,1,405051!G-HAMR,286,0.0,58,0.0,14,5,NACp,0.50,HFOM*15
Error = 465M 0.25NM

$PFLAA,0,44275,-31544,701,1,405051!G-HAMR,308,0.5,59,-2.2,14*29
$PFLAA,0,43882,-31048,701,1,405051!G-HAMR,307,0.0,60,-2.2,14,5,NACp,0.50,HFOM*3B
Error = 633M 0.34NM

$PFLAA,0,47477,-35627,487,1,405051!G-HAMR,300,0.0,81,-6.1,14*2E
$PFLAA,0,47261,-34989,487,1,405051!G-HAMR,309,0.0,76,-6.1,14,6,NACp,0.30,HFOM*3F
Error = 674M 0.36NM

avg=0.28

Thx
Lee
Last edited by leemoore1966 on Mon Jun 10, 2019 3:04 pm, edited 1 time in total.
User avatar
By Cub
FLYER Club Member  FLYER Club Member
#1699212
leemoore1966 wrote:Hi Cub, can you please share your data reference ?


Unfortunately, I can't.

leemoore1966 wrote:In the meantime, exfirepro supplied his flight data recorder information
This contains records of both the ADS-B position reports and mlat position reports
The ADS-B update for G-HAMR was very sporadic, I have no idea why this is the case, but the MLAT reports were frequently updated.
I have reduced the report to comparing positions to the ADSB, (when provided) against the next MLAT record


I don't believe I questioned the accuracy of G-HAMR. I used the position of G-TPAL, the receiving aircraft as the reference point and G-HAMR was almost spot on. What I was more concerned about was the position at that moment of UAA102 or as you call it GBYUS.
User avatar
By Cub
FLYER Club Member  FLYER Club Member
#1699216
leemoore1966 wrote: - That is pretty good I think, here is the full listing
in the flight recorder we use an extended syntax for the PFLAA records attempting to (pessimistically) predict the NACp(Navigational Accuracy Parameter) and HFOM(Horizontal Field of Merit)


This is kind of my point. You don't need to predict NACp for GHAMR. G-HAMR was emitting Mode S with ADS-B and generating a NACp value from the airframe perfectly successfully. You have chosen to 'bastardise' that parameter and then transmit your value rather than the true via an internationally specified protocol. That cannot be right and at some point down the line will result in serious confusion and simply detracts from the interoperability we are all trying to achieve.

If you need to, and I agree wholeheartedly that accuracy values are required for PAW multilaterated data but these should be specified via specifically named fields and supplied as an extension to the existing GDL90 protocol, to avoid any confusion or corruption of data in receiving applications IMHO.

Tim has suggested that a suitable extension is very straightforward to produce and I would bite his hand off if you were able to use his capabilities to produce such an extension for the onward transmission of PAW multilaterated data to the extent that he might be more comfortable using your data in his product. Or maybe you are not bothered?
gaznav liked this
#1699226
@Cub
Or maybe you are not bothered?


Why would you even bother writing such a stupid thing when you know full well he's 'bothered' and is trying to produce the best data possible?

Perhaps if you came up with something more than 'unable' when requested for your data things might progress. It's incredibly easy to sling s*#t from the sidelines but it takes a lot more to actually do something to help and all I've seen you do is criticise and put up roadblocks :roll:
Cub, PaulB, seanxair and 2 others liked this
  • 1
  • 17
  • 18
  • 19
  • 20
  • 21