Primarily for general aviation discussion, but other aviation topics are also welcome.
  • 1
  • 18
  • 19
  • 20
  • 21
  • 22
  • 29
#1664381
Sorry, I'll ask a daft question - Where is this uncertainty being generated? It it a function of the GPS, the EC device (ADS-B) or the developer's App? What is defining the NACp figure?
#1664384
Tim Dawson wrote:If it transpires that for ADS-B outputting aircraft the uncertainty is usually pessimistic, and that actually the aircraft is usually just about where it says it is, I agree it would be helpful.

However a complication is that PilotAware are proposing to use this same flag for another purpose, which is to represent the uncertainty inherent in a multilaterated position. In that case, it might be as likely as not that the aircraft is actually on your left when it's reporting it's on your right. There isn't much evidence at this point.


I think there is something very 'fishy' happening here, I cannot reasonably believe that ADS-B positions are being reported with an uncertainty of 10nm

For the MLAT positions on GA, the vast majority are below 0.3nm, and we are certainly seeing nothing at all in these ranges reported by gaznav

Thx
Lee
#1664386
Dave Phillips wrote:Sorry, I'll ask a daft question - Where is this uncertainty being generated? It it a function of the GPS, the EC device (ADS-B) or the developer's App? What is defining the NACp figure?

The NACp figure is calculated by the transceiver/transponder using information from the GPS device.
There is no inherent GPS/NMEA message which defines the NACp value transmitted over ADS-B

I would also add that we trawled over a large number of historical flight recorder data obtained from PilotAware users, and we have only observed NACp figures (other than 0) as follows

Code: Select allNACp=02(4nm)    7
NACp=03(2nm)    24
NACp=06(0.3nm)  1
NACp=08(0.05nm) 231
NACp=09(30M)    3988
NACp=10(10M)    1879
NACp=11(3M)     801


*edit*
first time I have looked in detail at this data, and in fact there was the following with a SIL of 3, seems a bit of an outlier
ICAO=461F4D
NACp=06
SIL=03
https://www.planespotters.net/hex/461F4D
T67M, gaznav liked this
#1664390
Hmmm, so I trotted outside and switched on my SE2. Once there was a 3D fix the SE2 reckoned it was shoving out a NACp of 9.

Image

Makes one wonder what combination was causing gaznav's circles of death. I'm not sure it would be a Finnair A350 :lol:
gaznav liked this
User avatar
By xtophe
#1664391
The NATS GA ADS-B GPS trial report have the following in its exec summary (p. 6):

Code: Select allThe Navigational Accuracy Code for Position (NACp) quality indicator that reports the expected accuracy of the position reported, was on the whole found to be very conservative in the non-certified fleet; however this is better than over-estimating the accuracy capability.


And more in section 4.11 (p. 38)
gaznav liked this
#1664393
A few data points and references. I don't think anything is fishy, I believe we are trying to use NACp in a way that it was not intended.

The accuracy defined by NACp is very course, and is intended to aid ATC in their typical 3 and 5 mile separation of IFR traffic. Not necessarily for precision or close range collision avoidance.. The ATC "system" (generic sense) relies on both GPS integrity and accuracy.

NACp is derived from the instantaneous accuracy figures, but is conservative number to indicate "95% accuracy limits for the horizontal position that is being currently broadcast" (from DO-260B). Therefore, the number represents a 95% certainty that the "target" is within that circle. Even if the instantaneous calculation is fairly accurate, there may be conditions (constellation, lack of SBAS, atmospheric, airframe shadowing) that cause the 95% certainty "bubble" to expand.

Also from the same doc: NACp "is reported so that surveillance applications may determine whether the reported geometric position has an acceptable level of accuracy for the intended use. Note, none of these uses indicate GA self separation.

As for the intended use, the table below for reference, also from 260B:



I know of no other EFB that uses this figure in this way, but I could be wrong.
Image

Also, I know its been discussed before but integrity and accuracy are different things. An interesting discussion can be found here:
https://gssc.esa.int/navipedia/index.php/Integrity#Integrity_vs._Accuracy

Finally, an interesting article, while not exactly relevant to the discussion - can give some insight into the various space and atmospheric conditions that can degrade GPS performance at any given time.

https://www.gpsworld.com/the-iono-blob-holds-back-air-safety-advances/
gaznav liked this
#1664402
uAvionix-Ramsey wrote:I know of no other EFB that uses this figure in this way, but I could be wrong.

Hi Christian
EasyVFR also uses the NACp to denote an area of ambiguity.

The accuracy defined by NACp is very course, and is intended to aid ATC in their typical 3 and 5 mile separation of IFR traffic. Not necessarily for precision or close range collision avoidance...


I think I disagree with that point, and here is an excerpt from the GDL90 specification related directly to NIC/NACp (which is what we are referring to in this context)
https://www.faa.gov/nextgen/programs/ad ... D_RevA.PDF
MFD Recommendation: Targets with either a NIC or NACp value that is 4 or lower (HPL >= 1.0 NM, or HFOM >= 0.5 NM) should be depicted using an icon that denotes a degraded target

*glossary* MFD = Multi Function Display

Now arguably this could mean a specific icon rather than an ambiguity circle (which was discussed earlier in the thread), but if the Traffic Receiver is going to pass traffic information with NACp values over the GDL90 interface, then I presume the Display tool is expected to make use of that data in some manner ?

Thx
Lee
gaznav liked this
User avatar
By Tim Dawson
SkyDemon developer
#1664438
leemoore1966 wrote:EasyVFR also uses the NACp to denote an area of ambiguity.


Presumably only because you asked them to, in order to help support your multilateration trial?
leemoore1966 liked this
User avatar
By gaznav
#1664489
leemoore1966 wrote:@gaznav
Looking at your original posting (and measuring on google maps), it would appear that the following ADS-B Aircraft are sending a NACp of the following values

Code: Select allG-BDFR // NACp=2.0nm
G-HMCF // NACp=2.0nm
G-EDGA // NACp=10.0nm


I think we need to understand why these numbers are so poor

As @Paul_Sengupta says, GPS is rarely that bad, so it sounds like a possible interpretation error either at the Transmission end (to be determined) or at the receiver end, SkyEcho2

Thx
Lee


Hi Lee

I will be looking at the instal on HMCF and EDGA tomorrow. I’m pretty sure the latter has just recently had a fully certified ADS-B Out fit and so the fact it was pushing out NACp = 1 of 10nm is pretty shocking :shock:

I’ll report back. Interestingly the same aircraft were all pretty much exactly where they were showing on ForeFlight using exactly the same SkyEcho 2, so I very much doubt it is a problem with the receiver.

I also had a bit of think about the way SkyDemon displays this. If the NACp is 1 (ie. 10nm) and then SkyDemon displays the aircraft’s reported position, which could be up to 10nm (unlikely but possible) and then SkyDemon puts a 10nm circle around that erroneous position, then actually the aircraft displayed could be 20nm from where it is actually displayed on SkyDemon? I think that is right, which would be really bad.

I must restate that every aircraft reporting these lower NACps appeared to be exactly where they were reporting their position. That also chimes with NATS’ Project EVA report that stated there were very few position errors compared to that observed with their RADAR.

All

Finally, seeing as this thread started to be all about FLARM and SkyEcho 2 - then for those just catching up - the FLARM reception with SkyEcho 2 and SkyDemon seems to work a treat, being aircraft to aircraft without any requirement for a 2nd party broadcast. Mega! :thumleft:
kanga, Nick liked this
User avatar
By gaznav
#1664526
Dave Phillips wrote:Hmmm, so I trotted outside and switched on my SE2. Once there was a 3D fix the SE2 reckoned it was shoving out a NACp of 9.

Image

Makes one wonder what combination was causing gaznav's circles of death. I'm not sure it would be a Finnair A350 :lol:


@Dave Phillips

#metoo! I have only ever noticed high NACp numbers of around 9 on my SkyEcho 2 - which is less than 30 metres accuracy. Further, I have never seen a big red circle from a SkyEcho emitting aircraft.

Image
By patowalker
FLYER Club Member  FLYER Club Member
#1664558
gaznav wrote:In fact, I have got my answer on HMCF and it uses a Nesis Glass Cockpit that has a 10 Hz, 66 channel, sensitivity -165 dBm GNSS/GPS. That should be perfectly good enough to give out a position quality better than 2nm!

https://www.kanardia.eu/product/nesis/#

So it is not using PAW as its position source for ADS-B.


But PAW must have been used to verify the accuracy of the position source, in order to get the mod approved by the LAA.

I wonder how useful that test is. My aircraft showed up exactly where it was, 0.1 km away. That could hide errors at greater distances. Better not tell Francis. :)

Position the PilotAware and associated computer at a safe distance from the aircraft – a nearby
clubhouse is ideal!
gaznav liked this
  • 1
  • 18
  • 19
  • 20
  • 21
  • 22
  • 29