Primarily for general aviation discussion, but other aviation topics are also welcome.
  • 1
  • 2
  • 3
  • 4
  • 5
  • 21
User avatar
By Cub
#1697348
Lee

I understand you are about to enable multilaterated traffic via PAW and 360 radar. My question relates to the position accuracy you are achieving and some assurance as to whether that accuracy is better than that depicted in 360 via their website?

Below is a screenshot just grabbed at random from 360radar, just now, of a non ADS-B GA aircraft presumably being multilaterated via 360radar. Whilst the functionality in support of the average plane spotter is commendable I question whether the obvious inaccuracies in the track are good enough to generate accurate traffic alerts using something like SkyDemon Traffic?

I also have a question for Tim and SkyDemon. Do you differentiate between PAW multilaterated tracks and directly received targets because I assume you will be giving me some indication of the accuracy of the target in SD Traffic?
Image
gaznav liked this
#1697393
As far as I know (and I have gently asked a couple of times) PilotAware will be sending us this multilaterated traffic information as if they were normal traffic whose position is known. That makes us unable to determine what has been multilaterated and what has not.

That’s a shame, if it’s true, because I would like our customers to “opt in” to receiving such data, at which point we could make them aware of the pitfalls.

I don’t want SkyDemon to tell somebody there is some traffic to their right when it’s actually on their left.
User avatar
By Cub
#1697395
riverrock wrote:Can I suggest you check it again a known track / aircraft rather than a random one?
FR24 has the same flight (I think) looking slightly differently: https://www.flightradar24.com/data/airc ... y#20bda4d4


I am not quite sure what you mean by check it again? My question to Lee is that my example and many other multilaterated non ADS-B tracks depicted on 360radar appear not to be good enough quality/resolution to generate accurate traffic information advice in tools like SD Traffic. I was wondering if Lee had any information on the accuracy achieved and whether the depicting software i. e. SkyDemon is likely to warn me of possible position errors with multilaterated targets.
User avatar
By gaznav
#1697401
@Cub

I have asked questions like these for some time.

The first was what is the latency between where a FLARM equipped glider is reporting where it actually is and where PAW reports it having received it from OGN-R? I’ve still get an answer better than - speed of light, you can’t beat the laws of physics.

The second was when we had the NACp debate and SkyDemon was putting circles of probability around tracks. Again, accuracy was asked without an answer.

I really feel that some form of academic trial, using someone like QinetiQ, should be done to understand exactly what a device like PAW and its ground stations is actually doing - what will it detect, to what accuracy, what will it display and when?

I know that the standard specified in CAP1391 was the result of Project EVA’s field trials and also two QinetiQ trials. So at least we have some idea what we are getting with devices that are certified to conform to CAP1391. Is it time to set standards for things like FLARM and PAW too?

Gaz
By johnm
#1697403
This is doing my head in. I think I may be going back to FLARM and ADS-B. Experience with traffic service is that primary contacts are either gliders or in the weeds and those transponding I get an accurate position for.
#1697420
gaznav wrote:
I really feel that some form of academic trial, using someone like QinetiQ, should be done to understand exactly what a device like PAW and its ground stations is actually doing - what will it detect, to what accuracy, what will it display and when?


This feels more suited to a design and controls review than a trial per se.
Theoretically I see no reason why MLAT can't be at least as accurate as primary or mode-C radar - both are fundamentally about timing.
The real issue seems to be around calibration and integrity checking.
The problem with most of the MLAT solutions being discussed is that they rely upon relatively uncontrolled distributed receiver networks - therefore it is the controls/checks to identify unreliable data that become key.

An MLAT trial one month might give perfect results (particularly if a lot of human effort is being spent watching it, making sure clocks are in-sync, received station locations are accurate, etc) ...... but if the system is then allowed to run with less scrutiny, data quality may drop.

My personal experience of 360radar has been that the results seem very good - a relatively simple check being watching MLAT final approaches ..... that could give false confidence however that it is always so.
gaznav, Cub liked this
#1697429
gaznav wrote:@Cub

I have asked questions like these for some time.

The first was what is the latency between where a FLARM equipped glider is reporting where it actually is and where PAW reports it having received it from OGN-R? I’ve still get an answer better than - speed of light, you can’t beat the laws of physics.

The second was when we had the NACp debate and SkyDemon was putting circles of probability around tracks. Again, accuracy was asked without an answer.

I really feel that some form of academic trial, using someone like QinetiQ, should be done to understand exactly what a device like PAW and its ground stations is actually doing - what will it detect, to what accuracy, what will it display and when?

I know that the standard specified in CAP1391 was the result of Project EVA’s field trials and also two QinetiQ trials. So at least we have some idea what we are getting with devices that are certified to conform to CAP1391. Is it time to set standards for things like FLARM and PAW too?

Gaz

I don't see how that helps the OP's query. The question is not about "what a device like PAW and its ground stations is actually doing". It's about the accuracy of MLAT data itself from 360 Radar that will eventually be fed through to Pilotaware - is it going to be better than that which appears on the the 360radar website?
Cub liked this
User avatar
By gaznav
#1697436
johnm wrote:This is doing my head in. I think I may be going back to FLARM and ADS-B. Experience with traffic service is that primary contacts are either gliders or in the weeds and those transponding I get an accurate position for.


Mate, it’s been doing the same for me too. You see with a transponder or ADS-B transponder you get a known output standard that they have to be manufactured to. There has been some independent testing of FLARM such as this: https://members.gliding.co.uk/wp-conten ... report.pdf
Or
https://www.researchgate.net/publicatio ... tory_Study
Or
http://journals.sfu.ca/ts/index.php/ts/ ... ad/614/577

But I am unaware of anything for PAW? The above ones don’t really answer all the questions for on FLARM either. I’ve always seen the problem with FLARM is the very low power level it radiates at (even Power FLARM) and that means low(ish) detection ranges of normally 3-5nm. That is just about the minimum useful range for GA aircraft speeds - although 10nm would be better. But it was designed for gliders to stop bumping into each other in thermals or on the ridge - so it does what it was designed for I believe.

But as we go down the EC pathway we are seeing more and more tech being brought in without that level of assurance you would want from a flight safety critical device (IMHO). So we end up with posts like Cub’s above asking whether this will deliver what people think it will deliver - we do need to assure the standard of that data presented to us though, otherwise it could be a dangerous thing to do.

In my humble opinion (standing by... :cyclopsani: )
User avatar
By gaznav
#1697438
@Boxkite

I don't see how that helps the OP's query. The question is not about "what a device like PAW and its ground stations is actually doing". It's about the accuracy of MLAT data itself from 360 Radar that will eventually be fed through to Pilotaware - is it going to be better than that which appears on the the 360radar website?


What I was trying to articulate is - do you actually know what the PAW and its ground stations are displaying to you, do you have any assurance on the quality of that data and if that MLAT data is of poor quality what will the system display to you?
User avatar
By Cub
#1697469
Boxkite wrote:
gaznav wrote:@Cub

I have asked questions like these for some time.

The first was what is the latency between where a FLARM equipped glider is reporting where it actually is and where PAW reports it having received it from OGN-R? I’ve still get an answer better than - speed of light, you can’t beat the laws of physics.

The second was when we had the NACp debate and SkyDemon was putting circles of probability around tracks. Again, accuracy was asked without an answer.

I really feel that some form of academic trial, using someone like QinetiQ, should be done to understand exactly what a device like PAW and its ground stations is actually doing - what will it detect, to what accuracy, what will it display and when?

I know that the standard specified in CAP1391 was the result of Project EVA’s field trials and also two QinetiQ trials. So at least we have some idea what we are getting with devices that are certified to conform to CAP1391. Is it time to set standards for things like FLARM and PAW too?

Gaz

I don't see how that helps the OP's query. The question is not about "what a device like PAW and its ground stations is actually doing". It's about the accuracy of MLAT data itself from 360 Radar that will eventually be fed through to Pilotaware - is it going to be better than that which appears on the the 360radar website?


Exactly, sir.
gaznav liked this
User avatar
By Cub
#1697474
johnm wrote:This is doing my head in. I think I may be going back to FLARM and ADS-B. Experience with traffic service is that primary contacts are either gliders or in the weeds and those transponding I get an accurate position for.


John

That is kind of my point. When you receive information via a radar controller about a primary or secondary contact utilising a certified piece of equipment, you can be confident about its position accuracy. If you receive that data via a receiver approved for the purpose (CAP 1391) and annunciated via piece of software such as SkyDemon Traffic, up until now you can also be confident of its position accuracy. However, via the ‘bastardisation’ of the GDL90 protocol to display relayed third party data we are now in a position of sharing data of dubious quality which will undoubtedly lead to misinterpretation if not purely incorrect conflict alerting.

IMHO the striving of some parties to display more and more contacts via their system, with little regard to the quality of that data, or at least an indication of the integrity of individual target information has gone too far.

Finally, if I were SkyDemon I would be extremely concerned about the continued utilisation of such data in my alerting algorithm when everything I have developed up to know, has been focussed on delivering accurate and timely warnings with a high degree of integrity.
gaznav liked this
User avatar
By PaulSS
#1697495
IMHO the striving of some parties to display more and more contacts via their system, with little regard to the quality of that data,


Yeah, I'm sure the PAW people wouldn't have given more than a couple of minutes thought as to data quality and accuracy :roll: :roll:

The original question has been discussed before on this forum but I get the distinct impression you're just happy to chip in with another negative PAW post instead of using the search function.
  • 1
  • 2
  • 3
  • 4
  • 5
  • 21