Primarily for general aviation discussion, but other aviation topics are also welcome.
  • 1
  • 23
  • 24
  • 25
  • 26
  • 27
  • 29
User avatar
By gaznav
#1664891
Lefty wrote:
gaznav wrote:@Cub


I think @GrahamB and I are the most closely aligned on this - let’s have the same sized symbols for different levels of confidence of their data depicted by either colour, shade or shape? Then if we know there is a lower confidence in the position quality then the pilot will need to expand their scan a bit more?


I’m sorry, but I can’t help thinking that all these suggestions of circles, or different coloured, different sized or blinking target, can only serve to force pilots into spending more and more time staring at the SD screen - and almost zero time looking outside. It is fundamentally a bad thing.

Re the alleged poor accuracy being reported by these transponders. Surely for the purpose of EC, we should accept that in 99% of instances, the GPS is actually accurate to within 30-50m and just accept that since the GPS is accurate > 99% of the time, then we shouldn’t add more complexity that simply gives the user (prop 99) incorrect data.

It is clear that a few folks are doing a lot of working trying to perfect EC on SD, which I applaud and thank them for.

However I reiterate my view is that ideally, Traffic Awareness info should NOT be combined with Nav info, but should have it’s own clock face style display that is small enough to be in the pilot’s view whilst he is looking out. (It should also give an audible warning of traffic 2 o’clock 4 miles, 500 ft above). If Tim could offer a facility to have a 2nd phone or similar display device displaying nothing but traffic - I think it would be a winner.


Hi Lefty

There already is. This is the SkyDemon Traffic Display - only selectable as a standalone display on a Smartphone. This is what I use on my old iPhone 5s whilst my iPad does the Nav display.

Image

It even beeps, flashes and squeaks at you when there is a conflict. Which is fantastic. I just need to convince Tim Dawson to allow 3x iPhone/iPad type devices in lieu of my PC licence that I never use and then I would be happy :thumleft:

Here it is mounted on my instrument panel with a bit of velcro. It works a treat. Also, if I haven’t got room in the Condor due to a passenger then I can use this in Nav mode to keep an eye on airspace and NOTAMs as well. :thumleft:

Image

It can also be mounted to display the other way up. This is what it looks like when it “beeps, flashes and squeaks” at you:

Image
Last edited by gaznav on Sat Jan 12, 2019 5:42 pm, edited 1 time in total.
kanga, Nick liked this
#1664894
uAvionix-Ramsey wrote:I interpret this a slightly different way. By definition a SIL=0 GPS has no integrity (in GPS aviation terms) and therefore the maximum NACp "uncertainty" radius is entirely appropriate when compared to any certified GPS SIL 1-3..

So is this a recent addition to the SkyEcho2 receiver ?
This would explain how @gaznav is seeing this but not @Cub
To be honest I think once the uncertainty exceeds possibly 2nm, it would be better to either exclude these ADSB targets or represent them as bearingless

To have targets with 10nm of uncertainty is pretty useless.
Even more crazy, is providing ADSB NACp, that are of no use, and causes so much frustration it is ignored by the display

If you are to provide the maximum uncertainty, what would you propose the EFB such as SkyDemon does with this information?

Thx
Lee
User avatar
By gaznav
#1664896
leemoore1966 wrote:
uAvionix-Ramsey wrote:I interpret this a slightly different way. By definition a SIL=0 GPS has no integrity (in GPS aviation terms) and therefore the maximum NACp "uncertainty" radius is entirely appropriate when compared to any certified GPS SIL 1-3..

So is this a recent addition to the SkyEcho2 receiver ?
This would explain how @gaznav is seeing this but not @Cub
To be honest I think once the uncertainty exceeds possibly 2nm, it would be better to either exclude these ADSB targets or represent them as bearingless

To have targets with 10nm of uncertainty is pretty useless.
Even more crazy, is providing ADSB NACp, that are of no use, and causes so much frustration it is ignored by the display

If you are to provide the maximum uncertainty, what would you propose the EFB such as SkyDemon does with this information?

Thx
Lee


The way I would like it in my most humble opinion would be for apps like SkyDemon to show traffic of high certainty in say white as they show here:

Image

And maybe those of NACp<=4 or SIL=0 as a different colour. Maybe with a red outline or with an exclamation mark next to them? That way, you would have an indication what is good and what is not so good?

The same for the SkyDemon Traffic Display, maybe? So on the one below maybe an exclamation mark next to it if it is low quality info?

Image
User avatar
By gaznav
#1664897
PS. I would not present them as bearingless as that would be a real waste. As I offered several times on this thread - whilst the position quality is reported as poor the aircraft invariably appears to be pretty much where it says it is. So to change that to bearingless would be a bad idea in my humble opinion.
User avatar
By GrahamB
#1664899
gaznav wrote:I just need to convince Tim Dawson to allow 3x iPhone/iPad type devices in lieu of my PC licence that I never use and then I would be happy.

You don't need a third login - just log it in and switch it to off line mode. Then go back to your other devices and log them out and back in again.

The old phone will continue to work in 'go-flying' mode with the radar display perfectly well in off-line mode.
Last edited by GrahamB on Sat Jan 12, 2019 6:01 pm, edited 2 times in total.
#1664900
From CAP 1391 (my bolds)

6.12
EC devices are intended to offer similar functionality to FLARM, but using the 1090MHz airborne spectrum. EC devices are expected to comprise commercial off the shelf (COTS) items such as Software Defined Radios (SDRs), GNSS receiver chipsets and, where applicable, altitude transducers, which are acceptable on the basis that Quality Indicators reported by the device, such as NIC, NAC, GVA, SIL and SDA shall report the lowest quality (refer to Table 4). EC devices may report barometric or GNSS altitude.


and then

Quality Indicator reporting
6.29 The Quality Indicators shall be reported by the EC device as detailed in Table 4.

(CAA define "Shall) in the preamble.

Table 4
Image

I think Christian has no option but to report a NACp=0 if he is to comply with CAP1391.
Last edited by Dave Phillips on Sat Jan 12, 2019 6:03 pm, edited 1 time in total.
gaznav liked this
User avatar
By gaznav
#1664901
On the subject of traffic on the Nav display, then I find this useful. Here is why. If you look at my picture above there is traffic just North of Enstone at 1,000ft above me. So if I look just North of Enstone slightly above the horizon then I should see what I am looking for - this is the ‘big to small’ principle and it has worked for me in Air Navigation for the past 30 years; it has never let me down. :thumright:
Paul_Sengupta liked this
User avatar
By gaznav
#1664902
GrahamB wrote:
gaznav wrote:I just need to convince Tim Dawson to allow 3x iPhone/iPad type devices in lieu of my PC licence that I never use and then I would be happy :thumleft: {/quote]

You don'y need a third login - just log it in and switch it to off line mode. Then go back to your other devices and log them out and back in again.

The old phone will continue to work in 'go-flying' mode with the radar display perfectly well in off-line mode.


Thanks Graham, I did not know that. Normally, I have to faff with this between my iPad, iPhone 5s and iPhone 6s Plus. Mega :D
#1664908
Dave Phillips wrote:I think Christian has no option but to report a NACp=0 if he is to comply with CAP1391.


Hmm, isn’t this referring to ADSB transmission for CAP1391 ?

What I was referring to is ADSB reception and consequential GDL90 formatting

If we are going to encode the NACp field of GDL90, what is the intended purpose?
I would presume it is to instruct the EFB to use the data in some manner

Or should it just be ignored?
#1664910
Clearly the reason Garmin added NACp to the GDL90 protocol was that they thought an app might find it useful. Quite reasonable.

That doesn’t mean it actually is, though. The fact is, transponders are pushing out NACp values that are not useful.

I’m with Lefty. All this symbology stuff is a red herring as it suggests the user should keep checking the screen.
kanga, gaznav, Nick liked this
#1664912
leemoore1966 wrote:[
Even more crazy, is providing ADSB NACp, that are of no use, and causes so much frustration it is ignored by the display

If you are to provide the maximum uncertainty, what would you propose the EFB such as SkyDemon does with this information?

Thx
Lee


Lee, I wouldn’t disagree that you focus was on ‘recieve’ but I was responding to your bit I’ve quoted above.
leemoore1966, gaznav liked this
#1664915
Tim Dawson wrote:The fact is, transponders are pushing out NACp values that are not useful.

This is sounding like the root cause here, the strange thing as I mentioned earlier in the thread, we have tons of records in flight recorder data provided by users. We log the NACp figures, and for all the data we have, the vast majority is NACp=0
I cannot understand where all these NACp figures are being produced

Thx
Lee
kanga, gaznav liked this
  • 1
  • 23
  • 24
  • 25
  • 26
  • 27
  • 29