Enhancement Requests

[scsirob]

I have two requests for the 'To-do' list.

1. In previous versions the traffic web page showed the squawk code. The latest doesn show this anymore. I'd like to see that returned if possible.

2. When I observe the traffic on EasyVFR or look at the NMEA codes, I see alternating identifications for a single flight. It alternates between the flight number (eg. KLM65L) en the aircraft registration (PH-BXG). The identifications appear to switch almost simultaneously for all flights in range, which seems to me that PAW decides which identification to report. If at all possible I would like an option to select which ID is displayed (Aircraft, Flight or alternating). For instance, suppose you have to report a near-miss, then having the aircraft registration is a lot more useful than the flight ID.

Thanks, and happy Holidays everyone!
Rob

[Admin]

Hi Rob

1. In previous versions the traffic web page showed the squawk code. The latest doesn show this anymore. I'd like to see that returned if possible.

Hmm, think you are confused here, I have never printed the squawk code in the traffic table.
Maybe you are mixing this up with the dump1090 table, which does display the squawk code.
That said, it would be quite easy I think to add the squawk code to the table.

2. When I observe the traffic on EasyVFR or look at the NMEA codes, I see alternating identifications for a single flight. It alternates between the flight number (eg. KLM65L) en the aircraft registration (PH-BXG). The identifications appear to switch almost simultaneously for all flights in range, which seems to me that PAW decides which identification to report. If at all possible I would like an option to select which ID is displayed (Aircraft, Flight or alternating). For instance, suppose you have to report a near-miss, then having the aircraft registration is a lot more useful than the flight ID.

There is an option under the Web Configure Menu 'Display Annotation', this can be set to Alternate (default setting), or remain fixed on FlightID or Reg
You can choose.
The reason it is set to Alternate, is because when in an ATC, Commercial Traffic will use their flight ID in Radio Comms, whereas we (GA) will use our Reg.
So if you are listening out and hear either a FlightID or a Reg, you should be able to confirm on the display - at least that is the logic.

Merry Christmas to you too!
thx
Lee

[scsirob]

Hmm, think you are confused here, I have never printed the squawk code in the traffic table. Maybe you are mixing this up with the dump1090 table, which does display the squawk code.
That said, it would be quite easy I think to add the squawk code to the table.

Ah, yes! Spot on. I was playing with dump1090 on my PC for a while and it does indeed show the squawk codes.

There is an option under the Web Configure Menu 'Display Annotation', this can be set to Alternate (default setting), or remain fixed on FlightID or Reg
You can choose.

Oh boy, do I feel dumb  That was exactly the option I had in mind, just missed it in the config screen. Just tried it, works perfectly.

Thanks Lee!

Merry Christmas,
Rob

[lmoon]

Hi Lee

Regarding the audio messaging out. I plan to use the rs232 output (bridge connect at 4800 baud) to feed into a PIC cpu that will parse the sentences for The $PFLAU sentence. I will save it in a buffer and extract the bearing, level and range information from it. The PIC will then send a serial command to a micro PFLayer MP3 player - which has pre recorded messages on it - which will inject the message into the pilots headset.  I plan to work 'backwards' i.e. get the MP3 player to play the stored messages first - this is because the 'manual' is not clear and I think that there will be a bit of head banging going on!!.  I have done another project on parsing serial strings so should be OK there. Interfacing TTL RS232 signals should be OK.  I do have a bus pass and can remember when software came on an 8" floppy disk, CPM was the main operating system, 32K of ram was the norm and 4Mhz CPU's were the new kid on the block!!  If you think I am on the right track I am happy to share the details of the system on this forum as it progresses.

kr

Lionel

[flying_john]

This sounds a great idea Lionel. I am not up to speed on the Pi architecture, but is it possible to have another background process running in the Pi to seize this data, parse the string and generate audio from the Pi's resources rather than using another cpu off board ?. Is the PFLAU string accurate enough to determine if the "threat" aircraft is within your aircraft's zone of concern. 

If it is not possible to do it within the Pi - perhaps we should be lobbying the App providers (RunwayHD, Skydemon etc) to analyse the  $PFLAU and generate the audio.

Whichever way, I think it is essential to have an audio alert to a possible threat, ideally in the same form you would get it from a Radar controller, "Traffic 2 o'clock 3 miles"...

John

[Admin]

Hi All

The intention has always been to use the audio output of the PI for Alerts.
We have been pretty consumed with other activities up until now 

I had done some initial investigations into using the ALSA library in order to synthesize these messages.
I think this is easily doable, this just hasn't rippled to the top of the priorities right now.

Thx
Lee

[AlanG]

Hi
EasyVFR currently has voice alerts for traffic and other infringements switchable by the operator, although I'm not sure if this is just in the Beta version I am currently testing prior to a new release.
Maybe not quite ATC standard but enough to get your eyeballs where they need to be.

Alan

[SteveHutt]

Don't forget the difference between:
a) audio alerting on all detected traffic, and
b) only audio alerting for traffic that is assessed to be on a conflicting trajectory

Users will start to disregard alerts if strategy a) is adopted and 99% of alerts are false alarms.

Also, if PAW were doing the audio alerting on the RPi and another device is using visual alerting (Red/Amber/Green) on the display
there is potential for confusion if the PAW and display device are using different algorithms to decide upon threat level.
Much better if the visual and audio alerting is running off the same threat assessment algorithm.
And much easier to ensure the same threat assessment algorithm is used if driven from the the same place.

Steve

[Admin]

Hi Steve, Alan

Interesting comments regarding audio alerts, let me put in my 2 Cents

Whenever I take up a passenger for the first time, I explain the background to 'good lookout', and I will instruct them how to communicate back to me if they get any visuals on traffic, so for example, please tell me 'traffic 1 o'clock - high'

I view PilotAware as another passenger or Co-Pilot in the cockpit, who will give me similar information, but it will be upto me to decide what to do with that information.

So for me I think the best usage of audio feedback, would be a similar scenario to having a passenger (or Co-Pilot) with 20/20 vision who does nothing but continually scan the skies for traffic within a visual range, because this would be the perfect scenario we could ever hope for under VFR rules today.
I do not want him to assess the threat, simply provide the information, because I am the PIC, and that is my responsibility.

I think it is a very brave man (or programmer in fact) who starts to implement algorithms to provide advice or risk assessment, many a good algorithm has been proven to be un-prepared by a 'perfect storm' of simultaneous (unexpected) events.

Part of my 'real' job is performing verification for highly complex electronic systems, we use techniques such as formal verification, directed scenario testing, and constrained random test generation. I can tell you that it is incredibly difficult trying to achieve what we call 'coverage' for all possible types of scenario. Defining the sets of scenarios to constrain the problem is even more complex.

I like (and continue to research) the idea of audio alerts, but for the time being I would intend to provide alerts as though I had the best Co-Pilot in the world (kindly supplied by Carlsberg) sat in the seat next to mine, and nothing more.

Thx
Lee

[AlanG]

Hi Lee
What a brilliant answer, i wish i had thought of that but here's a quote from an email on the subject of "Mode A/C/S alerts" I sent on 06/01/2016, I think to Rob at EasyVFR and yourself:-

"Lets not forget there are still aircraft flying without radio never mind xpdrs or PAW. I'm not sure if it was intentional but it is my belief that the PilotAware system is very well named and should be marketed as just that.  It should not be viewed as a Collision Avoidance System but a devise to make pilots aware that there is other traffic in their vicinity and to keep a sharp lookout."

Anybody got an old Mosquito Nightfighter radar set I can stick in the nose of my Quik?

Regards
Alan

[flying_john]

I cant find the thread where reporting Mode C was discussed but this product:
http://www.seaerospace.com/surecheck/tpasvrpg.pdf

has a useful graph showing range and signal level received - might be helpfull

It also uses audio output to indicate a "threat"  within a configurable bubble around you.

John

[scsirob]

Hi
EasyVFR currently has voice alerts for traffic and other infringements switchable by the operator, although I'm not sure if this is just in the Beta version I am currently testing prior to a new release.
Maybe not quite ATC standard but enough to get your eyeballs where they need to be.

Alan

The current public version of EasyVFR (3.82.0) has audio warnings but no voice. At least not something you can set. The venerable PocketFMS used to have voice warnings which you could change by swapping out a .WAV file, but I have not been able to find that for EasyVFR yet. Regardless, these were generic warnings, nothing like "Traffic 3 miles 10 o'clock 500ft above".

[scsirob]

A licensing request:

I'd like an option to pay a one-time perpetual license. Even if that would leave me entitled to upgrades for a limited period of time, one year or so.

This because I might make PAW a standard install in my plane. If I ever want to sell the plane, I do not want to tell the new owner that he has to take an annual subscription or lose part of the value of the plane. Or, in a black scenario, Lee decides to call it quits and there's no further licenses available.

Your thoughts?
Rob

[Richard]

        I'm not sure this has been suggested or not, Will a stand alone pilot aware unit with its own GPS transmit its position and provide other PAW units the correct info without it been connected to a Tablet or Phone. In other words if I was a Parasender with no room for an Ipad, I will still be transmitting my position for other users. Same apply's if my Ipad gave up working in flight?

[Admin]

        I'm not sure this has been suggested or not, Will a stand alone pilot aware unit with its own GPS transmit its position and provide other PAW units the correct info without it been connected to a Tablet or Phone. In other words if I was a Parasender with no room for an Ipad, I will still be transmitting my position for other users. Same apply's if my Ipad gave up working in flight?

Yes it will, this was an enhancement quite a while ago for it to act as a beacon.
So as soon as PilotAware is booted, and receiived a GPS lock, it will start transmitting its P3I data.

Are you a Parasender ?
If so, do you have any device, eg for navigation, oudie, naviter, Android/XCsoar ?

Thx
Lee