PilotAware

British Forum => General Discussion => Topic started by: Admin on July 29, 2015, 09:15:28 pm

Title: Enhancement Requests
Post by: Admin on July 29, 2015, 09:15:28 pm
First Posting
Title: Re: Enhancement Requests
Post by: chrismills on August 02, 2015, 11:36:31 pm
Hi Lee.
House move completed. Ready to have a go at writing Android version of app. Have ordered kit of parts which should all be here this week.  Any documentation or tips on where to start, source code etc that I could get started with?
BW Chris Mills
Title: Re: Enhancement Requests
Post by: Shortwing on August 03, 2015, 10:52:29 am
I may be able to assist with an android app - I have some experience.  If you need any assistance chrismills shout
Title: Re: Enhancement Requests
Post by: Admin on August 03, 2015, 01:09:11 pm
Excellent!

Where to start - I have no idea, I have never done any android development  :o
I do have a wealth of experience on Linux, and of course Android is built on Linux.

Let me give a brief overview.

The CollisionAware App does nothing more than connect to a listening posix socket on PilotAware,
then it streams the Location services information through the socket connection.
in essence - thats it!

So I would start by investigating :-
1. How to access location services on Android
2. Socket Comms on Android

I would hope (2) is Linux/Posix compliant, in which case we can just lift the code straight from the
IOS Application.

We could probably take most of this info offline through direct email, but let me start by saying this is
what the code in the IOS callback thread looks like for grabbing the location data.

Quote
gps.f32lat    = (Float32) (currentLocation.coordinate.latitude);
gps.f32lon    = (Float32) (currentLocation.coordinate.longitude);
gps.i32altmtr = (int32_t) (currentLocation.altitude);
gps.course    = (int32_t) (currentLocation.course);
gps.speedms   = (int32_t) (currentLocation.speed);
           
// convert Metres to feet
gps.i32altft  = gps.i32altmtr * METRES_TO_FEET;
gps.speedkns  = gps.speedms * MS_TO_KNOTS;

Hopefully location services data in Android is all in the same format - but may not be the case.

so as you can see from above I grab the data into a structure, and then this is sent over the posix socket,
in another thread with a specific interval period of 1 second

Quote
        //
        // If we are connected to the port
        //
        sprintf(tbuf, "$P3IGGA,%f,%f,%d,%d,%d,%d,%d,%d,*FF\r\n",
                gps.f32lat, gps.f32lon, gps.i32altft,
                gps.course, gps.speedkns, date, time,
                gps.valid);
        if (sendData(gps.sockfd, tbuf, &gps.commsok) <= 0) {
            NSLog(@"sendData Failed self=%@", self);
        }

This is then received by PilotAware and used accordingly.

Is this enough bootstrap info ?
As I mentioned 2 things to investigate, accessing location services, setting up posix thread connections.

Thx
Lee
Title: Re: Enhancement Requests
Post by: grvbc on August 03, 2015, 01:36:21 pm
Really pleased that you guys are on the Android app version - it'll open it up to many more and thereby encourage adoption.

On that note - can PilotAware pick up location info from the RS232 with NMEA already?  I.e. for those of use that want to use the aircraft's already installed GPS.  I guess the question is more a case of - do we have to have a phone/pad for other functionality (such as licencing)?

In my personal case I'd love to use the installed 496 to send NMEA location to PilotAware, and be able to display the traffic alerts graphically on the traffic-capable GPS, rather than need to have a phone/pad in the cockpit too.

All the kit ordered now and on the way.

Thanks
Title: Re: Enhancement Requests
Post by: Admin on August 03, 2015, 02:05:28 pm
Quote
can PilotAware pick up location info from the RS232 with NMEA already?  I.e. for those of use that want to use the aircraft's already installed GPS.  I guess the question is more a case of - do we have to have a phone/pad for other functionality (such as licencing)?
The RPi has only one serial port, and this is occupied by the ARF, however all is not lost.
I have already tested a USB-RS232 interface and had success.
The question is, does the installed GPS generate classic RS232 (ie +/-15v) or RS232-TTL, there is a difference, but both can be handled.

Quote
In my personal case I'd love to use the installed 496 to send NMEA location to PilotAware, and be able to display the traffic alerts graphically on the traffic-capable GPS, rather than need to have a phone/pad in the cockpit too.
This is probably a little more complicated, and I would not have a clue where to begin.
I presume the 496 takes RS232 input as well, so its a case of data formatting.

I have to be honest, seems like a long way off before getting around to that
Title: Re: Enhancement Requests
Post by: Wobblewing on August 03, 2015, 10:50:55 pm
I'm already using a Garmin96C for NMEA data out (RS232 +/-12V format) for the ADS-B ES trial..

A USB<>RS232 adapter thingy could also be wired to this 96C data out to receive NMEA input to the RPi (same data as being sent to my transponder).  http://uk.farnell.com/ftdi/chipi-x10/cable-usb-db9-male-rs232-10cm/dp/2352019

Should be a driver already available for virtual comm port?  then use this stream to send to tablet via flarm intfc?

Cheers
Andy
Title: Re: Enhancement Requests
Post by: Vince on August 03, 2015, 11:13:11 pm

Quote
In my personal case I'd love to use the installed 496 to send NMEA location to PilotAware, and be able to display the traffic alerts graphically on the traffic-capable GPS, rather than need to have a phone/pad in the cockpit too.
This is probably a little more complicated, and I would not have a clue where to begin.
I presume the 496 takes RS232 input as well, so its a case of data formatting.

I have to be honest, seems like a long way off before getting around to that

This should not be a great hurdle as to feed the Garmin with traffic data just requires passing it in the TIS format. I will dig out the spec and post it here.
Title: Re: Enhancement Requests
Post by: chrismills on August 04, 2015, 12:25:40 am
Thanks Lee. I'll do some homework. Might be bit of a slow start. BT are going to take 10 days to switch my broadband on!
Chris
Title: Re: Enhancement Requests
Post by: Admin on August 04, 2015, 01:19:31 pm
Thanks Lee. I'll do some homework. Might be bit of a slow start. BT are going to take 10 days to switch my broadband on!
Chris

Hi Chris,

Had a quick googla around, and I think these are a good starting point

1. Install the Android SDK
https://developer.android.com/sdk/index.html

2. Build your first App
https://developer.android.com/training/basics/firstapp/index.html

3. (the meat) Location Services
http://www.vogella.com/tutorials/AndroidLocationAPI/article.html

Thx
Lee
Title: Re: Enhancement Requests
Post by: Admin on August 04, 2015, 01:26:07 pm
I'm already using a Garmin96C for NMEA data out (RS232 +/-12V format) for the ADS-B ES trial..

A USB<>RS232 adapter thingy could also be wired to this 96C data out to receive NMEA input to the RPi (same data as being sent to my transponder).  http://uk.farnell.com/ftdi/chipi-x10/cable-usb-db9-male-rs232-10cm/dp/2352019

Should be a driver already available for virtual comm port?  then use this stream to send to tablet via flarm intfc?

Cheers
Andy

Hi Andy
Yes already tested a similar device and I got it to work.
I was only really considering NMEA-out (to go to an ADS-B transponder) rather than NMEA-in for the GPS info.

This is going to require a configuration interface.
My initial thoughts were to build this into the IOS/Android Apps.
I am now thinking it is much better to use a web interface (as I am now doing for license key entry)
This makes it independant of IOS & Android, such that the IOS/Android apps now become nothing more than
another GPS source.

In the long run that makes everything cleaner I think, and also solves the requirements of people wanting
to use those Kobo Minis for XCsoar

Thx
Lee
Title: Re: Enhancement Requests
Post by: Vince on August 04, 2015, 08:46:30 pm
I would recommend leaving options open so the configuration can be done via web interface, iOS app or droid app. Start with the website interface but build into it the ability for the apps to read and set the configuration.

Vince
Title: Re: Enhancement Requests
Post by: chrismills on August 05, 2015, 05:45:57 pm
Thanks for the pointers to get me started Lee.

On a slightly different note, I can't help wondering if including an off the shelf GPS module in the unit might be a good option. They are pretty cheap and the ones I've used in other projects in the past simple output standard NMEA sentences over a serial connection. I've parsed the sentences with an arduino nano to get the data I needed so I guess it sould be easy with a Pi.

Chris
Title: Re: Enhancement Requests
Post by: Wobblewing on August 13, 2015, 10:07:26 am
Agree on the web interface for configuration, makes things much cleaner.

Cheers
Andy
Title: Re: Enhancement Requests
Post by: chrismills on August 15, 2015, 09:27:53 pm
Hi Lee,
All parts arrived now and thinking about getting soldering iron out.
Any reason not to use 3.3V supply from Pi on GPIO pin 1, instead of using voltage regulator?

ChrisMills
Title: Re: Enhancement Requests
Post by: Admin on August 15, 2015, 11:17:50 pm
Hi Lee,
All parts arrived now and thinking about getting soldering iron out.
Any reason not to use 3.3V supply from Pi on GPIO pin 1, instead of using voltage regulator?

ChrisMills
Hi Chris

Yes, the 3.3v regulator on the pi provides about 50ma, we need 350ma

Thx
Lee
Title: Re: Enhancement Requests
Post by: chrismills on August 25, 2015, 01:18:18 am
OK Thanks Lee. I'll get this up and running asap. I have a cheap busted (now repaired) iPhone 3 for testing, once I can get it to work without a sim card. I'll keep you posted.
ChrisMills
Title: Re: Enhancement Requests
Post by: onkelmuetze on August 26, 2015, 06:11:28 am
Is anybody out there working on the android-app?
Title: Re: Enhancement Requests
Post by: BobD on August 26, 2015, 08:44:34 am
Is anybody out there working on the android-app?

Hi Seb,

Yes, have a look at this post which was in response to my same question in "Setting up the software" thread".

http://forum.pilotaware.com/index.php/topic,7.msg212.html#msg212

Thanks for your response about the pinouts on the PowerPod.

BobD
Title: Re: Enhancement Requests
Post by: Admin on August 27, 2015, 09:48:12 am
I should also mention that the guys at PocketFMS (EasyVFR) are looking at building the CollisionAware
functionality directly into there navigation tool, basically a broadcast NMEA/GPS that PilotAware will listen

This means
1. you will not need to run CollisionAware
2. It should just run on Android

I will mention this to the other vendors, seems like a good approach

Thx
Lee
Title: Re: Enhancement Requests
Post by: grvbc on September 01, 2015, 04:09:43 pm
Hi Lee

I'm wondering if it would be possible for you to use the --modeac option of dump1090 in combination with the signal strength field to allow PilotAware to show all transponding traffic.  You've probably looked at this already.

Granted, there would not be azimuth or height info for Mode A or C traffic, but it would provide a good warning based on signal strength.  It'd take nothing away from the precision advantages of ADSB-in and P3I for better-equipped traffic, but also warn of all the GA traffic which only have Mode A/C transponders (in the same way  Monrose/Zaon systems work).

Would make it immediately compelling for everyone, not only early adopters...... and not cost anything more.  More traction, more safety for us all.
Title: Re: Enhancement Requests
Post by: tj80 on September 02, 2015, 04:40:50 pm
Mode A/C tracking would, of course, be absolutely fantastic - and, I'm sure, would kick off mass adoption.  Most of this went over my head, but it looks like this is an alternative method of locating Mode A/C signals to the 4-antenna timing method used by the old Xaons?

http://www.radarspotters.eu/forum/index.php?topic=5143.0
Title: Re: Enhancement Requests
Post by: iang on September 04, 2015, 10:51:49 pm
I should also mention that the guys at PocketFMS (EasyVFR) are looking at building the CollisionAware
functionality directly into there navigation tool, basically a broadcast NMEA/GPS that PilotAware will listen

This means
1. you will not need to run CollisionAware
2. It should just run on Android

I will mention this to the other vendors, seems like a good approach

Thx
Lee
How are you going with the folks at Sky demon? I intend to use this on my hudl2
Title: Re: Enhancement Requests
Post by: Admin on September 06, 2015, 06:47:07 am
Unfortunately I was unable to convince SkyDemon to output the GPS sharing
Not a problem, simply means an additional app must share the GPS from the host
Or alternately that PilotAware integrates a GPS into the hardware, which was the
suggested route from SkyDemon, again also a viable possibility
Thx
Lee
Title: Re: Enhancement Requests
Post by: Kevin W on September 06, 2015, 12:23:43 pm
For me, 3 things are on my like to have and practical list:
A 4th as a 'nice to have'


Then last of all, something any of us can do, put it all into a single box with the dongles self contained.

Cheers
Kev
Title: Re: Enhancement Requests
Post by: REDX on September 06, 2015, 09:05:47 pm
Hi

Perhaps to add GPS, Baro Pressure, Inertials, Compass, etc.

This looks like an interesting posibility, perhaps worth a look for future enhancements.
http://www.ebay.co.uk/itm/181566850426?_trksid=p2055119.m1438.l2648&ssPageName=STRK%3AMEBIDX%3AIT (http://www.ebay.co.uk/itm/181566850426?_trksid=p2055119.m1438.l2648&ssPageName=STRK%3AMEBIDX%3AIT)


Glenn
Title: Re: Enhancement Requests
Post by: onkelmuetze on September 07, 2015, 07:16:44 am
I totally agree with "grvbc" and "tj80" - Mode A/C tracking is the most important feature to gain!
Title: Re: Enhancement Requests
Post by: Kevin W on September 07, 2015, 03:17:47 pm
I totally agree with "grvbc" and "tj80" - Mode A/C tracking is the most important feature to gain!

Unfortunately, Mode A C transmissions contain no positioning data, so PilotAware has nothing to display. 

Zaon tried to do guess work from 4 aerials, which resulted in a very expensive device and they went out of business.

The only alternative I can think of as a remote possibility is cellular data and hooking up to one of the FlightRadar type networks.  FlightRadar works because the 4 aerials can be 10's of miles apart, and so they have an easier calculation to do - but I haven't seen any data on how accurate their mlat actually is? (and that's ignoring other issues like cellular data coverage in the air, network delays, etc).

Cheers
Kev

Title: Re: Enhancement Requests
Post by: trapdoor on September 08, 2015, 11:15:20 am
What would be handy, would be a serial port 'loopback' test.

I have either a dud ARF module or one of the Pi B+'s with a faulty serial port as my ARF fails to initialise. At the moment, don't know which but I suspect the ARF.

It may be handy to test if the Rx & Tx pins are shorted before setting up the ARF and if they are, pop up a message saying something like 'Serial Port test OK - Loopback or shorted data pins'. If it was deliberately shorted or looped back, then that confirms the Tx & Rx on the UART is working OK. If it's shorted and doesn't pop up the message, dud RPi. If the ARF is plugged in and working, then it just gives the ARF config messages. At the moment it's tricky to see where the issue is.

The instructions to test a Pi serial port are a bit convoluted, especially for someone who doesn't have a copy of the vanilla OS, requiring setting the console port off and installing and running something like Minicom.
Title: Re: Enhancement Requests
Post by: Kevin W on September 08, 2015, 11:56:44 am
What would be handy, would be a serial port 'loopback' test.

I have either a dud ARF module or one of the Pi B+'s with a faulty serial port as my ARF fails to initialise. At the moment, don't know which but I suspect the ARF.

It may be handy to test if the Rx & Tx pins are shorted before setting up the ARF and if they are, pop up a message saying something like 'Serial Port test OK - Loopback or shorted data pins'. If it was deliberately shorted or looped back, then that confirms the Tx & Rx on the UART is working OK. If it's shorted and doesn't pop up the message, dud RPi. If the ARF is plugged in and working, then it just gives the ARF config messages. At the moment it's tricky to see where the issue is.

The instructions to test a Pi serial port are a bit convoluted, especially for someone who doesn't have a copy of the vanilla OS, requiring setting the console port off and installing and running something like Minicom.

Hi Trapdoor

You could always connect a 'scope if you have one, or an RS232 to USB converter to the RS232 pins and watch for Lee sending out the initial instruction to the ARF?

http://www.ebay.co.uk/itm/USB-TO-RS232-TTL-PL2303-CONVERTER-FOR-RASPBERRY-Pi-ADAPTER-CONSOLE-CABLE-/121070687261?hash=item1c3060141d

Cheers
Kev
Title: Re: Enhancement Requests
Post by: trapdoor on September 08, 2015, 12:21:05 pm
Hi Kev,

S'OK. It was a faulty Pi - just verified the ARF by talking to it with my Mac and a USB-Serial podule I had dug out. Gonna drop into RS later to pick up a new one and this one goes back to Amazon. The Pi is not actually sending anything out of the Tx pin as far as I can tell.

A basic loopback test may be useful though for someone building one with no test gear. I do have a scope (a Hameg DSO) and a sig gen but  not here and I was getting somewhat frustrated  ::)
Title: Re: Enhancement Requests
Post by: Admin on September 08, 2015, 12:29:54 pm
Hi All

Just seen these last couple of comments.
You should have had one of the following messages

either
    ARF-RS232: Programming End

or
    ARF-RS232: Communication Failure

Did you not get either of these messages on the console (assuming you connected an HDMI display) ?

Thx
Lee
Title: Re: Enhancement Requests
Post by: trapdoor on September 08, 2015, 01:16:50 pm
Yes, ARF Communication Failure, and no programming messages.

It's the Pi that's screwed. Research reveals that there are some with dud serial ports. It came from Amazon as I couldn't get to RS last week but I now have a replacement - when I get 10 mins I'll boot it up and see if that one is any better!!
Title: Re: Enhancement Requests
Post by: trapdoor on September 08, 2015, 02:04:30 pm
Now all working perfectly!

And running happily off a charge pak
Title: Re: Enhancement Requests
Post by: ianfallon on September 08, 2015, 02:52:59 pm
Now all working perfectly!

And running happily off a charge pak

Neat! That's using the Slice of Pod ? Could you post a pic of the other side of the SOP board ? Would be interested to see.
Title: Re: Enhancement Requests
Post by: trapdoor on September 08, 2015, 03:15:36 pm
I'll do it later - I'm just timing how long my ChargePak holds up to run the thing. Looking good so far.

The slice is nice  ;D but it needs a bit of modding to fit the case, but it gives a nice bit of support and structure and makes soldering up a doddle. I'm surprised no one else has used the thing.
Title: Re: Enhancement Requests
Post by: Admin on September 08, 2015, 03:33:28 pm
Hi Trapdoor,
Cool

Can you write down an inventory and supplier list for the Antenna and MCX/SMA converter
does the antenna for the SDR dongle stay fixed ?
I thought that adding an MCX/SMA converter would make it a bit loose

Thx
Lee
Title: Re: Enhancement Requests
Post by: ianfallon on September 08, 2015, 03:35:04 pm
I'll do it later - I'm just timing how long my ChargePak holds up to run the thing. Looking good so far.

The slice is nice  ;D but it needs a bit of modding to fit the case, but it gives a nice bit of support and structure and makes soldering up a doddle. I'm surprised no one else has used the thing.

Thanks - that would be appreciated. What modding was required ? I've ordered one as well as the Pod so will decide which way to go when I get all the bits. I will probably end up building at least one more so no probs having some spares :-)
Title: Re: Enhancement Requests
Post by: Admin on September 08, 2015, 03:36:04 pm
I'll do it later - I'm just timing how long my ChargePak holds up to run the thing. Looking good so far.

The slice is nice  ;D but it needs a bit of modding to fit the case, but it gives a nice bit of support and structure and makes soldering up a doddle. I'm surprised no one else has used the thing.

To get a good figure for the battery usage, you need to ensure the ARF is transmitting,
so have you run up CollisionAware and connected your NAV tool ?
If not then the transmitter will not be pulsing, so may give a false reading regarding
the battery run time

Thx
Lee
Title: Re: Enhancement Requests
Post by: trapdoor on September 08, 2015, 03:53:27 pm
Yep - it's sitting there, connected to SD and my BadElf Pro+ (via the iPad obviously) and happily pinging away as I'm receiving it on my Communication Rx on 869.4Mhz.
Title: Re: Enhancement Requests
Post by: rg on September 08, 2015, 04:53:27 pm
Hi Trapdoor.  What antenna's have you fitted to your box?
Title: Re: Enhancement Requests
Post by: trapdoor on September 08, 2015, 05:43:50 pm
Hi Trapdoor.  What antenna's have you fitted to your box?

An 868 - 870Mhz ISM antenna on the ARF and a decent quality RA GSM900 antenna with an MCX to SMA converter. It's performing surprisingly well BUT I am intending to de-case the DVB-T Rx and mount it inside and I've an MCX to SMA pigtail to take the antenna to the end of the case. Job for the weekend tho.

Problem with something like the DVB-T mounted mechanically off the USB socket (and the antenna off that) is that with the sort of vibration present in Lyco and Conti engined spam cans (like my Pup) it may become unreliable. I am thinking of removing one stack of the USB's and just installing a set of headers ILO and hard-wiring the DVB-T module. There is still some room in my case to do this and the prototyping board will give some mechanical support to the module.
Title: Re: Enhancement Requests
Post by: trapdoor on September 08, 2015, 07:19:07 pm
Hi Trapdoor,
Cool

Can you write down an inventory and supplier list for the Antenna and MCX/SMA converter
does the antenna for the SDR dongle stay fixed ?
I thought that adding an MCX/SMA converter would make it a bit loose

Thx
Lee

Hi Lee,

I'll draw up a list tomorrow. It's from all over.

The MCX to SMA IS loose but it's going to (hopefully) be a temporary solution for me, as I plan to relocate the dongle inside.

The option is to actually solder the converter to the MCX socket on the dongle. With a 25w iron it should be possible if VERY careful. Other option is a blob of silicone just to stop it rotating.

As it stands, I'm planning on a blob of silicone on the pigtail for the ARF as that isn't terribly tight either - people will need to make sure their construction is robust enough and bits are damped to take into account some of the serious vibrations in GA aircraft. This is one reason I have used the prototyping pod to mount the ARF to ... which someone asked for a photo, here it is:

Title: Re: Enhancement Requests
Post by: trapdoor on September 08, 2015, 07:24:45 pm
What modding was required ?

You need to desolder the two 'pod' headers as the lid for the Tontec case won't fit with these in place. You don't need em. If you cannot be bothered to desolder, then just wiggle side to side a few times and the pins break at the PCB plane and the header will fall off. I couldn't be arsed to desolder as the tip on my pump is worse for wear but if I was making for someone I'd do it properly.

Because of the prototyping pads, I elected to insulate the ARF but it's mounted on a strong double sided sticky foam tape.

HTH.
Title: Re: Enhancement Requests
Post by: ianfallon on September 08, 2015, 07:31:30 pm
What modding was required ?

You need to desolder the two 'pod' headers as the lid for the Tontec case won't fit with these in place. You don't need em. If you cannot be bothered to desolder, then just wiggle side to side a few times and the pins break at the PCB plane and the header will fall off. I couldn't be arsed to desolder as the tip on my pump is worse for wear but if I was making for someone I'd do it properly.

Because of the prototyping pads, I elected to insulate the ARF but it's mounted on a strong double sided sticky foam tape.

HTH.

Cool - thanks for that and the photo.  :)
Title: Re: Enhancement Requests
Post by: Kevin W on September 09, 2015, 07:21:36 pm
Hi

Having just built and tested my second unit - I realise that having the ICAO set at a default of 000000, and the code filtering out duplicate ICAO codes is probably a bad thing - by default the unit filters out another unit set at 000000 :)

Once I twigged and set it to the MAC address as a random number, all was good!  Maybe don't filter out 000000?

Cheers
Kev
Title: Re: Enhancement Requests
Post by: Admin on September 09, 2015, 07:44:08 pm
Hi
Having just built and tested my second unit - I realise that having the ICAO set at a default of 000000, and the code filtering out duplicate ICAO codes is probably a bad thing - by default the unit filters out another unit set at 000000 :)
Once I twigged and set it to the MAC address as a random number, all was good!  Maybe don't filter out 000000?
Cheers
Kev

Hi Kev
This is actually a bug.
Firstly i am deleting these feature from collisionaware and it is moving into the web interface
If the ICAO is 000000 it is supposed to use the mac address of the dongle, in fact I think I may simply make it an XOR of the upper 6 and lower 6 bytes to create the 6 byte code.
There is a special field in the packet to indicate it is autogenerated

That should fix your issue, hoping to get a release out in next couple of days with other enhancements as well, details to follow

Thx
Lee
Title: Slight bug-ette in CollisionAware app on iPhone?
Post by: trapdoor on September 09, 2015, 08:17:07 pm
Just tried to run the CollisionAware app on the iPhone and change the ICAO code and realised that there is no way to get shot of the soft keyboard or scroll down to click on update.

Is this known about or a work-around?
Title: Re: Slight bug-ette in CollisionAware app on iPhone?
Post by: Admin on September 09, 2015, 08:57:52 pm
Just tried to run the CollisionAware app on the iPhone and change the ICAO code and realised that there is no way to get shot of the soft keyboard or scroll down to click on update.

Is this known about or a work-around?

Oh that is a pain.
I use an iphone 6 plus, I presume you are on a smaller screen.

I mentioned on another thread I am close to releasing a new version which uses the web interface to do this instead of the ios app, are you up for trying some prerelease software to get around this ?

Thlre
Title: Re: Enhancement Requests
Post by: stephenmelody on September 11, 2015, 09:34:26 pm
I'm always up for pre-release / beta software...

Title: GPS Dongle
Post by: SteveN on September 11, 2015, 11:39:20 pm
Any more thoughts about a GPS dongle instead of relying on the Tablet's GPS.

GPSD (GPS Daemon) runs the GPS on millions of Androids out there.

http://catb.org/gpsd/ (http://catb.org/gpsd/)

It builds fine on a Pi as I have tried it on Raspian by simply following this script:

http://blog.retep.org/2012/06/18/getting-gps-to-work-on-a-raspberry-pi (http://blog.retep.org/2012/06/18/getting-gps-to-work-on-a-raspberry-pi)

Negligible CPU overhead on a Pi B+. Its beauty is it handles most dongles automatically.

PilotAware would then still report position even if a tablet was not in the aircraft.

Steve
Title: Re: Enhancement Requests
Post by: stephenmelody on September 12, 2015, 12:55:44 am
Considered doing anything with a screen? this is pretty affordable as a component...

http://thepihut.com/collections/new-products/products/official-raspberry-pi-7-touchscreen-display

considering one, just to see the console output as the device connects.
Title: Re: Enhancement Requests
Post by: Admin on September 12, 2015, 10:04:11 am
Gps is work in progress.
Parser is done, just need to put something into the OS to statically
identify the USB ports, all RS232 devices appear the same so need
a method to indicate the type of device

Thx
Lee
Title: Re: Enhancement Requests
Post by: bendavis on September 13, 2015, 08:30:49 am
A couple of thoughts spring to mind now I've got the device up and running, sorry if someone else has already mentioned these, I couldn't see anything about the data side of things....

1.  is poss to integrate a USB GPS dongle saving the wifi connection to the device? and if not..
2.  could it connect to the device over Bluetooth instead ?

Reason for asking is my iPad has a data sim installed and as I fly along it updates SkyDemon's data, weather, metars etc,(handy on those long flights) but obviously once the iPad is connected to a wifi network all data from the sim stops as it assumes it has internet access from wifi.

I'm not clever enough to come up with the solutions... just asking the questions  ;)

Ben
Title: Re: Enhancement Requests
Post by: onkelmuetze on September 14, 2015, 06:09:39 am
Considered doing anything with a screen? this is pretty affordable as a component...

http://thepihut.com/collections/new-products/products/official-raspberry-pi-7-touchscreen-display

considering one, just to see the console output as the device connects.

Might be a cool idea for a standalone box, w/o tablet. Just to draw your plane in center and then 1 mile-circles around it to display other aircrafts positions in.
Title: Re: Enhancement Requests
Post by: Admin on September 16, 2015, 05:10:43 pm
Might be a cool idea for a standalone box, w/o tablet. Just to draw your plane in center and then 1 mile-circles around it to display other aircrafts positions in.

so funny, here is version 1 of PilotAware from two years ago running on a WindowsCE device
Title: Re: Enhancement Requests
Post by: Admin on September 16, 2015, 05:14:04 pm
Hi Ben,
Quote
1.  is poss to integrate a USB GPS dongle saving the wifi connection to the device? and if not..
Yes and this is working with a glonass/gps Ublox 7 gps

Quote
2.  could it connect to the device over Bluetooth instead ?
No, the RPi does not have bluetooth

Quote
Reason for asking is my iPad has a data sim installed and as I fly along it updates SkyDemon's data, weather, metars etc,(handy on those long flights) but obviously once the iPad is connected to a wifi network all data from the sim stops as it assumes it has internet access from wifi.
This broke because of the requirement to support TCP broadcasts, I think I am going to get rid of this and switch back to TCP and UDP point to point. This should allow using the 3G network when connected to PilotAware

Thx
Lee
Title: Re: Enhancement Requests
Post by: onkelmuetze on September 17, 2015, 07:21:03 am
Might be a cool idea for a standalone box, w/o tablet. Just to draw your plane in center and then 1 mile-circles around it to display other aircrafts positions in.

so funny, here is version 1 of PilotAware from two years ago running on a WindowsCE device

haha, cool! It would be perfect like it is on your picture, displaying on one of those 2,5...3,5" Pi-Displays available for less than 30€! Question is, if the display uses the I/Os we need for the ARF?
Title: Re: Enhancement Requests
Post by: Admin on September 19, 2015, 11:38:34 am
I have added lots of extra information into the web browser so that people will be able to feedback detailed information on their configuration, please see snapshot below, I hope to get this released over the weekend
Thx
Lee
Title: Re: Enhancement Requests
Post by: brinzlee on September 27, 2015, 10:44:28 pm
Lee
Think the latest release is a marked improvement yet again on reliability with the addition of the rewritten collision aware app too
Wondered if you would consider writing on the web interface the output from the barometric sensor if included, as a value, just so that we can confirm the QNH is something that it's supposed to be.
Keep up the great work
Brinsley
Title: Re: Enhancement Requests
Post by: Admin on September 28, 2015, 10:48:21 am
How about this ....
Title: Re: Enhancement Requests
Post by: brinzlee on September 28, 2015, 11:12:00 am
Thats great Lee.......At least it gives us some idea of whats going on for accuracy... ;D ;D
Title: Re: Enhancement Requests
Post by: brinzlee on September 28, 2015, 11:34:43 am
Just another thought.....If there was a known error from the sensor to a referenced QNH.....then maybe a way of entering in an offset.....I'm not sure how accurate the little beasts are !!
Title: Re: Enhancement Requests
Post by: Admin on September 28, 2015, 11:52:27 am
Just another thought.....If there was a known error from the sensor to a referenced QNH.....then maybe a way of entering in an offset.....I'm not sure how accurate the little beasts are !!

they are VERY accurate, as you can see from the report in my posting.
the reported QNH (I calculate by comparing GPS Alt versus Pressure Alt) is 1038, XC weather is reporting 1037
Title: Re: Enhancement Requests
Post by: dougblair on October 05, 2015, 03:26:14 pm
Hi Lee,
apologies if this is elsewhere !   I have just put a Open Glider Network Receiver together as I live high ish up on the eastern edge of Snowdonia.
Can or in the future could the two systems see each other ? Not sure how Flarm with encoding might fit into this. Your system would greatly enhance OGN by being able to see gliders in cockpit.
Doug
Title: Re: Enhancement Requests
Post by: Admin on October 05, 2015, 03:57:42 pm
Hi Lee,
apologies if this is elsewhere !   I have just put a Open Glider Network Receiver together as I live high ish up on the eastern edge of Snowdonia.
Can or in the future could the two systems see each other ? Not sure how Flarm with encoding might fit into this. Your system would greatly enhance OGN by being able to see gliders in cockpit.
Doug

Hi Doug,
I am in contact with the OGN developers, but there is nothing to report more than we are in communication.
I agree it would be great to have the systems able to see each other
Thx
Title: Re: Enhancement Requests
Post by: flyingalan on October 07, 2015, 02:01:05 pm
Hi, just got my system fired up and working, very happy thanks.
As a future software enhancement would it be possible to receive non ads-b transponders and display a coloured ring around my aircraft whose diameter is proportional to received signal strength.
Whilst this does not given any actual position information it does alert pilot that another aircraft is somewhere close, the smaller the ring the closer it is !!!
This is implemented on "PowerFlarm" interface to SkyDemon and I find it very useful, it really make me look out with great attention when I get a ring around my current position. Not as good as ADS-B position I agree but better than no alert at all.
Great work from you, thanks,
regards
Alan
p.s. you might want to put in construction document the SkyDemon Flarm code 6000, it took me a while to find why my box wouldn't connect. Also in SkyDemon, there is an altitude window for traffic alerts in "set up" - "navigation options" that took me a while to find. Might be worth mentioning in build document.  :)
Title: Re: Enhancement Requests
Post by: Admin on October 07, 2015, 02:23:15 pm
Hi Alan,

Quote
Hi, just got my system fired up and working, very happy thanks.
As a future software enhancement would it be possible to receive non ads-b transponders and display a coloured ring around my aircraft whose diameter is proportional to received signal strength.
Whilst this does not given any actual position information it does alert pilot that another aircraft is somewhere close, the smaller the ring the closer it is !!!
This is implemented on "PowerFlarm" interface to SkyDemon and I find it very useful, it really make me look out with great attention when I get a ring around my current position. Not as good as ADS-B position I agree but better than no alert at all.

The problem here is equating strength to distance  ::)
There was a post by Andy Fell an RF engineer who comments about the massive innacuracy in this approach,
but I could certainly try this, not sure of the value right now.

Quote
Great work from you, thanks,
regards
Alan
p.s. you might want to put in construction document the SkyDemon Flarm code 6000, it took me a while to find why my box wouldn't connect. Also in SkyDemon, there is an altitude window for traffic alerts in "set up" - "navigation options" that took me a while to find. Might be worth mentioning in build document.  :)

this information has been pushed down a list, but was documented here ....
http://forum.pilotaware.com/index.php/topic,13.msg16.html#msg16
Title: Re: Enhancement Requests
Post by: flyingalan on October 09, 2015, 12:38:02 am
Hi Lee, thanks for reply, yes it is correct that it is almost impossible to get any accurate real distance measurement from the received strength, however the issue is that it alerts you that someone is close with a transponder going in the absence of ADS-B information, and at present there are many more non ADS-B transponders than active ones on GA aircraft.
It makes you look out twice as hard when you see that (in my case) green ring !
It doesn't need to respond to small signals that are far away, as far as I can see (I'm guessing) it seems a trigger level is set that makes the ring appear and it then gets smaller around my aircraft symbol the stronger the signal. It really gets your attention when you see a ring getting smaller around you, i.e. closer !
Probably requires some experimentation to get the scaling sensible but I have found it a helpful display. Happy to be of any help I can if you decide to pursue this idea.
regards
Alan
Title: Re: Enhancement Requests
Post by: onkelmuetze on October 09, 2015, 07:23:49 am
As the strength of the received signal may vary with placement/quality/... of you're antennas, etc, it might be a good idea to implement a user setting "gain" of the Mode-C signals. So everybody could adjust the range for Mode-C-listening, or set it to "0" to fully discard Mode-C-signals.
Title: Re: Enhancement Requests
Post by: N6010Y on October 09, 2015, 10:05:08 am
I raised this in an earlier post - I would definitely support a Mode C function.
Title: Re: Enhancement Requests
Post by: rg on October 09, 2015, 12:00:20 pm
would this use an existing antenna or mean a 3rd?
Title: Re: Enhancement Requests
Post by: scsirob on October 09, 2015, 12:57:04 pm
This one is in the 'dream out loud' category..

If you add support for a temperature/humidity sensor (such as the HTU21D https://cdn.sparkfun.com/assets/6/a/8/e/f/525778d4757b7f50398b4567.pdf ) then you have all information available to calculate density altitude. This will allow you to calculate relative engine performance.

Applications such as EasyVFR and SkyDemon already have plane performance information built in. They also know where you are and the airfield/runway you are taxiing to. If you taxi to a short runway, how cool would it be to get a big warning that the performance isn't enough to perform a safe take-off from that runway??

This would probably take some programming in PAW (support for sensor, and a new P3I message), and then support from EasyVFR and the likes.

Title: Re: Enhancement Requests
Post by: Admin on October 09, 2015, 01:13:54 pm
I have a very cunning plan for mode C, specifically to mitigate the receiver sensitivity vs distance innacuracies
I shall attempt some experiments next week

Thx
Lee
Title: Re: Enhancement Requests
Post by: scsirob on October 09, 2015, 01:28:31 pm
I have a very cunning plan for mode C, specifically to mitigate the receiver sensitivity vs distance innacuracies
I shall attempt some experiments next week

Thx
Lee

Let me guess.. If you have multiple PAW users in an area and they could share eachother's data, you could use some kind of triangulation??
Title: Re: Enhancement Requests
Post by: N6010Y on October 09, 2015, 07:27:02 pm
Not just a cunning plan - but a 'very' cunning plan !  Very interesting Lee.....
Title: Re: Enhancement Requests
Post by: Ian Melville on October 10, 2015, 09:01:48 am
As cunning as a fox who's just been appointed Professor of Cunning at Oxford University?

Trouble is there may not be enough aircraft in range at any one time. Now if there was an network of ground stations :-)
Title: Re: Enhancement Requests
Post by: Richard W on October 10, 2015, 04:24:42 pm
Lee, would it be possible to configure the ARF TX and RX messages separately, for logging, pretty please?  This is for ground tests where people have been persuaded to fly overhead, and logging RX only would stop the TX messages scrolling the interesting stuff off the screen.

Thanks,
Richard
Title: Re: Enhancement Requests
Post by: flyingalan on October 11, 2015, 01:53:53 pm
Lee, thanks, I look forward to learning more about your "cunning Plan" !!

On a separate subject, I would also support the establishing of PA ground stations and would certainly be happy to host one if no progress is made with OGN. I would think with the relative hi power O/P of the PA transmitter, it would have a pretty good range to a ground station giving good coverage if the ground receiver antenna is in a clear location.
Unfortunately I have no knowledge of servers and programming so cannot provide any direct help in implementation but I'm sure amongst this group we must have some that are knowledgeable in this area

I don't believe PA will have any significant take up in the gliding community, Flarm is too well established, however in the GA community I think you have a winner. The extremely low cost of build, open protocol and small size all seem very attractive to implement as an anti collision system. Even as ADS-B takes hold in GA, to just have your low cost device as a receiver only displaying other traffic including ADS-B on an iPad is magic.

I also found recently another use; in implementing ADS-B on an existing aircraft installation, it is hard to do an initial test to prove operation and do a check on its performance. I used your device just as a receiver with my iPad and could verify the presence ADS-B transmission on the ground after modification. Then by carrying it in the air on the same aircraft, I could see that the ADS-B GPS position being given corresponded with the actual position of the aircraft as shown on the moving map. A great piece of test equipment !  :)
regards
Alan
Title: Re: Enhancement Requests
Post by: scsirob on October 11, 2015, 09:23:39 pm
Before planning an entire network, please note that the ISM frequency band that PAW uses, is shared with other non-licensed users  :o . There is no guarantee that transmissions are uninterrupted and you may actually cause interference with others.
Title: Re: Enhancement Requests
Post by: SMW on October 11, 2015, 09:43:42 pm
Lee
can you add

BMP180 I2C Digital Barometric Pressure Sensor
http://www.raspberrypi-spy.co.uk/2015/04/bmp180-i2c-digital-barometric-pressure-sensor/

assuming i have no way off applying
http://www.raspberrypi-spy.co.uk/2014/11/enabling-the-i2c-interface-on-the-raspberry-pi/

as i can't login.

I have a 180 installed, but PA says manual mode.

Thanks
Stephen
Title: Re: Enhancement Requests
Post by: GarethHorne on October 12, 2015, 09:20:48 pm
Are there any plans to add WEP, WPA, or WPA2 to the WiFi hotspot? The PilotAware box creates a good, strong hotspot and at a busy airfield I'd rather know I'm the only one connecting to my own unit, rather than someone else perhaps inadvertently connecting (thinking its their device) and making changes via the web config page.
Title: Re: Enhancement Requests
Post by: flyingalan on October 13, 2015, 10:08:54 am
Before planning an entire network, please note that the ISM frequency band that PAW uses, is shared with other non-licensed users  :o . There is no guarantee that transmissions are uninterrupted and you may actually cause interference with others.

Ground receivers would not transmit anything so could not cause interference to anyone else. However you are correct that any ground station could receive interference.
regards
Title: Re: Enhancement Requests
Post by: scsirob on October 16, 2015, 08:35:02 am
I have a feature/enhancement request. I just received my uBlox NEO M8N GPS receiver. It sends traditional USA GPS coordinates using "$GPxxx" NMEA strings. However, it also receives GLONASS signals. This information is sent as "$GNxxx" strings. This currently gets logged as unsupported messages.

Would it be possible to treat "$GN" equal to "$GP" please?
Title: Re: Enhancement Requests
Post by: Admin on October 16, 2015, 10:01:00 am
I have a feature/enhancement request. I just received my uBlox NEO M8N GPS receiver. It sends traditional USA GPS coordinates using "$GPxxx" NMEA strings. However, it also receives GLONASS signals. This information is sent as "$GNxxx" strings. This currently gets logged as unsupported messages.

Would it be possible to treat "$GN" equal to "$GP" please?

Hi Rob,
Actually I have already fixed this, but not in the released product.
I should get a new release out over the weekend which will support these messages.

Do you have a complete list, and I will cross reference to be absolutely sure, I now handle the following

Code: [Select]
GPGGA
GPGLL
GPGSA GLGSA GNGSA
GPGSV GLGSV
GPVTG GNVTG
GPRMC GNMRC
GPZDA
GPTXT (discarded)

Thx
Lee
Title: Re: Enhancement Requests
Post by: scsirob on October 16, 2015, 11:38:46 am
Hi Lee,

The GNxxx messages you have are all that's been sent. I have sent you a trace from my uBlox.

Thanks!
Rob
Title: Re: Enhancement Requests
Post by: Paul_Sengupta on October 18, 2015, 01:51:35 am
Might be a cool idea for a standalone box, w/o tablet. Just to draw your plane in center and then 1 mile-circles around it to display other aircrafts positions in.

so funny, here is version 1 of PilotAware from two years ago running on a WindowsCE device

Would it be at all possible to draw something like this on the display output on the PI?
Title: Re: Enhancement Requests
Post by: Admin on October 19, 2015, 01:24:50 pm
Might be a cool idea for a standalone box, w/o tablet. Just to draw your plane in center and then 1 mile-circles around it to display other aircrafts positions in.

so funny, here is version 1 of PilotAware from two years ago running on a WindowsCE device

Would it be at all possible to draw something like this on the display output on the PI?

this is probably something which could be developed in isolation of PAW and easily integrated - volunteers ?
Title: Re: Enhancement Requests
Post by: Ian Melville on October 19, 2015, 03:56:49 pm
I think the idea was to use the PIlotAware Pi with an LCD display, rather than having 2 Pi or other devices. I think that would need your input Lee?

No squared jokes please

Title: Re: Enhancement Requests
Post by: scsirob on October 19, 2015, 06:07:48 pm
Hi  Lee,

I'm still testing on the ground. Currently, the HDMI output blanks after a few minutes, so I can't see logging to the attached screen anymore. Only way to get the screen back is to hit a key on the keyboard *if* one is attached. I usually don't. Would you please disable the screen timeout so it keeps displaying data?

Thanks!
Rob
Title: Re: Enhancement Requests
Post by: Admin on October 19, 2015, 06:22:30 pm
Hi  Lee,

I'm still testing on the ground. Currently, the HDMI output blanks after a few minutes, so I can't see logging to the attached screen anymore. Only way to get the screen back is to hit a key on the keyboard *if* one is attached. I usually don't. Would you please disable the screen timeout so it keeps displaying data?

Thanks!
Rob

I have no idea how to do that, do you know a way ?
Also, you know you can get the log output through the web interface ?
Thlee
Title: Re: Enhancement Requests
Post by: JCurtis on October 19, 2015, 07:20:41 pm
Hi  Lee,

I'm still testing on the ground. Currently, the HDMI output blanks after a few minutes, so I can't see logging to the attached screen anymore. Only way to get the screen back is to hit a key on the keyboard *if* one is attached. I usually don't. Would you please disable the screen timeout so it keeps displaying data?

Thanks!
Rob

I have no idea how to do that, do you know a way ?
Also, you know you can get the log output through the web interface ?
Thlee

From my "handy commands" text file of all sorts of odd things you can try....

Code: [Select]
Edit /etc/kbd/config
sudo pico /etc/kbd/config

Change the settings;

BLANK_TIME to 0
POWERDOWN_TIME to 0

As you don't use X that should stop the screen blanking.  Or it did at the time when I put it onto my tips file, be a while ago now though.
Title: Re: Enhancement Requests
Post by: scsirob on October 19, 2015, 07:24:24 pm
Hi  Lee,

I'm still testing on the ground. Currently, the HDMI output blanks after a few minutes, so I can't see logging to the attached screen anymore. Only way to get the screen back is to hit a key on the keyboard *if* one is attached. I usually don't. Would you please disable the screen timeout so it keeps displaying data?

Thanks!
Rob

I have no idea how to do that, do you know a way ?
Also, you know you can get the log output through the web interface ?
Thlee

I think if you add "setterm -blank 0" in your startup shell script, the screen should stay alive. As you use runlevel 2 by default, somewhere in the rc2.d scripts directory would probably be good. Assumption is that setterm is present (or part of busybox)

The web log output is too slow over WiFi to catch up.

Thanks!
Rob
Title: Re: Enhancement Requests
Post by: scsirob on October 26, 2015, 07:33:27 pm
Lee, if you have nothing better to do, would you consider making the WiFi and eth0 IP addresses configurable? The current default clash with my home network.
Title: Re: Enhancement Requests
Post by: onkelmuetze on October 30, 2015, 06:01:12 am
As this forum becomes bigger and bigger, I start to loose my overview of what is going on on the development side.  ::)

I suggest a fixed thread "captain's logbook", containing open points on your list, stuff in progress, and solved/implemented points and/or issues.

Only Lee should be allowed to post to keep it from drifting off topic.
Title: Re: Enhancement Requests
Post by: Admin on October 30, 2015, 03:56:19 pm
As this forum becomes bigger and bigger, I start to loose my overview of what is going on on the development side.  ::)

I suggest a fixed thread "captain's logbook", containing open points on your list, stuff in progress, and solved/implemented points and/or issues.

Only Lee should be allowed to post to keep it from drifting off topic.

its a good point, I need to have a sweep of the enhancement requests and put out to a poll.
I have a lot of this info in my logbook, just not publicly available.
At the moment we are concentrating on the P3I Transceiver work.

Thx
Lee
Title: Multiple Navigation Clients
Post by: Admin on October 31, 2015, 04:40:58 pm
Hi All

There was a request quite a while back to support multiple Navigation clients, ie connect more than one copy of SkyDemon/RunwayHD etc to PilotAware.
I now have this working and this will be included in the next release

Thx
Lee
Title: Re: Multiple Navigation Clients
Post by: T67M on October 31, 2015, 09:12:45 pm
There was a request quite a while back to support multiple Navigation clients, ie connect more than one copy of SkyDemon/RunwayHD etc to PilotAware.
I now have this working and this will be included in the next release

Thanks Lee - much appreciated.
Title: Re: Enhancement Requests
Post by: Ian Melville on November 01, 2015, 07:41:33 am
Hi Lee,
If you PIlotAware does not have a GPS, do you have to set a master device for it to receive the GPS signal from? Or is this only for PIlotAware units that have an internal or USB GPS?
Title: Re: Enhancement Requests
Post by: Admin on November 02, 2015, 09:17:59 am
Hi Lee,
If you PIlotAware does not have a GPS, do you have to set a master device for it to receive the GPS signal from? Or is this only for PIlotAware units that have an internal or USB GPS?

Hi Ian,
It will be the first to connect.
PAW will run a single listenening socket, so further connections will be ignored
Thx
Lee
Title: Re: Enhancement Requests
Post by: Ian Melville on November 02, 2015, 12:31:36 pm
Thanks Lee, Still waiting for the GPS :'(
Title: Re: Enhancement Requests
Post by: r_w_walker on November 02, 2015, 02:27:35 pm
I was lucky with my iphone got system working great BUT would prefer a stand alone system.

Iphone screen too small, iPad device too old to run SkyDemon or Runway HD. Both dependent on subscriptions to third parties.

So many combinations of display possibilities but many posts of problems with third party devices.

Is version 1 available seems to be just what I want. I have a windows CE device.

Might be a cool idea for a standalone box, w/o tablet. Just to draw your plane in center and then 1 mile-circles around it to display other aircrafts positions in.

so funny, here is version 1 of PilotAware from two years ago running on a WindowsCE device

There are still some pilots who fly VFR without GPS, iPads, etc who might be interested in an inexpensive collision avoidance device.
Power FLARM too expensive. A stand alone device would be very attractive.

Title: Re: Enhancement Requests
Post by: SteveN on November 15, 2015, 09:36:57 pm
I'm helping install a Avidyne TAS600 in a RV-7 at the moment. That device can be configured without any display as it issues audio traffic warnings e.g.

"{tone} TRAFFIC  2 O'CLOCK HIGH 4 MILES"
"{tone} TRAFFIC  6 O'CLOCK SAME ALTITUDE  LESS THAN 1 MILE"

So If audio only is good enough for a  $10,000 certified system ......

Pi has audio capability and the same output socket as Garmin Aera/496 portables many of which are now connected to aircraft audio via an adaptor.

Just a thought for the future if Lee ever decides to calculates trajectories :)

Title: Re: Enhancement Requests
Post by: Paul_Sengupta on November 17, 2015, 12:08:17 am
You've probably seen this on the Flyer forum, but one "enhancement" which should be possible fairly easily is to incorporate a "ground" mode, where the ARF is set not to transmit, so the unit can be used for surveillance only.
Title: Re: Enhancement Requests
Post by: Wadoadi on November 19, 2015, 11:26:59 am
Hi,
   as an enhancement i would like to suggest that 1 or 2 pins on the GPIO are used to indicate the status of the unit. e.g. pin high once the box is fully booted and another pin high while there is a GPS 3D fix.

the reason for this is that I have build my PilotAware into an enclosure and would like to use these pins to drive status LEDs.

Others may want to remotely mount their devices and the use of 2 pins could provide them with a window into the status of the box.

thanks

Adi   
Title: Re: Enhancement Requests
Post by: Paul_Sengupta on December 03, 2015, 01:48:49 pm
I have a feature request, assuming this hasn't already been done.

How about a serial "pass through" for a Flarm unit?

A USB/serial converter can be used to input the serial data from a Flarm, and then this could be combined with the data being fed out through the Wifi to the tablet. The pinouts for the Flarm are readily available. In this way, the PilotAware would act as a "butterfly" for the Flarm.

We'd have three in one then, assuming we have a Flarm unit. Could be good for gliders.
Title: Re: Enhancement Requests
Post by: efrenken on December 03, 2015, 06:20:05 pm
I have a feature request, assuming this hasn't already been done.

How about a serial "pass through" for a Flarm unit?

A USB/serial converter can be used to input the serial data from a Flarm, and then this could be combined with the data being fed out through the Wifi to the tablet. The pinouts for the Flarm are readily available. In this way, the PilotAware would act as a "butterfly" for the Flarm.

We'd have three in one then, assuming we have a Flarm unit. Could be good for gliders.

This gets my vote for sure!
Title: Re: Enhancement Requests
Post by: flying_john on December 03, 2015, 10:18:01 pm
Just decode the Flarm bursts perhaps and send out to Skydemon/RunwayHD. What frequency does Flarm use, can the RTL be used in a frequency hopping mode of some sort or dual channel reception mode. I know the waterfall displays of received transmissions show a broad spectrum.

Another thought is can the RTL be used to receive the P3i too - just have the RF board do the transmission of position.
Title: Re: Enhancement Requests
Post by: Paul_Sengupta on December 04, 2015, 12:26:25 am
Speaking to Lee on the weekend, he said it would be easier to have another R820T dongle if you wanted another receiver rather than constantly frequency hop with the one. It takes a fair amount of processing to receive stuff using an SDR (Software Defined Receiver) rather than a dedicated receiver, so it makes no sense to receive P3i on an R820T dongle if you've already got a receiver.

To "decode" Flarm, you could do it on a dongle or you could incorporate another dedicated receiver, but the reasons for not doing so have been spelt out before. But if you have an actual Flarm box, then all's well in this regard, hence the request for connecting it.
Title: Re: Enhancement Requests
Post by: the_doc on December 10, 2015, 06:42:20 pm
Would it be possible to put a beta test option in, which a user could enable via the web interface if they wish, to add bearingless Mode C & S data in to the data feed to the tablet?  A number of us could test this out while airborne and advise the team of how accurate / inaccurate the algorithm is. I would suggest data for threats detected within an assumed 5nm range are what would be most helpful for most GA operations.    (Thinking ahead to when this area gets looked out in more detail)
Title: Re: Enhancement Requests
Post by: Robski on December 15, 2015, 06:22:01 am
Are there any plans for providing other ads-b in functionality in the future?
Or would this be dependent on SkyDemon etc being able to use the data received?
Or are such services not going to be made available in the UK?  >:(

I ask as on an FAA page I read:

What are ADS-B In broadcast services?
ADS-B In pilot cockpit advisory services consist of Flight Information Service-Broadcast (FIS-B) and Traffic Information Service-Broadcast (TIS-B). These are free services transmitted automatically to aircraft equipped to receive ADS-B In.
FIS-B provides a broad range of textual/graphical weather products and other flight information to the general aviation community. FIS-B is only available on the 978MHz Universal Access Transceiver (UAT) equipment. FIS-B includes the following:
Aviation Routine Weather Reports (METARs)
Non-Routine Aviation Weather Reports (SPECIs)
Terminal Area Forecasts (TAFs) and their amendments
NEXRAD (regional and CONUS) precipitation maps
Notice to Airmen (NOTAM) Distant and Flight Data Center
Airmen's Meteorological Conditions (AIRMET)
Significant Meteorological Conditions (SIGMET) and Convective SIGMET
Status of Special Use Airspace (SUA)
Temporary Flight Restrictions (TFRs)
Winds and Temperatures Aloft
Pilot Reports (PIREPS)
TIS-B is an advisory-only service available to both 1090ES and UAT equipment users. TIS-B increases pilots’ situational awareness by providing traffic information on all transponder-based aircraft within the vicinity of the ADS-B In equipped aircraft receiving the data.
Title: Re: Enhancement Requests
Post by: Paul_Sengupta on December 15, 2015, 10:23:14 am
The weather stuff is not a function of ADS-B in Europe, only in the US, as they have a dedicated frequency for it.

TIS-B is a function of the radars used in the US.
Title: Re: Enhancement Requests
Post by: SteveHutt on December 16, 2015, 02:29:48 pm
Are there any plans for providing other ads-b in functionality in the future?
Or would this be dependent on SkyDemon etc being able to use the data received?
Or are such services not going to be made available in the UK?  >:(

I ask as on an FAA page I read:

What are ADS-B In broadcast services?
ADS-B In pilot cockpit advisory services consist of Flight Information Service-Broadcast (FIS-B) and Traffic Information Service-Broadcast (TIS-B). These are free services transmitted automatically to aircraft equipped to receive ADS-B In.
FIS-B provides a broad range of textual/graphical weather products and other flight information to the general aviation community. FIS-B is only available on the 978MHz Universal Access Transceiver (UAT) equipment. FIS-B includes the following:
Aviation Routine Weather Reports (METARs)
Non-Routine Aviation Weather Reports (SPECIs)
Terminal Area Forecasts (TAFs) and their amendments
NEXRAD (regional and CONUS) precipitation maps
Notice to Airmen (NOTAM) Distant and Flight Data Center
Airmen's Meteorological Conditions (AIRMET)
Significant Meteorological Conditions (SIGMET) and Convective SIGMET
Status of Special Use Airspace (SUA)
Temporary Flight Restrictions (TFRs)
Winds and Temperatures Aloft
Pilot Reports (PIREPS)
TIS-B is an advisory-only service available to both 1090ES and UAT equipment users. TIS-B increases pilots’ situational awareness by providing traffic information on all transponder-based aircraft within the vicinity of the ADS-B In equipped aircraft receiving the data.

Rob,
Nope, afraid none of that is available outside the US. They have two datalink frequencies in the US - 1090MHz (same as everywhere else in the world) and 978Mhz (only in the US - known as UAT).

There is insufficient bandwidth on 1090MHz for all the FIS-B broadcast info.

We don't have it, but TIS-B is a very useful capability as it creates ADS-B position data broadcasts for aircraft with Mode C or S but without ADS-B. It is achieved by ground stations taking radar position information, converting it to ADS-B format, and rebroadcasting. These groundstations also receive 1090MHz ADS-B aircraft position data and rebroadcast on 978MHz (ditto 978MHz receiption rebroadcast on 1090MHz). That is the major cost implication and drawback of using two separate frequencies for effectively the same purpose.

Nowhere except the US (and possibly China) is using this 1090MHz/978MHz dual datalink model.

Bottom line is... don't go buying any 978MHz UAT ADS-B kit from the US - it won't work here.

Steve
Title: Re: Enhancement Requests
Post by: SteveHutt on December 16, 2015, 02:36:47 pm
p.s. be careful about the term TIS-B.

TIS-B is the label for the traffic data ground broadcasts in the US.
TIS-B is also used by Garmin as the name for the data format they use for receiving traffic data into one of their display devices, e.g. a Garmin 695.
Title: Re: Enhancement Requests
Post by: flying_john on December 20, 2015, 01:17:34 pm
In Runway HD, you can filter traffic displayed to those less than XXXX feet and I am sure SD and others have similar.

Would an enhancement to  be able to filter on a band of altitudes referenced to one's own altitude, i.e display aircraft only + - 500feet from my altitude be aimed at Runway HD or PilotAware.  I find the display takes too much of your "out of the window time" to be useful, especially as there is no audible warning of a threat.

In my view you need to be able to set the size of an imaginary bubble around your own aircraft, by using altitude filtering and position filtering, and then issue an audible warning to draw your attention to the display.

So if there is mechanism to pass ideas to the display software providers.......
Title: Re: Enhancement Requests
Post by: Admin on December 20, 2015, 02:00:55 pm
Hi John

I am sure this is how it works today.
The altitude filter is a relative setting to your own altitude, not absolute

Is this what you mean ?

Thx
Lee
Title: Re: Enhancement Requests
Post by: flying_john on December 20, 2015, 09:44:53 pm
Quote
I am sure this is how it works today.
The altitude filter is a relative setting to your own altitude, not absolute

Oh - o.k , I thought they were absolute values above sea level based on the Mode S actual value transmitted by the aircraft. I did not know that PA or Runway HD did some sums and displayed altitude relative to one's own altitude.

So - if it is as it works today and I set the filter to say 500 feet, and I fly at say 2000ft,  will the display show -500 for a threat aircraft at 1500feet and +500 for a threat at 3000ft?
Title: Re: Enhancement Requests
Post by: Admin on December 20, 2015, 09:56:37 pm
Quote
feet, and I fly at say 2000ft,  will the display show -500 for a threat aircraft at 1500feet and +500 for a threat at 3000ft
?

Correct, except +500 would be 2500ft

Thx
Lee
Title: Re: Enhancement Requests
Post by: flying_john on December 20, 2015, 11:38:59 pm
Whoops - I think I got the sums wrong.

So just to be clear, I am bimbling along at 2000ft and there is one aircraft at 2500 and one at 1500ft. My filter in R/WHD is set to 500ft and the screen will show an aircraft "arrow" and show -500 alongside the one flying at 1500ft and an arrow and +500 alongside the one flying at 2500ft.


John
Title: Re: Enhancement Requests
Post by: Admin on December 20, 2015, 11:43:19 pm
Whoops - I think I got the sums wrong.

So just to be clear, I am bimbling along at 2000ft and there is one aircraft at 2500 and one at 1500ft. My filter in R/WHD is set to 500ft and the screen will show an aircraft "arrow" and show -500 alongside the one flying at 1500ft and an arrow and +500 alongside the one flying at 2500ft.


John

Thats my understanding John, and is certainly the case with SD
thx
Lee
Title: Re: Enhancement Requests
Post by: scsirob on December 23, 2015, 09:51:07 am
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
Title: Re: Enhancement Requests
Post by: Admin on December 23, 2015, 10:08:11 am
Hi Rob

Quote
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.

Quote
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
Title: Re: Enhancement Requests
Post by: scsirob on December 23, 2015, 12:22:17 pm
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
Title: Re: Enhancement Requests
Post by: lmoon on January 13, 2016, 08:52:06 pm
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
Title: Re: Enhancement Requests
Post by: flying_john on January 14, 2016, 11:49:13 am
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
Title: Re: Enhancement Requests
Post by: Admin on January 14, 2016, 12:29:44 pm
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
Title: Re: Enhancement Requests
Post by: AlanG on January 14, 2016, 12:55:04 pm
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
Title: Re: Enhancement Requests
Post by: SteveHutt on January 14, 2016, 06:33:15 pm
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
Title: Re: Enhancement Requests
Post by: Admin on January 15, 2016, 12:11:31 pm
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
Title: Re: Enhancement Requests
Post by: AlanG on January 15, 2016, 05:30:19 pm
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
Title: Re: Enhancement Requests
Post by: flying_john on January 15, 2016, 07:56:29 pm
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
Title: Re: Enhancement Requests
Post by: scsirob on January 17, 2016, 08:36:42 pm
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".
Title: Re: Enhancement Requests
Post by: scsirob on January 17, 2016, 08:38:55 pm
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
Title: Re: Enhancement Requests
Post by: Richard on January 22, 2016, 10:27:06 am
        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?
Title: Re: Enhancement Requests
Post by: Admin on January 22, 2016, 11:14:19 am
        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
Title: Re: Enhancement Requests
Post by: Richard on January 23, 2016, 07:04:09 am
Hi Lee,
    No sorry I'm not a Parasender. The Question was just a general Q. which i had missed in an earlier request. Thank you for the info.
Title: Re: Enhancement Requests
Post by: lmoon on January 24, 2016, 09:20:32 pm
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

HI  I have made good progress and can get the MP3 module to 'talk'. I can supply dummy "NMEA" messages to it from the computer however I should like to start using the serial dongle on the RPi.

RS232 Out (NMEA Sentences at 4800 baud)

- RS232 Out (NMEA+ADSB+P3I Sentences at 57600 baud)

- WiFi Software AP (NMEA+ADSB+P3I)  --- this is working OK on my Sky Demon system (I live under the London TMA)

Your home page suggests the above should be available.  I do not seem to get any data from the USB/Serial port (the serial device does show up on the home page of 192.168.1.1) Do I have to toggle something to get the data to stram out or am I missing something here?

KR

Lionel
Title: Re: Enhancement Requests
Post by: Admin on January 24, 2016, 09:46:52 pm
Hi Lionel

I presume you have it plugged into the port you have configured as rs232 ?
What is the dvice listed as, in the usb device list ?
Thx
Lee
Title: Re: Enhancement Requests
Post by: lmoon on January 24, 2016, 10:04:00 pm
Hi Lee

status page shows the following:

USB Bus 001 Device 005 ID etc etc.    Prolific Tech Inc PL2303 Serial Port

and I have set USB port 3   to Auto and 9600 baud.

Kr

Lionel
Title: Re: Enhancement Requests
Post by: Admin on January 25, 2016, 01:45:52 pm
and I have set USB port 3   to Auto and 9600 baud.

Hi Lionel,

OK, I see the problem.
I suggest you configure this as 'Traffic Dynon', this will send NMEA sentences and Traffic sentences

Thx
Lee
Title: Re: Enhancement Requests
Post by: lmoon on January 25, 2016, 05:48:02 pm
Hi Lee

Thanks for the reply. However if I select Traffic Dynon on USB 3, I then click 'change' and then reboot it still comes back set as auto....

I understand that you are designing a shield - daughter board - to go on the RPi. Do you know its size yet and/or will it cover the complete length of the 40 pin expansion header? (just trying to work out how much space I have for the speech module)

Kr

Lionel
Title: Re: Enhancement Requests
Post by: Admin on January 25, 2016, 05:59:14 pm
Hi Lee
Thanks for the reply. However if I select Traffic Dynon on USB 3, I then click 'change' and then reboot it still comes back set as auto....
I understand that you are designing a shield - daughter board - to go on the RPi. Do you know its size yet and/or will it cover the complete length of the 40 pin expansion header? (just trying to work out how much space I have for the speech module)
Kr
Lionel

Yes it covers the entire GPIO
http://forum.pilotaware.com/index.php/topic,261.msg3717.html#msg3717

Thx
Lee
Title: Re: Enhancement Requests
Post by: lmoon on January 25, 2016, 06:47:54 pm
Hi Lee

Thanks for the link to the shield.

However do you have any further thoughts as to why I can't get the USB3 port to stay on Traffic Dynon selection. (reverts to auto)

Kr

Lionel
Title: Re: Enhancement Requests
Post by: Admin on January 25, 2016, 06:55:54 pm
Thanks for the link to the shield.
However do you have any further thoughts as to why I can't get the USB3 port to stay on Traffic Dynon selection. (reverts to auto)

Simply sounds like a bug, this does not happen in the latest development code.
Which version are you running ?

Thx
Lee
Title: Re: Enhancement Requests
Post by: lmoon on January 25, 2016, 08:07:37 pm
Hi Lee

Version number is 20151219

Kr

Lionel
Title: Re: Enhancement Requests
Post by: lmoon on January 25, 2016, 09:24:27 pm
Hi Lee

Don't panic....problem solved!!  I was using IE 8 to access the setup page. Just had one of those hunches which said try Firefox - which happens to ver 34.0.5 and guess what it now retains the changed settings (Traffic Dynon) now have serial data streaming out of USB3.

Anyway thanks for the help, sorry to have bothered you.....i'm sure you have better things to do.

Kr

Lionel
Title: Re: Enhancement Requests
Post by: lmoon on February 11, 2016, 09:59:14 pm
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

Hi John

I am not using another background process on the Pi. I am using the serial output from the Pi that sends data to third party devices. To that end i Have a PIC processor chip which looks for a PFLAU message. It then copies the message to a buffer and then extracts the required information i.e. threat, heading, level and distance. To date I have written the software and tested the required hardware on a test rig. My intention is to record some MP3 messages on the MP3 module which will create a message in the form of " traffic 3 O'clock level, range 2 miles". Our aircraft has a 4 place headset/mike setup and I have successfully 'injected' the message into the audio system. I am planning to have a control to adjust the sound volume. I am also installing a three colour LED indicator  to indicate system activity if the volume is turned right down. This will give a short flash of green if the threat level is 0 or !. If the threat level is 2 the colour will be yellow and for threat level 3 (urgent) it will be red. I have designed a small daughter board to mount above the USB connectors on the Pi. This is because the Pilot Aware people are planning a board to plug onto the 40 pin header and will cover the existing board completely. I am just about to send off the PCB design to get some prototype boards made. If we get some good weather I plan to test talking to ATC on the radio whilst a 'threat' message in being overlaid on the audio - likewise when a message is being received from ATC. If anyone is interested I am happy to share the details of my design components and board layout. It should be noted that Pilot Aware intend to provide an audio output on their system in late 2016.
Title: Re: Enhancement Requests
Post by: flying_john on February 13, 2016, 03:00:18 pm
That all sounds very positive Imoon. It sounds as if you have done a lot of work. I suspect there is some serious maths going on to work out bearing heading and speed to see if a contact is a threat and then triggering the appropriate phrase to be output on the audio line.  I hope that Lee will take a look at your work to see if it will help the integration of such a feature into the Paw as there is plenty of on-board processing power in the Pi to do this without needing an external processor.  Good luck with it and keep us all posted.

John
Title: Re: Enhancement Requests
Post by: lmoon on February 15, 2016, 07:01:05 pm
Hi John

Surprisingly there is not a lot of maths involved. If you like to drop me a email at lionel@lionelmoon.co.uk  I will send you the details of how the NMEA $PFLAU sentence is constructed - it has most of the hard work done already. Incedentally I have just ordered a couple of prototype PCB's to build a complete circuit.

Kr

Lionel
Title: Re: Enhancement Requests
Post by: lmoon on February 18, 2016, 07:33:02 pm
Hi Lee

Can I ask a few questions regarding the P3i packet protocol. Having got to grips with the $PFLAU sentence I am now looking at P3i sentence. Firstly will it be available for third parties like the NMEA sentences are and if so will it be on the same USB port or another - I am reading LAU sentences on USB 3 set for Traffic Dynon. Will the P3i sentence be 'raw' data as shown in your home page presentation?  If so is there anywhere I will be able to obtain 'my' position from in order to calculate range, bearing etc.  Should be receiving prototype pcb's for my speech output in a couple of days.

Apologies for asking so many questions.....

Kr Lionel
Title: Re: Enhancement Requests
Post by: Admin on February 18, 2016, 07:47:59 pm
Hi Lionel

The P3i data is the RF packet format.
For the NAV interface it will appear as another flarm data format message
Thx
Lee
Title: Re: Enhancement Requests
Post by: lmoon on February 18, 2016, 09:22:11 pm
Hi Lionel

The P3i data is the RF packet format.
For the NAV interface it will appear as another flarm data format message
Thx
Lee

Hi Lee

Thanks, that sounds as though it should just be an extension on the work I have already done.
Kr
Lionel
Title: Re: Enhancement Requests
Post by: lmoon on February 19, 2016, 10:16:04 pm
Hi Lionel

The P3i data is the RF packet format.
For the NAV interface it will appear as another flarm data format message
Thx
Lee

Hi Lee

Do you have the details of this data sentence yet ?
 .
Kr
Lionel
Title: Re: Enhancement Requests
Post by: lmoon on February 25, 2016, 06:34:33 pm
Hi Lee

I don't know is you missed my last question as I had it embedded in a quote !!

Do you have the details of this data sentence yet ?
 .
Kr
Lionel
Title: Re: Enhancement Requests
Post by: Admin on February 25, 2016, 08:56:44 pm
Hi Lee
I don't know is you missed my last question as I had it embedded in a quote !!
Do you have the details of this data sentence yet ?
 .
Kr
Lionel

Hi Lionel,
I am not sure what you are asking.
P3i messages are sent over the radio interface, not the RS232 interface.
When P3i messages are received, they are translated to flarm style messages, and sent over RS232
Thx
Lee
Title: Re: Enhancement Requests
Post by: lmoon on February 25, 2016, 09:43:42 pm
Hi Lee

So are you saying that a P3i message is received it will come out over RS232 and look like a $PFLAU message ?

Kr

Lionel
Title: Re: Enhancement Requests
Post by: Admin on February 25, 2016, 09:53:35 pm
Hi Lee

So are you saying that a P3i message is received it will come out over RS232 and look like a $PFLAU message ?

Kr

Lionel

Exactly
Thx
Lee
Title: Re: Enhancement Requests
Post by: lmoon on March 09, 2016, 03:10:28 pm
Hi Lee

Regarding $PFLAU sentences can you provide details of when alarm levels 1 and 2 are generated?. Obviously the heading/track denotes a potential conflict but at what height difference and at what range do the two alarm levels get triggered.

Kr

Lionel
Title: Re: Enhancement Requests
Post by: Admin on March 09, 2016, 04:51:58 pm
Hi Lee

Regarding $PFLAU sentences can you provide details of when alarm levels 1 and 2 are generated?. Obviously the heading/track denotes a potential conflict but at what height difference and at what range do the two alarm levels get triggered.

Kr

Lionel

Hopefully this is self explanatory, but quite liable to change

Code: [Select]
typedef struct tfcAlarmAdsbS {
Uns32 hdiff; // Horizontal Range boundary (metres)
Uns32 vdiff; // Vertical Range boundary   (ft)
} tfcAlarmAdsbT, *tfcAlarmAdsbP;
const tfcAlarmAdsbT alarms_adsb[] = {
[0] = {999999, 999999}, // km - ft
[1] = {10000,  2000}, // km - ft
[2] = {5000,   1000}, // km - ft
[3] = {3000,   500}, // km - ft
};
Title: Re: Enhancement Requests
Post by: Richard on March 09, 2016, 06:30:14 pm
Lee
    Thank you for the update option in the new versions.
    This is just a suggestion for a later option, but would it be possible to update PAW via the wifi Dongle on the PAW? It would mean connecting the PAW direct to a Hot Spot. May-be this could be selected on the configure page of PAW then just press update?  This would be a good option for a PAW fixed peppermint with in the aircraft panel and not easy accessible. It would allow an update at the airfield using a smart phone as hotspot.
Title: Re: Enhancement Requests
Post by: AlanG on March 09, 2016, 07:46:56 pm
Would that class as a "sweet" solution.     ;D

Ah the vagaries of predictive text.

Alan
Title: Re: Enhancement Requests
Post by: lmoon on March 09, 2016, 07:49:47 pm
Hi Lee

Thanks for that, it is indeed self explanatory.  ;)  Is there by chance a 'test' version of the PAW software which can force $PFLAU sentences with error messages?  I only as the only other option that I can see it to arrange to physically fly close to another aircraft !! (i am running version 20151219)

Kr

Lionel
Title: Re: Enhancement Requests
Post by: Admin on March 10, 2016, 09:01:58 am
Lee
    Thank you for the update option in the new versions.
    This is just a suggestion for a later option, but would it be possible to update PAW via the wifi Dongle on the PAW? It would mean connecting the PAW direct to a Hot Spot. May-be this could be selected on the configure page of PAW then just press update?  This would be a good option for a PAW fixed peppermint with in the aircraft panel and not easy accessible. It would allow an update at the airfield using a smart phone as hotspot.

Hi Richard,
This would be a great solution, unfortunately this will not work.
The PAW WiFi is configured as a server,
in order for this to connect to your phone hotspot, it would need to run as a client.
If the PAW Wifi runs as a client, you cannot connect to it from your table device, thus rendering this bit impossible
Quote
May-be this could be selected on the configure page of PAW then just press update?
- because its a client, not a server  :o

Theres a hole in my bucket dear Liza dear Liza ....

Thx
Lee
Title: Re: Enhancement Requests
Post by: Admin on March 10, 2016, 09:04:07 am
Hi Lee
Thanks for that, it is indeed self explanatory.  ;)  Is there by chance a 'test' version of the PAW software which can force $PFLAU sentences with error messages?  I only as the only other option that I can see it to arrange to physically fly close to another aircraft !! (i am running version 20151219)
Kr
Lionel

There is some internal code that has this capability, but not in a form to release.
The release which will contain the PilotAware Bridge should have a tracking capability, which will record your movements, and everyting that was visible to your device, and it will have the option to save that data.
A replay could be added later

Thx
Lee
Title: Re: Enhancement Requests
Post by: flying_john on March 10, 2016, 11:54:52 am
Lee - I think what Lionel is looking for is a way to test the device (tablet or otherwise) to ensure it makes an appropriate alert to the pilot when a threat  becomes an alarm of one type or another. Its quite tricky for developers of devices that will attach to the PAW (RunwayHD, Skydemon or other eqpt) to exercise all of their code without the ability of making the PAW send out all possible PFLAU sentences.

John
Title: Re: Enhancement Requests
Post by: lmoon on March 10, 2016, 12:48:44 pm
Lee - I think what Lionel is looking for is a way to test the device (tablet or otherwise) to ensure it makes an appropriate alert to the pilot when a threat  becomes an alarm of one type or another. Its quite tricky for developers of devices that will attach to the PAW (RunwayHD, Skydemon or other eqpt) to exercise all of their code without the ability of making the PAW send out all possible PFLAU sentences.

John


HI Lee

Perhaps I should have mentioned that I live under the London TMA and get the 09 departures to Ockham VOR coming directly over the house at about 3000 ft.  All I would like to do is to be able to set the 'alert altitude' to something like 4000 ft then the PAW unit would give me $PFLAU messages with data in them.  Indecently from my upstairs room I can see traffic on the PAW unit up to 45 Km away!

Kr

Lionel
Title: Re: Enhancement Requests
Post by: Paul_Sengupta on March 10, 2016, 07:19:18 pm
45km? From upstairs here in Guildford I can see them over Belgium and the Netherlands!
Title: Re: Enhancement Requests
Post by: lmoon on March 11, 2016, 08:22:38 pm
Hi Lee
Thanks for that, it is indeed self explanatory.  ;)  Is there by chance a 'test' version of the PAW software which can force $PFLAU sentences with error messages?  I only as the only other option that I can see it to arrange to physically fly close to another aircraft !! (i am running version 20151219)
Kr
Lionel

There is some internal code that has this capability, but not in a form to release.
The release which will contain the PilotAware Bridge should have a tracking capability, which will record your movements, and everyting that was visible to your device, and it will have the option to save that data.
A replay could be added later

Thx
Lee

Hi Lee

It was not a tracking ability that I was inquiring about.  What I was looking for was the PAW unit to transmit $PFLAU sentences with alarm 1 ,2 or 3 and thus provide some 'real' data to test my audio device - I have done computer simulations to date. As mentioned I have EGLL traffic departing over my house and I can see from the traffic screen on the PAW that they are usually below 4000 feet and come to within 0.5Km of the house!!  What I was looking for is a doctored version of the PAW software that that 'thinks' anything below 4000 feet is a threat. The heading and distance is already taken care of (see above)

I presume that even if we have two PAW units on the same desk we would not get alert messages as there is zero velocity between the two units..

Kr Lionel
Title: Re: Enhancement Requests
Post by: SteveHutt on March 12, 2016, 09:57:57 pm
Isn't the Alarm test issue solvable by creating the ability for users to set their own alarm thresholds?

If that table detailed a few posts earlier were the default values and there was a facility to override them if desired with a user's preferred values then testing becomes very simple. Setting very high thresholds would cause all passing traffic to trigger the alarm.,

Plenty of GPS navigation devices offer this sort of user configuration facility. I'm sure my old Garmin 296 let me configure many of the control functions like this.

Steve
Title: Re: Enhancement Requests
Post by: Chris7777 on April 13, 2016, 03:11:47 pm
Hi

Just to report that I built my PAW back in Oct 2015 and it seemed to boot ok when monitoring the HDMI output. However there is not much traffic to monitor in the wilds of Scotland so it wasn't until this last week that I installed the GPS dongle and updated the software and found that it works brilliantly picking up aircraft as far out as 100km, just from my kitchen table.

I have now disconnected the P3I Tx, as I think we are not meant to be using that at the moment?

I think a status LED to tell me that PAW is working normally would be useful and it would be great to have a display of non-ADS-B traffic which appear on the traffic.cgi page, superimposed on the SD like the attached photo.

Well done the PAW team.

Many thanks for developing an interesting and I hope, useful project.

Chris
Title: Re: Enhancement Requests
Post by: SteveN on May 08, 2016, 06:18:04 pm
I guess two or more aircraft sat on the ramp together will get a choice of PAW to connect to.

Might be an idea to append  the Wifi hotspot with  PAWs flightID entry (e.g. reg).

eg: "Pilotaware-B999XXXYYYY - G-ABCD"

Not a fan of encryption as a solution in this instance as people also fly in other peoples aircraft.
Title: Re: Enhancement Requests
Post by: the_doc on May 17, 2016, 11:35:32 pm
Any chance of making the Ethernet IP address manually configurable or DHCP compliant?

My Classic is set at 192.168.0.100 - believe it or not (don't ask!) I have devices around that range and a printer whose IP is identical I really don't want to change without causing a major headache!

I would have thought it better to set this to use DHCP (if Pi does such a thing?) as every owner's network will be quite different and this might of course be an issue in update problems that could be avoided, saving you from possible support requests?

Great idea, Ethernet enabled updates-  :)
Title: Re: Enhancement Requests
Post by: Admin on May 17, 2016, 11:43:25 pm
Any chance of making the Ethernet IP address manually configurable or DHCP compliant?

My Classic is set at 192.168.0.100 - believe it or not (don't ask!) I have devices around that range and a printer whose IP is identical I really don't want to change without causing a major headache!

I would have thought it better to set this to use DHCP (if Pi does such a thing?) as every owner's network will be quite different and this might of course be an issue in update problems that could be avoided, saving you from possible support requests?

Great idea, Ethernet enabled updates-  :)

Hi
Actually it does use DHCP if your subnet is NOT 192.168.0.xxx
This was for ease of test development, so when I plug into my netwok it is always the same IP  :)

Its a valid point, and probably should be added in the future
I have had similar thoughts on ssid name, and encryption key

Thx
Lee
Title: Re: Enhancement Requests
Post by: the_doc on May 18, 2016, 07:46:42 am
Thanks Lee. That's great news. (My temporary fix is to run a second router set to a subnet other than 192.168.0.* for now then!)
Title: Re: Enhancement Requests
Post by: peteD on May 18, 2016, 11:36:48 am
Block ground vehicles please!

Pete wrote:

Quote
However at my airfield I found several unknown Hex codes on the traffic page and displaying on my SkyDemon aircraft symbol.

Looking at the traffic page I believe they are ground vehicles as they are equipped with transponders.(reverse hex code lookups showed "unknown").

So is there any way of filtering out these known hex codes, i.e. I like to be able to enter more than one code into Hex-ID?

Lee wrote:

Quote
as you have quite correctly worked out, the HEX-ID field is for your own transponder ICAO, this simply stops PilotAware using either your Mode-S or Mode-S/ES(ADSB) from your own transponder.

Unfortunately there is no way to filter other objects, other than relative height difference in your Nav tool settings.
So the ground items could be filtered once in the air at a relative height greater than your filter.

Interestingly, I recall that ground vehicles have a setting in the DF strings which indicate it is a ground setting, so there is the potential to filter out ALL ground vehicles, could I ask you to add this onto the enhancement requests ?

Please can we filter out ground vehicles/traffic?
Thanks
Pete
Title: Simulator
Post by: gilest on May 19, 2016, 11:15:18 am
Not sure if this has already been discussed but it would be great to have a simulator mode - useful for setting up and testing. Have just purchased and setup my unit but would like to adjust volume of warnings from PAW and to see how both ADSB, PAW and Mode S contacts and warnings appear on my Runway HD.
Title: Re: Simulator
Post by: Admin on May 19, 2016, 11:27:09 am
Not sure if this has already been discussed but it would be great to have a simulator mode - useful for setting up and testing. Have just purchased and setup my unit but would like to adjust volume of warnings from PAW and to see how both ADSB, PAW and Mode S contacts and warnings appear on my Runway HD.

Yes this is an interesting concept, we could probably just add a replay feature of a pre-recorded flight.
This could then be selected on a repeat loop in the web interface.
Good idea!
Title: Re: Enhancement Requests
Post by: SteveN on May 21, 2016, 11:39:12 am
Not sure how feasible it would be but an alternative/addition to using the PI jack for traffic warnings might be to send them over Wifi to the tablet. The tablet then announces all the warnings.

Play store already appears to have a free app to do this.

https://play.google.com/store/apps/details?id=com.vnd.wifiaudio&hl=en (https://play.google.com/store/apps/details?id=com.vnd.wifiaudio&hl=en)

Cooperation from Skydemon etc would of course mean no need for a second app.



Title: Re: Enhancement Requests
Post by: Richard on May 22, 2016, 04:04:36 pm
Would it be possible to update our PAW via one of the USB slots by using a USB Dongle? This will allow a PAW to be fixed within an aircraft with an extension USB from it. ( where a GPS on an extension )
Title: Re: Enhancement Requests
Post by: Richard on May 22, 2016, 10:16:37 pm
Sound alerts are fantastic, I really like it.. Just one thing, at a busy airfield on taxi and takeoff it can be very distracting as you are been warned about traffic in patients around the airfield. Would is be possible to select traffic below, say, 1200feet and you already have above traffic already selectable

Thank you

Edit...... May be to filter out traffic below 500 ft would be better!!
Title: Re: Enhancement Requests
Post by: Admin on May 23, 2016, 04:29:23 pm
Sound alerts are fantastic, I really like it.. Just one thing, at a busy airfield on taxi and takeoff it can be very distracting as you are been warned about traffic in patients around the airfield. Would is be possible to select traffic below, say, 1200feet and you already have above traffic already selectable

Thank you

Edit...... May be to filter out traffic below 500 ft would be better!!

Hi Richard,
I am not sure what you are asking here ?

Firstly are you referring to the ADS-B or Mode-S alerts ?
(ADS-B will give Direction and Range, Mode-S simply a 'Warning, Traffic')

for Mode-S you can filter in the configuration screen for +/- 500, 1000, 2000, 30000 ft vertical

for ADS-B there are 3 Zones comprised of
+/- 500ft (vertical), 3km (horizontal)
+/- 1000ft (vertical), 5km (horizontal)
+/- 2000ft (vertical), 10km (horizontal)

You are only given an alert as each zone is entered.
So are you asking for more control over the sizes of the zones ?

Thx
Lee
Title: Re: Enhancement Requests
Post by: Paul_Sengupta on May 23, 2016, 05:28:25 pm
I think Richard's asking that if you're on the ground, would it be possible to have a switch to filter out other ground traffic otherwise you'll continuously be getting alerts from other ground traffic as you taxi and take off.

Probably likewise as you approach the airport for a landing.

As suggested, this could be filtering out traffic below a certain altitude (though 500ft MSL wouldn't work at many airfields, and you couldn't do AGL without having a comprehensive database of airfields and their elevation) or perhaps below a certain altitude and below a certain ground speed? But this would perhaps filter out helicopters, and you'd need to keep a table of position reports of all traffic to be able to work out their speed.

Title: Re: Enhancement Requests
Post by: Richard on May 23, 2016, 05:41:31 pm
Hi Lee,
    OK, As I Taxi out as Sherburn yesterday, there is 3 aircraft in 1000 ft circuit, and 4 taxing, two in and two out, An estimation, 3 of these aircraft are mode S (Club Aircraft all are at Sherburn) there was one in the Circuit ADSB, I could see him. :P

While I'm taxing out the Pilotaware is going crazy with voice alerts (I'm not complaining as it doing what is should) It is just very distracting on takeoff, I just wanted to know if it could be tweaked a little. Maybe only starts providing info when airborne or filter out traffic on the ground or in circuit at a set altitude. This my be difficult to imply correctly.

If flying in to the LAA Rally the voice alerts will go crazy and I would probably turn PAW off, something I do not want to do.

This is only a suggestion

Thanks for your help.
Title: Re: Enhancement Requests
Post by: exfirepro on May 23, 2016, 06:10:03 pm
Hi Lee/Richard,

As you say, Lee, this is not generally an issue with ADS-B as the alerts only occur as each aircraft breaks each 'puck' boundary on the way in. This can however certainly be an issue with Mode S alerts, which tend to 'repeat' as the signal from each aircraft drops below and then returns above each alert threshold (as can happen in a large GA circuit, especially from an aircraft on the ground).

Hopefully the proposed revisions to the Mode S trigger levels will help. I will also give some thought to how we might filter or reduce alerts from aircraft on the ground, though this will not be easy. I certainly wouldn't want to filter out aircraft in the circuit, bearing in mind that's where the majority of accidents occur.

I will give this some more thought.

Regards

Peter R
Mode S Tester

Supplementary:-
We might be able to use the proposed Ultra Short Range setting as a Ground Filter for GA Airfields, though this would mean resetting after takeoff in [Config] before continuing en-route which might be too much of a fiddle. I will try this during our next test session and report back.
Title: Re: Enhancement Requests
Post by: Admin on May 23, 2016, 06:19:36 pm
Block ground vehicles please!

I think I have this solved - but difficult to test.
I am now testing for an 'absent' Altitude setting, and excluding this from the list of possible threats.
It will still appear in the traffic table, but will not be dispatched to the Navigation Device, or produce an
audible warning.

Will be available in the next release.
Title: Re: Enhancement Requests
Post by: exfirepro on May 23, 2016, 06:48:30 pm
Lee / PeteD,

Just out of interest, what 'type' of signal do these ground vehicles transmit?

(Sorry Guys, Just read back the thread and sussed out that bit)

I wondered if a similar filter would work for Richards's ground (aircraft) Mode S traffic, but at my own field for example, Mode S or ADS-B aircraft can show on the traffic screen with a relative altitude of from -75 to +75 feet depending on where we each are on the field. Other airfields will of course differ. Taking  GPS altitude variation into account, you would probably have to set a filter at something like +/- 100 feet to filter these out without reducing the effectiveness of the unit for detecting circuit traffic. Anything already within that band is probably already too close for PAW to be of much help!

Peter R
Title: Re: Enhancement Requests
Post by: Richard on May 23, 2016, 06:54:01 pm
Block ground vehicles please!

I think I have this solved - but difficult to test.
I am now testing for an 'absent' Altitude setting, and excluding this from the list of possible threats.
It will still appear in the traffic table, but will not be dispatched to the Navigation Device, or produce an
audible warning.

Will be available in the next release.

Hooo!!! My word your good

I will test when it's avalble

Thank you Lee
Title: Re: Enhancement Requests
Post by: Admin on May 23, 2016, 07:03:09 pm
Lee / PeteD,

Just out of interest, what 'type' of signal do these ground vehicles transmit?

I wondered if a similar filter would work for Richards's ground (aircraft) Mode S traffic, but at my own field for example, Mode S or ADS-B aircraft can show on the traffic screen with a relative altitude of from -75 to +75 feet depending on where we each are on the field. Other airfields will of course differ. Taking  GPS altitude variation into account, you would probably have to set a filter at something like +/- 100 feet to filter these out without reducing the effectiveness of the unit for detecting circuit traffic. Anything already within that band is probably already too close for PAW to be of much help!

Peter R

Hi Peter,
In the case of the ground vehicles Pete was reporting, the Altitude is reported as UNKNOWN, so in the traffic table it is shown as '-'.
but in the comparison routine the variable contained a zero (0), so I just needed to test whether the value is valid or not.

Thx
Lee
Title: Re: Enhancement Requests
Post by: exfirepro on May 23, 2016, 07:12:24 pm
Richard,

There has been a bit of cross-posting. The vehicles PeteD had asked Lee to block are airfield ground vehicles not aircraft (see Lee's explanation above). No doubt he will advise in due course of the feasibility of my suggestion to filter aircraft within say +/- 100ft of your own to reduce the ground alert clutter. Hopefully should be feasible.

Regards

Peter
Title: Re: Enhancement Requests
Post by: Paul_Sengupta on May 23, 2016, 08:41:11 pm
For taxying it would be easy, just don't give audio alerts if your ground speed is (say) under 20 knots. There could be a switch for this depending on if you wanted it or not. Wouldn't help for take off or landing though.
Title: Re: Enhancement Requests
Post by: exfirepro on May 23, 2016, 08:50:50 pm
Hi Paul,

Could work, but some flexwings don't fly much faster than that (LOL) ;D

Joking apart, using an altitude filter of +/- 100 ft could minimise the problem and would automatically take account of the airfield elevation as 'you' would be on the ground (thus automatically setting the datum) - or if on final, warnings would cease during the final approach /round-out and hold-off phase. And all this without needing to manually switch anything!

Peter
Title: Re: Enhancement Requests
Post by: Paul_Sengupta on May 23, 2016, 09:08:30 pm
The "switch" I was talking about would be a setup option.

I'm sure Lee will give this problem some thought!  ;D
Title: Re: Enhancement Requests
Post by: exfirepro on May 23, 2016, 09:36:22 pm
I realised that Paul, but if we can achieve what we need without switching screens, it would be even better - as we will keep everyone's eyes outside the cockpit and also reduce the chance of SD (or other nav systems) 'dropping out' as we swap between apps.

Peter
Title: Re: Enhancement Requests
Post by: Paul_Sengupta on May 23, 2016, 10:12:12 pm
Sorry, when I mean a setup option, I mean you set it up when you first set up PAW as per personal preferences, and then it's either on or off for the rest of eternity! Or until you want to change it.

A "stop voice alerts when under 20 knots" tick box, so you can choose to tick it or not tick it, then leave it be.
Title: Re: Enhancement Requests
Post by: peteD on May 23, 2016, 11:04:40 pm
Hi All,To clarify:

The ground traffic I was referring to are shown in the attached screenshot as hex 43BF78,79 & &7A.

These are ground vehicles and would differ from aircraft on the ground who had their transponders on.(Not sure what the difference would be between ground and Alt mode, as both seem to tx an Altitude, at least mine appears to do so)


Regards

PeteD
Title: Re: Enhancement Requests
Post by: T67M on May 24, 2016, 02:15:31 am
Joking apart, using an altitude filter of +/- 100 ft could minimise the problem and would automatically take account of the airfield elevation as 'you' would be on the ground (thus automatically setting the datum) - or if on final, warnings would cease during the final approach /round-out and hold-off phase. And all this without needing to manually switch anything![/b

I'm not sure I like the idea of disabling the warning of aircraft within 100ft of mine - they're the ones I'm most likely to hit while flying! Witness my airprox where I was head-on, same altitude and only avoided a collision by pushing -2G at the last second. Literally  :(
Title: Re: Enhancement Requests
Post by: exfirepro on May 24, 2016, 07:20:29 am
Joking apart, using an altitude filter of +/- 100 ft could minimise the problem and would automatically take account of the airfield elevation as 'you' would be on the ground (thus automatically setting the datum) - or if on final, warnings would cease during the final approach /round-out and hold-off phase. And all this without needing to manually switch anything![/b

I'm not sure I like the idea of disabling the warning of aircraft within 100ft of mine - they're the ones I'm most likely to hit while flying! Witness my airprox where I was head-on, same altitude and only avoided a collision by pushing -2G at the last second. Literally  :(

Believe me, I fully appreciate your concerns. You were very lucky and are a terrific 'advert' for why systems like PAW are so important. I too have been there, though didn't get it on video (though I do have a snatched still shot as I banked hard left to avoid the oncoming aircraft - I just happened to have my camera in my hand), so fully appreciate where you are coming from. But remember, what we are discussing here is 'What is the best way of trying to reduce the number of what become nuisance alerts when you are on the ground, without compromising safety in the air.

I don't like the idea of deliberately excluding warnings of any sort, but having  experienced continual alerts from high powered transponders while on the ground at busy airports during Mode S testing, I can appreciate the strain that this places on the pilot and hence why the need to reduce such 'nuisance' alerts was asked for. Before I got involved in the testing, I didn't for example appreciate that CAT traffic in Ground Radar mode can bump out a massive 'mode S' signal while taxiing or queueing waiting for departure, and GA transponders, though less powerful, still cause the same problems.

If Lee agrees to it, the filter would be set for mode S only - ADSB and P3i use a different trigger system which generates far fewer alerts because they are generated from the aircraft's actual position and only occur as it approaches you and breaks one of 3 clearly defined 'physical' boundaries. Because Mode S alerts are not generated from physical boundaries, but from received signal strength at 3 different trigger levels, they repeat every time the signal drops below and then returns above any of these triggers - which can happen several times when the aircraft is in the circuit - especially if it 'disappears' from your antenna behind hangers or terrain for example, or simply because the distance between you increases, then shortens again, generating repeat warnings each time this occurs. The same thing can happen with aircraft taxiing on the ground. These then become 'nuisance' alerts, because you should already be aware of the presence of the aircraft.

In the air, these multiple mode S alerts are far less likely to occur (unless you are flying in very close formation with other mode S aircraft) and the chances of a mode S aircraft getting within +/- 100 ft of your altitude in normal flight without breaking all 3 trigger thresholds as it approaches (thus alerting you to its presence in sufficient time for you to lookout for it) would be extremely low. But of course mode S can only tell you an aircraft is approaching - it can't tell you where it is - that I'm afraid is down to the pilot. To help reduce 'nuisance alerts' and give some user choice, Lee has already introduced 'user selectable' Mode S Detection Range settings in 'Configuration' in the current software release. As part of ongoing development, these are being continually tested and refined and an improved version will be included in a forthcoming update. What we are discussing here is simply a relatively minor adjustment to address a specific ground issue.

Trust me, we are well aware of the dangers and wouldn't suggest - and Lee certainly wouldn't make - any changes which might in any way affect safety without extensive thought, discussion, testing and due consideration of the risk. Hopefully this will help to alleviate your concerns.

Regards

Peter
Title: Re: Enhancement Requests
Post by: Richard on May 24, 2016, 08:21:52 am
Thank you Peter,
          you have made the suggestion I made very clear. I concur totally.
Title: Re: Enhancement Requests
Post by: tnowak on May 24, 2016, 08:35:31 am
Wouldn't a check of the "host" PAW motion (speed) be the simplest check, as mentioned previously? If less than 20 MPH (or Kt) inhibit  all alarms?
I can't think of a "flying" scenario where this type of mask would affect real alerts when in the air.

SD uses a similar check for when to start and stop logging.
Tony Nowak
Title: Re: Enhancement Requests
Post by: Paul_Sengupta on May 24, 2016, 08:52:26 am
I can't think of a "flying" scenario where this type of mask would affect real alerts when in the air.

Maybe if you were a police helicopter.

Or a flexwing flying into a good headwind.

But if you could turn the feature on or off, you could choose to keep the voice alerts enabled below 20 knots.
Title: Re: Enhancement Requests
Post by: exfirepro on May 24, 2016, 12:31:32 pm
All these suggestions have their pros and cons (what's new). Ideally a built in trigger to activate PAW after say 200 ft of climb might be the answer, but that would mean no alerts on the ground from inbound aircraft, which was why I favoured a fairly tight +/- altitude filter. I have given some thought since last night to Paul's suggestion to make it selectable, which I am coming round to now. I just don"t like the idea of having to manually switch something on/off during or after takeoff - far too easy to forget in my experience (viz. my transponder!).

Possibly a combination of forward motion (but as Paul says might not suit helicopters / gyros / older flex wings / paramotors etc) and or an automatic altitude after takeoff 'switch' (driven by the software) might be the answer. I'm sure Lee is following this and cringing at the thought of all the extra workload. 😂

Good positive discussion though

Regards to all

Peter
Title: Re: Enhancement Requests
Post by: exfirepro on May 26, 2016, 01:45:43 pm
Further Supplementary after considerably more thought.

A Mode S altitude filter (+/- 100 feet with respect to your own ground 'altitude'), set to switch on automatically when the unit is powered up, would be self calibrating and would cut out alerts from other aircraft on the ground, while leaving those inbound or already in the circuit live (until the final 100 feet or so of descent). That won't stop potential repeat alerts from aircraft in the circuit, but IMHO these are ones we need to hear.

This filter would be set by default but could be de-selectable in 'Configuration' (thanks Paul).

ADSB and P3i, which are far less problematic would be left as they are.

If we could also configure the filter to switch 'off' automatically after takeoff, at say 500 feet WRT our original ground altitude, this would remove the worry about manual switching and the concerns about filtering out aircraft close to our own altitude in flight as these would then remain visible within whatever upper and lower altitude limits you have yourself set.

Now I just need to figure out a way of automatically switching the filter back on again for landing, though I'm not sure this phase presents so much of a problem if left 'open' (oh and persuade Lee to write the additional software). :)

Regards

Peter
Title: Re: Enhancement Requests
Post by: Admin on May 26, 2016, 05:24:15 pm
So I have been thinking on this, and it seems difficult doesn't it  ::)

If you use an altitude filter, you may filter the thing you are interested in
if you use motion filter, not good for a helicoptor

So how about an audio mute with a timeout ?

I have been thinking of having a control panel on the web server with some BIG BUTTONS (no fiddly buttons for flight)
so that they are easy to control, and MUTE seems a good candidate

For example a 5 minute mute timeout (or selectable), so that it automatically re-enables after a timeout, or can be manually re-enabled before the timeout has elapsed.

This is actually along the lines of another idea I had which is I want the following audio reminders

1. "Check Flaps"
I am always forgetting to retract flaps after takeoff, then wondering why its sluggish, it is simple to detect the initial acceleration and climb, then simply output a single message to "Check Flaps"

2. "Instrument Scan"
Every 5 minute interval, just a nice reminder to scan your instruments.

And I am sure we can think of others ...

Thx
Lee

Title: Re: Enhancement Requests
Post by: exfirepro on May 26, 2016, 05:47:38 pm
Lee,

My only concern about an audio mute on the ground is that it masks alerts from inbound aircraft which would warn taxiing aircraft not to cross or enter runways in front of landing aircraft. I know... we should be checking visually, but the same could be said of every other potential conflict situation.

Also recent experience when changing to Config or other screens then back to SD is to find SD has dropped out and 'go flying' has to be restarted which is a real pain, especially in bumpy conditions, so I would prefer to avoid changing screens at all once set, if at all possible.

Good idea for audio prompts though.

Peter
Title: Re: Enhancement Requests
Post by: SteveN on May 26, 2016, 11:13:12 pm
As grist to the mill, this is what  Avidyne TAS does (by default):

When on the ground, other ground traffic is NOT displayed. Airborne traffic is displayed. No audio warnings while on the ground. I think TAS detects something as also on the ground by being the same FL.  A decent Mode S installation will show 25ft resolution but there are plenty around using old encoders so they will be 100ft.

TAS detects it is on the ground via a squat switch.  This could be replaced by GPS speed detection as has been suggested above.  A TB20 and a paramotor need different speeds so best have speed selectable.
Out of interest Garmin use a combination of speed and change in altitude to detect airborne.
Title: Re: Enhancement Requests
Post by: peteD on May 27, 2016, 10:17:09 am
Is it not possible to filter out mode s transponders when in ground mode?(I understand the ground mode transmissions are different from airborne, and have status info)?
Title: Re: Enhancement Requests
Post by: Admin on May 27, 2016, 01:27:46 pm
Is it not possible to filter out mode s transponders when in ground mode?(I understand the ground mode transmissions are different from airborne, and have status info)?

Hi Pete

I have added this to the current code, so that Ground Mode is ignored from reporting (this will be in the next release)

I think most of the comments here are regarding aircraft in the circuit when you are on the ground, and a way to filter that
information as it is 'too noisy', so a way to filter during arrival/departure

Thx
Lee
Title: Re: Enhancement Requests
Post by: T67M on May 27, 2016, 04:50:47 pm
A couple of thoughts here. First, I frequently hop from one aircraft to another. Having a paper list of all the ICAO codes is a bit fiddly and error prone - would it be possible to instead have a pull-down list of options which can be configured quickly and easily?

Second, accessing the web interface on a tablet whilst in the aircraft is a bit fiddly. Is there any way to add a physical button or even a rotary switch to select between aircraft, or to mute circuit alerts etc? I appreciate this would be a hardware modification - perhaps for the next iteration of the bridge?

Finally, I flew with the Classic for the first time today. In the air it seemed to behave perfectly, however on the ground I saw two returns from an aircraft in the circuit - both were indicating the same relative altitude, one was moving in the correct place, but the other was piggy-backed onto my aircraft. I believe the aircraft is equipped with a Mode S-ES (ADS-B) transponder but was not carrying a PAW. I guess that the piggy-back aircraft was the Mode-S detected return, but I can't see why the PAW didn't collate it with the Mode S-ES (ADS-B) return.

(http://mikeellis.org.uk/webphotos/20160527-double.png)
Title: Re: Enhancement Requests
Post by: Admin on May 27, 2016, 05:22:22 pm
Hi T67M,

Wow that is interesting, and needs investigating.
the display you are showing there is the FlightID, by any chance did it switch to the Reg or ICAO ?

Unless we have a bug, this would indicate this aircraft was sending a different ICAO code for Mode-S and ADS-B
which is pretty unbelievable, but possible.

All is not lost
In the background PilotAware is recording lots of information about the data you transmitted and the data you
received ADS-B/P3I/Mode-S

you can see what is recordedd by going to the web browser and selecting 'ListTracks'
the Tracks are Date/Time Ordered of the form
YYYY-MM-DD_HH_MM.trk

*** PLEASE DONT HIT DELETE ***
Could you download the track file and send to me as an email ?
I can then work out what was happening, this is really curious.

By the way, you will not be able to download this from your tablet, you will need a MAC or PC, but the mechanism
is the same

Connect your PC/MAC to the WiFi Hotspot PilotAware-xxxxxxxxxx

Open a browser to http://192.168.1.1
go to ListTracks
download the tracks and please send to me.

Many Thx
Lee
Title: Re: Enhancement Requests
Post by: Ian Melville on May 28, 2016, 08:51:10 am
Lee the same question was asked here http://forum.pilotaware.com/index.php/topic,435.0.html. In there I think you misunderstood the question to be about transmission, when it was about how PAW receivers handle a mode S reception and P3i from the same aircraft.
Title: Re: Enhancement Requests
Post by: Admin on May 28, 2016, 10:36:37 am
Lee the same question was asked here http://forum.pilotaware.com/index.php/topic,435.0.html. In there I think you misunderstood the question to be about transmission, when it was about how PAW receivers handle a mode S reception and P3i from the same aircraft.

Hi Ian

Thanks I will go back and check
Effectively the index into the internal database is the ICAO code, each database entry gathers as much information that it can, alt, pos etc. Then when sending to the nav device it decides how to represent the data.
So for example, if it receives Mode-S and P3I, then it has position, ground speed, track, squawk code, ICAO, altitude barometric and gnss. So this is NOT represented as bearingless, because we have appended the P3I data to the Mode-S.
Unless there is a bug here, this should only provide a single representation in the nav device.

Hope that makes sense ?

Thx
Lee
Title: Re: Enhancement Requests
Post by: Admin on May 28, 2016, 11:38:32 am
I am so glad I put that tracking feature in  :D

Thanks for the data, so this is what I have found
I found the following Aircraft

At some point 2 different ICAO codes were using the same FlightID, one Mode-S
and the other P3I/ADS-B, the ICAO codes are 87EA65 and 401FF2
$GPGGA,103857,5113.014,N,00008.432,W,2,05,1.0,57.0,M,-34.0,M,,*49
$PFLAA,3,-387,-302,7,1,87EA65!GBJWZ,0,,0,,8*1D
$PFLAA,3,0,0,5,1,401FF2!GBJWZ,,,,,0*15

I looked on ginfo for these codes, and G-BJWZ is
Hex: 401FF2
Which matches the Mode-S signature, but something with Hex Code 87EA65 is transmitting either P3I or ADS-B

So what is more interesting, I found the following other traces ALSO configured as FlightID GBJWZ, but only one of each, the above were many traces
$PFLAA,3,8,13,10,1,D3D090!GBJWZ,0,,0,,8*1E
$PFLAA,3,-235,-33,-3,1,D300F0!GBJWZ,224,,3,,8*03
$PFLAA,3,-153,503,100,1,DEE488!GBJWZ,81,,22,,8*4B
$PFLAA,3,21,306,-4,1,ED49E0!GBJWZ,75,,20,,8*79

I wonder if someone was trying to configure their PilotAware and inputing different HEX codes ?

Thx
Lee
Title: Re: Enhancement Requests
Post by: Keithvinning on May 28, 2016, 01:48:24 pm
Perhaps a shared PAW being used in many school aircraft. With the reg being changed but the ICAO code not.
Title: Re: Enhancement Requests
Post by: T67M on May 28, 2016, 09:54:13 pm
I've checked with the person who installed the PAW in G-BJWZ and he hadn't realised that the ICAO code needed to be configured as well as the registration, so it was using one of the automatically allocated codes. This has now been corrected... but doesn't explain the other four ICAO codes which Lee spotted in the log file. The aircraft is privately owned, and was in flight, so I'm pretty sure that no-one was configuring its PAW when I made the screen grab!

At least the main concern is understood and resolved.
Title: Re: Enhancement Requests
Post by: Ian Melville on May 28, 2016, 11:44:25 pm
Thanks Lee, I broadly knew how it worked, but thanks for the details.
Title: Re: Enhancement Requests - Voice Alert filtering
Post by: gilest on May 30, 2016, 05:50:15 pm
The voice alerts directly from the PAW are fantastic. A really brilliant addition but can I add my vote to the request to provide some sort of filtering for stationary or ground based devices - ideally selectable in the configuation.

1. If the PAW device is stationary (or very low ground speed <20kts?) can it be set not to announce traffic warnings when receiving traffic from other nearby transmitters. While great for testing, it would be distracting to get traffic alerts from other aircraft, while sitting on the ground not moving. If optional in the configuration then I guess helicopter or other aircraft capable of flying at very low ground speeds pilots could decide to enable?

2. Similarly if the PAW device is stationary should it transmit PAW signals? I assume another PAW device will pick up the stationary transmitter and will just be clutter or may even be seen as a traffic threat to other aircraft flying low overhead. I assume that if stationary the transmitting aircraft is not a threat. Again this could be an optional setting for helicopters or paramotors etc. This is not tested so apologies if this is how it currently works.

3. Some sort of optional filter to switch off audible voice alerts when manoeuvring or close to the ground or on final etc at known airfields. I guess this could be simply unplugging the PAW audio out but would one forget to plug in again!! So maybe an optional filter based around proximity to ones manually inputed home airfield(s). If one inputted the altitude (asl) and GPS location of an airfield then a user could choose to optionally disable voice alerts when say within 1km or 500ft of the airfield(s). Just an idea? :-)

For interest what is the criteria for "same level' when annoucing traffic alerts? Within 1000ft? I was getting "same level 1,2,3 o'clock" warnings from aircraft flying between 500-1000ft all above me when I was on the ground (testing in the garden!). Assume this is ADSB traffic as no PAW transmissions seen and the directional warning I assume means the aircraft must be transmitting GPS location - so not Mode S. Also I assume they were flying above 500ft all as I live in a village and aircraft we are light GA aircraft several km from the nearest airfield! I see there is a setting for Mode-S sensitivity but there does not seem to be something similar for PAW and ADSB traffic.

4. Therefore following on from above what about a setting to adjust the altitude difference that triggers audible traffic warnings for low, high and same level traffic?

Hopefully this is helpful and will provoke some thought and discussion for possible future improvements.
Title: Re: Enhancement Requests
Post by: Admin on May 30, 2016, 07:53:23 pm
Hi Giles,

All good feedback.

Quote
For interest what is the criteria for "same level' when annoucing traffic alerts? Within 1000ft? I was getting "same level 1,2,3 o'clock" warnings from aircraft flying between 500-1000ft all above me when I was on the ground (testing in the garden!)

The voice alerts give either 'above', 'level' or 'below'.
This is not indicating relative height, but the elevation to the horizon.
So if you think about it, an aircraft 10km away at 1000ft above is going to appear as though it is 'level'.

The algorithm calculates if the angle to the horizon is +/- 20 degrees or less, this depicts 'level' and the other cases are either 'above' or 'below'

Thx
Lee
Title: Re: Enhancement Requests
Post by: gilest on May 30, 2016, 10:37:59 pm
Ok. That makes sense. So if +/-20 deg between PAWs then level, so the further apart the greater the height difference to still be level.
Title: Re: Enhancement Requests
Post by: Admin on May 30, 2016, 10:48:20 pm
Ok. That makes sense. So if +/-20 deg between PAWs then level, so the further apart the greater the height difference to still be level.
Thats correct, but ADS-B as well as P3I (PAW)
Thx
Lee
Title: Re: Enhancement Requests
Post by: gilest on May 31, 2016, 10:43:03 am
Thats correct, but ADS-B as well as P3I (PAW)

What about Mode-S. Does that not give a level (but obviously not a direction) too? Also your thoughts on my suggestions to limit voice alerts and P3I transmissions when a PAW is stationary?
Title: Re: Enhancement Requests
Post by: exfirepro on May 31, 2016, 11:49:02 am
Hi Giles,

To keep them simple and 'different' from the 'position based' ADS-B/P3i alerts, Mode S alerts, based predominantly on the strength of the received signal, take the form 'Traffic- Notice', followed by 'Traffic - Alert' and 'Traffic - Danger', if the target continues to get closer. This is accompanied by a visual warning on your nav system screen which includes the target's relative altitude. No positional information is given in the audio warning.

In the case of ADS-B / P3i the warning is 'Traffic - X o'clock (with reference to your track) - 'Level' or 'Above' or 'Below -  (at) Y kilometres.  it is not a 'Level' as in 'a flying height'. Again the relative altitude of the target is displayed next to the (moving) aircraft symbol on your nav system display.

You have obviously read the earlier posts in this thread about audio alerts on the ground, which we are trying to decide the best way to deal with, without simply 'turning them off' and letting pilots taxi out into for example the path of an un-noticed and perhaps non-radio aircraft on final. (Preferably without having to manually operate a screen based on/off switch when your attention should be elsewhere). Lee has already incorporated user selectable filters which control the Mode S alerts and updated settings are currently under test which should improve things. In a similar vein, the P3i transmitter can be turned off by selecting 'Base Station' mode in [Config], (edit: I have just been told that I was misinformed - that this is NOT correct. At the present time, selecting 'Base Station' DOES NOT turn off the P3i transmitter)...but this is not something we would encourage in active aircraft anyway as the inbounds may still benefit from a reminder that you are there on the taxi way or threshold.

Unfortunately, the simple sounding 'solutions' all have their flaws, but Lee is working on it and your contribution to the discussion is very much appreciated.

Regards

Peter

Title: Re: Enhancement Requests - ground traffic
Post by: gilest on June 02, 2016, 10:30:20 am
Hi Peter. Thanks. That is really helpful to know how the Audio Alerts work. I had assumed that mode S used the relative altitude to calculate a level, above, below warning. Is that something in the pipeline?

audio alerts on the ground, which we are trying to decide the best way to deal with, without simply 'turning them off' and letting pilots taxi out into for example the path of an un-noticed and perhaps non-radio aircraft on final.

From my personal prospective (and as an active pilot) by far the primary purpose of PAW is to provide a "see and be seen" tool while flying cross country - where a combination of high closing speeds, poor aircraft visibility and other cockpit distractions create a potential collision risk. In my personal opinion "electronic" ground based traffic warnings are not so necessary, as other aircraft are much easier to be seen and pilots more attuned to the risks during taxi, take off and landing phases. In my opinion audible warnings may even contribute negatively due to the distraction, complacency and the tendency to manually switch off the PAW. However I realise that is my opinion and may not be held by others - however a configurable setting would allow individual choice.

Quote
in active aircraft as the inbounds may still benefit from a reminder that you are there on the taxi way or threshold.

The same comments as above. In this critical phase I want to be focused on the landing area and circuit traffic not to be distracted by someone inbound 10km out transmitting mode S! Maybe a simple audio mute is the solution.

Anyway it is great to be able to enter the debate and I really applaud the work you are all doing in this critical safety area.
Title: Re: Enhancement Requests
Post by: Admin on June 02, 2016, 11:34:27 am
Thanks for all the input, should probably moved the Audio/Mode-S/ADS-B/P3I onto a separate thread, but this is what I think we are coming to ....

Firstly the audio messages of 'above/level/below' indicate an angle to the horizon of
above = greater than +20degrees
level = between +20 and -20 degrees
below = less than -20 degrees

This can only be calculated with ADS-B/P3I - simple trigonometry, you need a distance and relative altitude.

For Mode-S, all you have is relative altitude, but no distance, therefore it is impossible to calculate the angle to the horizon, consider the angle to the horizon of +500ft at a distance of 100m and 1000m - completely different.
The altitude difference could be added for Mode-S altitude if it is valuable, but this would be of the form
"Notice, traffic, 500ft above", thus not indicating elevation to the horizon
Phew!

I think I am hearing two requirements for muting the audio :-

1. A manual mute: I like this idea with a configurable timeout, in other words mute for X minutes, then automatically re-enable, or mute permanantly (or pull out the plug!)
This could solve the issue of Taxi, Take off & Landing

2. Ground speed filter: if my speed is less than X Kns, then mute the audio.
This can only address the issue of Taxi & Take-off

These could both be config options, and in the case of Helicoptor, Paraglider, Hanglider, the speed option may not be a good choice.

Thx
Lee

Title: Re: Enhancement Requests - ground traffic
Post by: gilest on June 02, 2016, 12:51:38 pm
Lee. Thanks for quick response.

For Mode-S, all you have is relative altitude, but no distance, therefore it is impossible to calculate the angle to the horizon, consider the angle to the horizon of +500ft at a distance of 100m and 1000m - completely different.
The altitude difference could be added for Mode-S altitude if it is valuable, but this would be of the form
"Notice, traffic, 500ft above", thus not indicating elevation to the horizon

I think this is a great idea. Giving height adds a huge amount to the message. Roughly where to look vertically but more importantly with the decision whether to climb or descend.

Thinking about ADS-B/P3I alerts the perfect solution would be to announce relative height if "level" and within short range ie in danger of collision - then even if not visual one can decide whether to climb or descend. Maybe getting too complex but think it would be very useful safety aid.

Quote
1. A manual mute: I like this idea with a configurable timeout, in other words mute for X minutes, then automatically re-enable, or mute permanently (or pull out the plug!) This could solve the issue of Taxi, Take off & Landing

My only comment is if a software mute how this would be accessed? Going into the configuration of the PAW in-flight is tricky. I feel a hardware mute is best, but implementing a time out would be difficult! Maybe just pulling the plug is simplest/best solution here! ;-)

Quote
2. Ground speed filter: if my speed is less than X Kns, then mute the audio.

Personally I really like this idea and I think this should also apply to P3I transmissions (both optionally from config).

Interestingly (as I am sure you know) the procedure for Mode S transponders is to leave on standby mode until entering the runway threshold or in the case of aircraft that have a sensor on the undercarriage until after take-off and similarly on landing to switch back to standby after vacating the runway or having touched down. It seems to me that this procedure is equally relevant to PAW but due to the lack of easily accessible controls on the PAW device that a more intelligent process is needed ie the speed filter.

Quote
These could both be config options, and in the case of Helicoptor, Paraglider, Hanglider, the speed option may not be a good choice.

Absolutely

Giles
Title: Re: Enhancement Requests
Post by: GrahamBaker on June 08, 2016, 06:51:20 am
I'd like to be able to filter out audio warnings for traffic greater than a certain distance away. Hearing 'Traffic noticed' every time an airliner gets airborne 75 miles away is a bit pointless, frankly.

BTW Mode S Ground Mode and Standby are not the same thing, AFAIUI.  Standby means your transponder effectively is switched off, but powered up. Ground Mode means it still responds, but with a flag set (I think).
Title: Re: Enhancement Requests
Post by: exfirepro on June 08, 2016, 08:36:58 am
I'd like to be able to filter out audio warnings for traffic greater than a certain distance away. Hearing 'Traffic noticed' every time an airliner gets airborne 75 miles away is a bit pointless, frankly.

Graham,

Because Mode S (as with all transponders) provides no positional information we can't filter by distance. Instead we have provided filters in (Configure) (Mode S Detect) to allow you to filter high power CAT signals by setting a shorter detection range. Unfortunately this means that lower powered (GA) ones get closer in before you know about them, so we had to do a fair bit of juggling to get the trigger levels correct (and fine tuning of these will remain ongoing).

The first thing you need to do is make sure you are running software version (21060530), which contains the most up to date trigger settings - earlier releases had much coarser filters. Personally as I often fly very close to Edinburgh Airport, I use the 'Short Range'  filter, but set to Medium Range if I am flying cross country, but this will depend on your own circumstances.

Quote
BTW Mode S Ground Mode and Standby are not the same thing, AFAIUI.  Standby means your transponder effectively is switched off, but powered up. Ground Mode means it still responds, but with a flag set (I think).

Correct, but during testing we realised that CAT traffic on the ground (so presumably in Ground Mode) transmits very strong Mode S responses to the airport ground radar, which were reporting as 'Traffic Danger' alerts at up to 2 miles - hence the 'Ultra Short Range' setting, if you normally get that close and CAT is your main risk.

Hope this helps

Regards

Peter
Title: Re: Enhancement Requests
Post by: Admin on June 08, 2016, 09:49:34 am
Hi Graham,

Just to follow up on Peters posting ....

Firstly I need to invent some terminology here, so here goes, we have two types of air traffic:-

precise traffic
Traffic which includes full location details in addition to information regarding speed, track and identification.
This would consist of ADS-B & P3I traffic returns

imprecise traffic
Traffic which includes partial or missing location details consists of Mode-A, Mode-C and Mode-S transponder returns. To be even more detailed, we have no accurate method of distinguishing between a Mode-A and Mode-C return, because to the passive receiver, they appear exactly the same, but their encoded meaning is significantly different, namely squawk or altitude.
(for more information try googling Transponder FRUIT)

For precise traffic, we have everything we need in order to accurately and definitively provide audio and visual prompts to the user, and we can control when those audio prompts occur. For example the audio alerts occur by intrusion into 3 zones
10KM +/-2000ft
5KM +/-1000ft
3KM +/- 500ft

So as you can see, there are no precise traffic warnings for traffic at 75 miles  :o

For impreceise traffic warnings, this is more art than science, and this is something Peter and Alan have been experimenting and advising to come up with the most suitable settings (as detailed in his previous posting)

The settings for imprecise traffic warnings are under user control, so please take advantage of these settings including the sensitivity and the separation parameters, for example the 30,000ft separation is only useful for testing purposes, a more realistic setting I would say is 1000 ft

Thx
Lee
Title: Re: Enhancement Requests
Post by: Paul_Sengupta on June 08, 2016, 04:07:15 pm
One enhancement request which has been mentioned is to be able to use a bluetooth dongle in one of the USB ports for audio out. Any chance?
Title: Re: Enhancement Requests
Post by: Admin on June 08, 2016, 04:14:57 pm
One enhancement request which has been mentioned is to be able to use a bluetooth dongle in one of the USB ports for audio out. Any chance?

I did look into this when implementing the audio, and unfortunately it did not 'drop out in the wash', so would need a serious amount of investigation.

Thx
Lee
Title: Re: Enhancement Requests
Post by: GrahamBaker on June 08, 2016, 04:43:10 pm
For precise traffic, we have everything we need in order to accurately and definitively provide audio and visual prompts to the user, and we can control when those audio prompts occur. For example the audio alerts occur by intrusion into 3 zones
10KM +/-2000ft
5KM +/-1000ft
3KM +/- 500ft

So as you can see, there are no precise traffic warnings for traffic at 75 miles  :o
Hi Lee,

Thanks for the clarification; I'll need to check my configuration again, (box at home, I'm 200 miles away until the weekend)  but I'm pretty sure I had the filters closed right down, and yet naggy Nora was still chirruping at me!
Title: Re: Enhancement Requests
Post by: Keithvinning on June 08, 2016, 06:52:26 pm
Oops
Definitely not naggy Nora but lovely Demi-Lee

Keith
Title: Re: Enhancement Requests
Post by: exfirepro on June 08, 2016, 10:13:18 pm
Lee's daughter, Graham!!!!

Guess that's you off the Christmas Card List  :-[

Peter
Title: Re: Enhancement Requests
Post by: Admin on June 08, 2016, 10:50:17 pm
Hey Graham, she will be working the stand at the LAA Rally, if you swing by, you might not want to use your real name ;D

Thx
Lee
Title: Re: Enhancement Requests
Post by: GrahamBaker on June 09, 2016, 01:02:50 pm
Whoops.  :-[ :)
Title: Re: Enhancement Requests
Post by: gvpsj on June 09, 2016, 04:34:23 pm
It is so nice to have such a pleasant voice talking to ME whilst I fiddle and work away in the hanger ;-)))
Title: Re: Enhancement Requests
Post by: exfirepro on June 09, 2016, 04:54:56 pm
It is so nice to have such a pleasant voice talking to ME whilst I fiddle and work away in the hanger ;-)))

John, what a Crawler!! ;D

It's Graham that needs to do that  :)
Title: Re: Enhancement Requests
Post by: Paul_Sengupta on June 10, 2016, 08:54:42 am
How easy would it be on the home page (192.168.1.1/index.cgi) to include, under both ADS-B and TRX, the total current number of each received?
Title: Re: Enhancement Requests
Post by: Admin on June 10, 2016, 10:56:15 am
How easy would it be on the home page (192.168.1.1/index.cgi) to include, under both ADS-B and TRX, the total current number of each received?

Hi Paul,

this is done already, the format is
    ADS-B (DVB-T)    Connected Msgs=N_total(+N_inc)

N_total : total received ADS-B messages
N_inc : messages received in last 5 seconds

    TRX (RXTX)    Connected TX=TX_total RX=RX_total CRCFAIL=0

TX_total : total transmitted P3I messages
RX_total : total received P3I messages

Thx
Lee
Title: Re: Enhancement Requests
Post by: Paul_Sengupta on June 10, 2016, 11:58:36 am
Oh, sorry, I didn't word it very well, I meant the current number of aircraft visible in each field!
Title: Re: Enhancement Requests
Post by: exfirepro on June 10, 2016, 12:37:27 pm
Oh, sorry, I didn't word it very well, I meant the current number of aircraft visible in each field!

Paul,

Are you not going a bit deep here. Bearing in mind we should be looking at the Nav Display when flying, the current Home Page to my mind provides exactly the information required to confirm that your PAW is operating properly, so what is it you are trying to achieve? Presumably changing to numbers of aircraft rather than simply numbers of received transmissions will involve a fair bit of work for Lee and I can't see what significant gain we would get from this. Your request for the GPS info on the other thread however, I can fully appreciate.

Not being negative, just confused.

Regards

Peter

Title: Re: Enhancement Requests
Post by: Paul_Sengupta on June 10, 2016, 12:54:32 pm
It's for information, to see how many P3i aircraft there are for instance, and as a quick tally for ADS-B/Mode S. Not a change, an add. I don't know if there is a current count of aircraft within the software - if there is, it should be very easy to display it. It wouldn't be used while trying to fly/maintain separation, it's an information field, like the other information fields on the homepage.
Title: Re: Enhancement Requests
Post by: exfirepro on June 10, 2016, 01:35:32 pm
Thanks Paul,

I see what you are trying to do. I knew it would be important - just wondered how! I certainly wouldn't want to 'lose' the raw counts as they confirm that all is OK (or otherwise) even if the 'aircraft' never make it to the 'Nav' screen.

Regards

Peter
Title: Re: Enhancement Requests
Post by: Admin on June 10, 2016, 01:43:39 pm
Actuall there is already a count, which is on the traffic page, but it is a total count of

ADS-B
P3I
MODE-S

The Count is at the top in HEX(<count>)

Are you saying you want a breakdown ?
Title: Re: Enhancement Requests
Post by: Paul_Sengupta on June 10, 2016, 02:13:36 pm
Yeah, just displayed next to the other information in the ADS-B or TRX fields on the home page would be nice. As long as it's an easy job!  :)
Title: Re: Enhancement Requests - FR24
Post by: gilest on June 10, 2016, 04:16:47 pm
Hi Lee

Just a thought. FR24 displays FLARM and it also displays triangulated (MLAT) locations for mode S transmitting aircraft (above about 2500ft). Has anyone spoken to FR24 to see if you could somehow receive their stream while airborne to display FLARM and Mode S positions? And maybe they might be interested in including an P3I receiver in their devices to display PAW equipped aircraft - a kind of quid pro quo for using their stream?

As I say probably a dead end and not feasible - but a thought.
Title: Re: Enhancement Requests - FR24
Post by: exfirepro on June 10, 2016, 06:05:33 pm
Hi Lee

Just a thought. FR24 displays FLARM and it also displays triangulated (MLAT) locations for mode S transmitting aircraft (above about 2500ft). Has anyone spoken to FR24 to see if you could somehow receive their stream while airborne to display FLARM and Mode S positions? And maybe they might be interested in including an P3I receiver in their devices to display PAW equipped aircraft - a kind of quid pro quo for using their stream?

As I say probably a dead end and not feasible - but a thought.

Giles,

AFAIK FR24 get their FLARM feed from the OGN (Open Glider Network), which like FR24 comprises a network of FLARM receiving stations across the country, all feeding data in to OGN / FR24's servers - which then process all this information and disseminate it back out over the internet as the FR24 /OGN displays we know and love (did I say that!). It is this multiplicity of receiving stations that allows them to 'estimate' the position of Mode S aircraft through MLAT. As I have already stated elsewhere today, this all means that the information is not LIVE due to the inevitable processing and transmission delays. It is also, certainly in the case of Mode S, not ACCURATE - I can vouch for this having seen several Mode S equipped airliners land safely at Edinburgh and not in the car park almost a mile away where I was parked and where FR24 showed them landing. So I certainly wouldn't trust it for collision avoidance or Pilot Awareness.

Let's not even start talking about trying to receive FR24 in flight when your tablet is already connected to your PAW.

Nice thought, but as you say not really practicable. Keep the ideas coming though.

Regards

Peter

Title: Re: Enhancement Requests
Post by: SteveN on June 13, 2016, 05:15:42 pm
A little update on the OGN -> FR24 feed. People may have noticed there are recently a lot less gliders and other FLARM traffic showing. What happened is FLARM effectively forced OGN to adopt an opt in process for display on OGN/FR24.   SO unless you are aware of the OGN process your FLARM will not be displayed. The FLARM argument was privacy. The fact that there is no opt in or out process for ADS-B doesn't seem to have deterred them.
Title: Re: Enhancement Requests
Post by: exfirepro on June 13, 2016, 09:51:51 pm
Hi Steve,

Thanks for the update. Knew it was something along those lines but couldn't remember the detail.

I am perfectly happy to use FR24/OGN to track down unidentified contacts on the ground, but certainly not something I would want to rely on for in-flight awareness.

Regards

Peter
Title: Re: Enhancement Requests - Alerts selectable units
Post by: Ian Melville on June 16, 2016, 06:45:13 pm
Could we have selectable miles/km please
Title: Re: Enhancement Requests - Alerts selectable units
Post by: Admin on June 16, 2016, 07:03:40 pm
Could we have selectable miles/km please

Are you referring to the Audio Alerts, or units in the traffic table ?
Also statute or nautical ?

And if we were to change to the different units, would you want the range warnings rounded up ?

For example the range warnings in km are
3, 5, 10

so in NM that would probably be
2, 3, 6

thx
Lee
Title: Re: Enhancement Requests
Post by: Ian Melville on June 16, 2016, 08:19:48 pm
Hi Lee, Audio Alerts. For nautical miles, as used in UK aviation.

I guess rounding down would be safest, but up/down nearest mile most accurate?

Cheers
Ian
Title: Re: Enhancement Requests
Post by: Paul_Sengupta on June 26, 2016, 10:58:24 pm
I have an enhancement request. A friend has just said that with a couple of aircraft at the same level (Mode S), they were showing 200ft below.

I suggested that this may be due to the static pressure in the cockpit being lower than that outside. I suggested that he request here, but I'm doing it for him, that you perhaps have a setting on the web page to introduce an offset to compensate for this. I know this issue was mentioned on the forum when the barometric sensor was first experimented with, but I don't think it's come up since.

Am I right in thinking that PAW to Mode S is done on Baro, but PAW to PAW is done on GPS altitude? Or are they both done on Baro?
Title: Re: Enhancement Requests
Post by: Paul_Sengupta on June 28, 2016, 03:10:49 pm
The other thing which can be done is to read your own altitude from your own transponder over the air.

If this offset is being coded in, perhaps the offset could be greyed out with a tickbox which says, "Read own Mode S transponder".

Could be awkward if your transponder isn't transmitting (ground?) though...
Title: Re: Enhancement Requests
Post by: Admin on June 28, 2016, 03:30:50 pm
Am I right in thinking that PAW to Mode S is done on Baro, but PAW to PAW is done on GPS altitude? Or are they both done on Baro?

Hi Paul
Almost, ADS-B and Mode-S are compared using the Baro, and PAW to PAW using GPS
did you see my response on flyer forum ?

Thx
Lee
Title: Re: Enhancement Requests
Post by: dougblair on June 28, 2016, 03:51:39 pm
Audio volume.  Will there be an update soon to make the audio volume stay at the required level after a re set ?  Only asking to prevent me installing the little £3 audio board from e bay if I do not need it.
Title: Re: Enhancement Requests
Post by: Admin on June 28, 2016, 04:08:25 pm
Audio volume.  Will there be an update soon to make the audio volume stay at the required level after a re set ?  Only asking to prevent me installing the little £3 audio board from e bay if I do not need it.

I will make my best endeavours to get this in the next release  :)
Thx
Lee
Title: Re: Enhancement Requests
Post by: Paul_Sengupta on June 28, 2016, 04:44:26 pm
Cheers!

did you see my response on flyer forum ?

I have now, thanks.
Title: Re: Enhancement Requests
Post by: Shortwing on June 30, 2016, 11:21:45 am
In one of the very early releases there was a map showing traffic within the admin panel 192.168.1.1 - does this still exist?  I've lost the link if it does.
Title: Re: Enhancement Requests
Post by: Richard on June 30, 2016, 12:06:17 pm
Shortwing
    You are correct the traffic is under "traffic" when you log into 192.168.1.1 if you can not see it. What version are you using?
Title: Update Option
Post by: homeuser on July 02, 2016, 07:56:39 pm
It would be great to be able to update the software over WLAN/WiFi. I have a Semi-fixed installation on our Mooney and there it is very hard at the hangar to make internet available over Ethernet. Easily available is a WiFi Hotspot via a mobile phone...

But I understand there is no such way (yet?)

Thanks!
Title: Re: Enhancement Requests
Post by: homeuser on July 02, 2016, 08:05:22 pm
Another Alternative would be to use the remaining USB Port to temporarely put a USB-Stick with the new release in...

Then we could easily download at home, take the new release to the airport and just let it update...

Anything taking the situation at a hangar into account would help much!
Title: Re: Enhancement Requests
Post by: JCurtis on July 02, 2016, 08:10:08 pm
Another Alternative would be to use the remaining USB Port to temporarely put a USB-Stick with the new release in...

Then we could easily download at home, take the new release to the airport and just let it update...

Anything taking the situation at a hangar into account would help much!

IMHO this is probably the most universal method.  If it could be combined with the ability to download the track/log files to the USB stick too then the likes of a iPad is all you need to do everything in/near the aircraft via the web interface on PilotAware.
Title: Re: Update Option
Post by: exfirepro on July 02, 2016, 11:34:35 pm
It would be great to be able to update the software over WLAN/WiFi. I have a Semi-fixed installation on our Mooney and there it is very hard at the hangar to make internet available over Ethernet. Easily available is a WiFi Hotspot via a mobile phone...

But I understand there is no such way (yet?)

Thanks!

Hi homeuser,

I fully sympathise as I also have my main unit semi-fitted in my flexwing, but unfortunately Lee has previously advised that this is not possible as the PAW wifi is configured as a server and in order to connect to download from another server it would need to act as a client. See this link:

http://forum.pilotaware.com/index.php/topic,4.msg4621.html#msg4621

Richard and I, however worked out a method using a 'spare' PAW or simply a spare raspberry pi - most of us now have spare PiB+'s from the early Beta trials - as a surrogate to allow you to take the card from your fitted PAW home or to a point where you can connect to your club router via ethernet and update your main cards's software via the surrogate. Any spare Pi will work for this - it does not need a bridge, GPS or whatever fitted, though a wifi dongle helps you to check that the download to the card has been successful.

See this link:

http://forum.pilotaware.com/index.php/topic,465.msg5924.html#msg5924

...and the following reply number 18 for how to do this.

Hope this helps

Regards

Peter

Title: Re: Enhancement Requests
Post by: homeuser on July 03, 2016, 11:21:56 am
Peter,

thanks for this! Not a bad idea - I guess I could also work with two SD Cards, right? The airfield is about an hour drive and at the airfield is no option to really run the second Pi. Furthermore will I not have an issue since the other Pi will habe a different MAC address?

I´d still prefer the USB-Stick method since it saves me getting another Pi and I could still change the USB-Stick by simply taking a notebook to the airfield...

homeuser
Title: Re: Enhancement Requests
Post by: exfirepro on July 03, 2016, 11:32:35 am
Morning homeuser,

Yes, I totally see where you are coming from. I'm sure Lee will come on and let us know whether / why not this is feasible in due course. Just wanted to let you know the alternative, which we know does work.

Yes you can use two cards, but you need to do a 'full overwrite with size adjustment on' SDFormat as per page 34 of the Pilotaware Operating Manual here http://www.pilotawarehardware.com/dl/PAWOperationManual.pdf the first time you use a new card.

The great benefit of the auto-update is that once each card has your Mac and license details on it, they stay there and you don't need to spend ages re-formatting cards and re-entering details each time like we used to. Definitely a big step forward.

Happy and safe flying

Regards

Peter
Title: Re: Enhancement Requests
Post by: roweda on July 04, 2016, 09:35:00 pm
Would it be possible to have an option to change the format of the distance on the Traffic screen? It currently defaults to KM when everywhere else the majority of us talk in nautical miles. An option for: nm, statute miles and km would be a nice additional feature.

Dave
Title: Re: Enhancement Requests
Post by: Vic on July 11, 2016, 09:52:09 am
Just a thought to throw the idea into the mixer..

Making use of the Infrared receiver on the SDR dongle. ..volume changes or anything else?


http://www.rtl-sdr.com/making-use-of-the-infrared-led-on-rtl-sdr-dongles/

My SDR dongle came with a small credit card IR remote..
Title: Re: Enhancement Requests
Post by: homeuser on July 21, 2016, 03:26:50 pm
Coming back to the update aspect, one additional thought (I still did not manage to download the new release due to poor network coverage at the airport :-[ and I do not want to take the PAW out frequently neither do I have a second Pi):

Assuming that the download and update process works in a way that the update-procedure first downloads the update file into a specific folder in the filesystem and that afterwards the software checks whether there is a file and if so starts the update, wouldn't it be possible to manually put the file into that folder and then click "update"?

Downloading at home, taking a notebook to the airport, putting the file into the respective folder using the notebook and then let the PAW do the update would work well for me...

Should that work, could you please indicate which folder in the filesystem to use?
Title: Re: Enhancement Requests
Post by: Admin on July 21, 2016, 04:08:39 pm
Unfortunately you cannot see that filesystem unless you mounted the disk in another linux system.
If you simply inserted the disk into your laptop - you only see the first partition I think

However, there may be a way to leave some space on the first partition and copy it out, once
the system is up and running.

This does not fit the general case because some people are requesting NOT to have to remove the MicroSD Card
Title: Re: Enhancement Requests
Post by: homeuser on July 21, 2016, 04:32:57 pm
I understand this and I would also like the USB-Stick option discussed above better but as long as this is not realized, I´m searching for alternative approaches...

Accessing the Linux Filesystem on the Notebook should not be an issue with Ext3/Ext4 drivers for windows or am I missing something? I do access Linux Filesystems (such as Enigma) that way...

The question is would the WebIF even continue to the point where it checks whether there is an update file in the destination directory without having detected internet-access before?
Title: Re: Enhancement Requests
Post by: Admin on July 24, 2016, 12:58:31 pm
I understand this and I would also like the USB-Stick option discussed above better but as long as this is not realized, I´m searching for alternative approaches...

I have a prototype working which will mount the USB stick and look for a specific file in a specfic location,
This will then appear as one of the install options in the install menu
So I think I can get this in for the next release

so in the root Directory you will place the update file. something like
PilotAware.update.gpg

Thx
Lee
Title: Re: Enhancement Requests
Post by: homeuser on July 24, 2016, 09:52:13 pm
That would be PERFECT!

And I'll also be an early adopter of FLARM - we have heavy glider activity in the north of our airfield and that is basically where I'm usually coming from... It has been a few times that I saw a piece of plastic with short notice... On a decent with 175kts ground it would be great to know where they are, a bit earlier...

Any chance to get Flarm-mouses cheaper by ordering a bigger quantity?
Title: Re: Enhancement Requests
Post by: rg on July 30, 2016, 09:36:57 am
Aircraft profiles saved.  When jumping into different aircraft it would be nice to be able to select the reg from a drop down and have the hex code load up.
Title: Re: Enhancement Requests
Post by: brinzlee on July 30, 2016, 10:41:49 am
That would be very handy.....Great idea !!
Title: Re: Enhancement Requests
Post by: Ian Melville on August 01, 2016, 08:07:26 pm
Not that we are going to get updates through a USB pen Drive, would it be possible for the log files to be copied to a USB pen drive as well. Otherwise those with a plumbed in system will not have easy access to the logs.

Note: If you can connect you phone/tablet to 3G as well as PAW WiFi, then you can save them to Dropbox. Not perfect but a workaround.
Title: Re: Enhancement Requests
Post by: exfirepro on August 01, 2016, 10:44:35 pm
I just take my laptop down to the airfield, log onto my PAW WiFi and download the track logs straight onto the laptop. Works for me.

Regards

Peter
Title: Re: Enhancement Requests
Post by: Ian Melville on August 02, 2016, 06:00:20 am
You could. I take my PAW home, so no need for this download at the field, but I don't own a laptop and I think it's wrong to assume everyone does.
Title: Re: Enhancement Requests
Post by: exfirepro on August 02, 2016, 09:36:23 am
Hi Ian,

Yes, I totally agree. A USB 'option' would be good for me too - I just have a bit of a hangup because I used to have PowerFl*rm Core, which relies on a usb stick for configuration and updates. Mine wouldn't read from or write to any of my sticks, yet they kept insisting the problem was with my sticks (what?...all of them...?), not their unit - which I disproved by using my sticks on someone else's unit - so back it went for a refund. With the Fl*rm, there was no way to see what was going on inside except through the USB port. At least with the PAW you can look at the logging and track files - provided you can get them off the Pi of course.

As you say, Lee is looking at updates via USB, so I'm sure he will consider this at the same time.

Regards

Peter
Title: Re: Enhancement Requests
Post by: Admin on August 02, 2016, 10:05:41 am
Now that I have the data transfers going from USB->PilotAware.
This is a reasonable extension to the functionality.

I am thinking of maybe a 'Sync ' capability, which will simply synchronize the files on
PilotAware - to the memory stick.

I think at the moment you get folder in the root of your USB containing the update file
/PilotAware/Pilotaware.pgp

So after a 'Sync' operation, I would expect to see something like
/PilotAware/Tracks/2016-03-31_07-20.trk
/PilotAware/Tracks/2016-03-31_10-15.trk

etc
Title: Re: Enhancement Requests
Post by: exfirepro on August 02, 2016, 10:39:25 am
Sounds good to me Lee. So each time you plug in your (dedicated to PAW - keeps it clean!) USB stick, it woud (automatically??) check for updates and also download any .trk files not already on the stick - am I right?

If so this would be great!!

Peter
Title: Re: Enhancement Requests
Post by: Admin on August 02, 2016, 10:55:47 am
Hi Peter,

I was thinking of adding a 'Sync' button possibly on the Tracks page, rather than automatic
- do you think the automatic is better ?

Thx
Lee
Title: Re: Enhancement Requests
Post by: exfirepro on August 02, 2016, 11:36:50 am
Lee,

'Sync' button might be better assuming there would be some indication when sync has completed. Automatic sync leaves the user in doubt as to what is happening and whether the sync is finished yet or not and might result in the stick being pulled out before the sync is completed. Otherwise, I have no particular preference. Which is easier?

Peter
Title: Re: Enhancement Requests
Post by: Ian Melville on August 04, 2016, 05:31:36 am
Thanks Lee,
I think a sync button may be best, as per Peters comments.
Cheers
Ian
Title: Re: Enhancement Requests
Post by: tj80 on August 05, 2016, 04:37:08 pm
Sorry if these have been posted already somewhere in the preceding pages - but if not here are some suggestions based on my first flight with PAW:

- Fix the bug which resets the audio volume after reboot!
- Display audio volume setting in the config page - e.g. if there are 10 levels, display the number of the current setting.  At the moment you have to change the volume with the +/- button and guess if you're on max!
- Change distances from KM to NM - it seems strangely unintuitive to be using different units for traffic distance compared to everything else!
- Although this doesn't affect me yet as the aircraft I fly are only Mode-C, if flying multiple aircraft (e.g. club rental) it would be a pain to have to enter the transponder ID each time.  Could we have some presets built into the config page?  We could then pre-configure the transponder code for all the aircraft we commonly fly (e.g. all the club fleet) and just select from a drop down list of registrations - e.g. G-ABCD = 0x123456
- Finally, another vote for Mode C detection which I know is in the works!  :)

Many thanks,
Tim
Title: Re: Enhancement Requests
Post by: Pwwuk on January 05, 2017, 03:44:06 am
Can I also vote for Audio Alerts via Bluetooth   
Title: Re: Enhancement Requests
Post by: AlanG on January 05, 2017, 08:55:56 pm
Hi Pwwuk

Audio alerts via bluetooth are currently available using a small add-on device.
See this forum link. http://forum.pilotaware.com/index.php/topic,516.msg9100.html#msg9100 (http://forum.pilotaware.com/index.php/topic,516.msg9100.html#msg9100)

the link to the item is here. http://www.ebay.co.uk/itm/2-in-1-Wireless-Bluetooth-Audio-Music-Transmitter-Receiver-Adapter-Two-Way-A2DP-/272048764056?hash=item3f575eb498 (http://www.ebay.co.uk/itm/2-in-1-Wireless-Bluetooth-Audio-Music-Transmitter-Receiver-Adapter-Two-Way-A2DP-/272048764056?hash=item3f575eb498)

Alan
Title: Re: Enhancement Requests
Post by: mo0g on March 29, 2017, 09:40:54 am
Not sure if this has been mentioned in the previous pages, or is feasible, but aside from when testing, or just being interested watching the traffic, would there be any way to exclude commercial traffic?  There is no reason any of us needing to be warned about airliners operating in and out of our major airports.

This may be something that needs to be worked on, on the nav app side, where it may be easier to filter out traffic within the major airspace, or be able to use more complex algorithms.
Title: Re: Enhancement Requests
Post by: exfirepro on March 29, 2017, 11:23:54 am
Not sure if this has been mentioned in the previous pages, or is feasible, but aside from when testing, or just being interested watching the traffic, would there be any way to exclude commercial traffic?  There is no reason any of us needing to be warned about airliners operating in and out of our major airports.

Hi Mark,

Sorry but I have to disagree. We operate outside but very close to Edinburgh CTA (as do many other airfields - different CTAs obviously), and have regular overflights by commercial aircraft descending into the approach pattern. Areas such as around Aberdeen also have literally hundreds of low level flights by commercial helicopters and light fixed wing aircraft, so excluding commercial traffic would be difficult to achieve and potentially dangerous.

If you don't want to see high altitude contacts, you should be able to filter them out yourself using the altitude filters in your nav system, but I would certainly be dead against deliberately excluding commercial traffic.

Regards

Peter
Title: Re: Enhancement Requests
Post by: brinzlee on March 29, 2017, 11:29:37 am
I agree with Peter....That would be a retrograde step, more and more GA are finding ways to enable ADSB with their own transponders and PilotAware. As Peter suggested if their are too many commercial flights on your navigational software decrease the height filter.....I don't think many of the airliners at 30,000 feet are considered much of a threat at the moment !!
Title: Re: Enhancement Requests
Post by: mo0g on March 29, 2017, 12:40:06 pm
I operate between Heathrow and Gatwick, so I know all about low level commercial aircraft, however these operate within strictly controlled zones/cta/tmas etc, and GA should be never busting that airspace, and if we did ATC would be routing traffic away from us.  When we do get permission to fly in/through those zones it is via agreed limits/routes which do not impact on their traffic.

Any airfield within or under CTAs will also have set limits on their operations so conflicting with commercial traffic is nigh on impossible, and again, if you did somehow fly outside those limits and come into potential conflict, you wont need PAW to help you avoid that traffic, ATC will be doing that before you even know you have busted airspace.

Unless I am missing something?

Or lets put it another way, PAW is for GA to avoid conflicts with other GA traffic, not airliners, right?

Now, I accept that this may not be possible due to PAW simply detecting ADSB and not being able to determine whether that is a 787 or just a spamcan with ADSB enabled, but that is a different issue from GA traffic NEEDING to be warned about airliners operating in and out of our major airports.  It is also something which Nav software can potentially do, based on track (into a major airport for example).

There may be other scenarios where a PAW user is in danger of conflicting with commercial traffic too, which I havent thought of, but even so, an option to turn off/on the traffic, if it were possible, would be an "enhancement" from my perspective.
Title: Re: Enhancement Requests
Post by: GrahamBaker on March 29, 2017, 02:53:30 pm
There are commercial movements outside of CAS in a number of locations around the UK. Also, there places abroad where Class E is prevalent and you can find IFR and uncontrolled VFR traffic mixing it separated only by 500'.

In all these circumstances, filtering out of 'commercial' traffic would be unwise.

Another factor to be considered is that of wake turbulence. There are plenty of videos on YouTube and the like of serious upsets to GA aircraft caused by proximity to CAT. If operating under a CTA or TCA where there are movements of large aircraft, I think I'd rather know where they are than pretend they didn't exist.

Title: Re: Enhancement Requests
Post by: T67M on March 29, 2017, 06:19:07 pm
I regularly fly my SEP through Gatwick and Stansted airspace. Simply using the altitude filters to remove stuff well above me means than I can use PAW to watch the traffic on final and be ready for the crossing clearance because I have the "big picture". The one annoyance is that the audio alerts keep warning me about traffic 10km away and there is no distance filter. If it's more than 3km away, I don't want an audio alert - it will never be an immediate safety concern to me, and unless it's a 747, I won't even be able to see it!
Title: Re: Enhancement Requests
Post by: mo0g on March 29, 2017, 06:24:53 pm
I regularly fly my SEP through Gatwick and Stansted airspace. Simply using the altitude filters to remove stuff well above me means than I can use PAW to watch the traffic on final and be ready for the crossing clearance because I have the "big picture". The one annoyance is that the audio alerts keep warning me about traffic 10km away and there is no distance filter. If it's more than 3km away, I don't want an audio alert - it will never be an immediate safety concern to me, and unless it's a 747, I won't even be able to see it!

I havent tried using the audio alerts in PAW yet, and it is precisely the commercial traffic into and out of Heathrow and Gatwick which would stop me using it.  If I were getting constant audio alerts they would lose their impact, or I would stop using them, which again makes the option of somehow filtering out commercial traffic an "enhancement" for me.

My only concern is to see, and be seen by, other GA bimbling around.  I assume your crossing clearances at Gatwick and Stanstead factor in any wake turbulence potential?  I can possibly see how using PAW for commercial traffic may be useful in that very very limited scenario, but again its not the raison d'etre for PAW afaik.
Title: Re: Enhancement Requests
Post by: Ian Melville on March 29, 2017, 08:09:10 pm
Quote
but again its not the raison d'etre for PAW afaik.
Quote
PAW is for GA to avoid conflicts with other GA traffic, not airliners, right?

Isn't it? I thought the whole idea was to stop anyone bumping into anything airborne! There is enough CAT in my usual Class G airspace to make that a non-starter. However, I can see your problem.

I doubt the Pi has enough power to compute all the airspace(or just Class A) and traffic within it. Then you would have to have updates with the AIRINC data each month. Which countries would it cover? PAW has an international reach.

Filtering by call sign or class or aircraft is also a non-starter as you have no idea of the intent of the flight.

The only way I can see PAW being able to do anything is by 'Trajectory Prediction', and IIRC this is a route Lee was unwilling to go down.

What I don't understand is that you are not using audio alerts, so how is the display of CAT on SD et al, causing an issue?
Title: Re: Enhancement Requests
Post by: mo0g on March 29, 2017, 08:15:54 pm

What I don't understand is that you are not using audio alerts, so how is the display of CAT on SD et al, causing an issue?

It isnt causing a problem.  This wasnt a problem report, but an enhancement idea - being able to disable CAT alerts for those of us utterly unconcerned about bumping into traffic being controlled by ATC into Heathrow or Gatwick.  Apart from anything else, I'd be upset if I didnt spot an airliner on a collision course.

Does anyone have any info on airprox incidents between CAT and GA aircraft, say for the last 20 years?  I am surprised that PAW considers such avoidance a feature, never mind as a primary purpose :)
Title: Re: Enhancement Requests
Post by: Ian Melville on March 29, 2017, 08:57:03 pm
https://www.airproxboard.org.uk/Reports-and-analysis/Annual-Airprox-summary-reports/

Knock yourself out  :o

I picked one report at random and there were 13 CAT v GA in a six month period Jan - Jun 2005, 19 in the same period in 2006, so yes they do happen. I am struggling to pick out the same stats for 2015, though there is a lot more data and analysis.
Title: Re: Enhancement Requests
Post by: exfirepro on March 30, 2017, 12:31:22 am
Mark,

You have certainly opened a can of worms ! Whilst I fully appreciate your comments if operating only in the vicinity of such large and closely controlled airports as Heathrow and Gatwick, I can assure you that in the wider world, Commercial Aircraft regularly operate outside controlled airspace at levels where they can easily come into conflict with GA, including Microlight or Glider traffic operating perfectly legally within the same uncontrolled airspace environment. Using the listening squawks, we regularly hear our local ATC advise in or outbound CAT of the presence of uncontrolled GA traffic and if requested by ATC are happy to exchange information with them regarding our proposed routing, maximum altitude etc. which allows ATC to guide the descent of the inbound aircraft to our mutual benefit and with minimum disruption to either.

I consider the ability to see CAT traffic on screen as well as all other electronically visible traffic to be an essential part of PilotAware's armoury. I could give you many instances where it has already proved mutually beneficial. As ADSB targets are clearly visible and trackable from a long way out, their presence on screen has in my experience never proved detrimental and PilotAware's audio alerts for known position targets are well refined and extremely unlikely to cause major interference, though in your case being so close to Heathrow, I accept that you might want to keep the volume setting low.

Regards

Peter
Title: Re: Enhancement Requests
Post by: mo0g on March 30, 2017, 08:51:30 am
https://www.airproxboard.org.uk/Reports-and-analysis/Annual-Airprox-summary-reports/

Knock yourself out  :o

I picked one report at random and there were 13 CAT v GA in a six month period Jan - Jun 2005, 19 in the same period in 2006, so yes they do happen. I am struggling to pick out the same stats for 2015, though there is a lot more data and analysis.

Lies, damned lies and statistics :)

It is heavy reading and I havent found the specific section within that report, but moving through it in the CAT section there were zero risk A incidents, and a bit further along, among the causal factors there were only 3 of the total airprox incidents attributed to the pilot not seeing the other traffic.  That is for all the CAT incidents, not CAT v GA.  So I could equally take that as proof CAT v GA, caused by not being able to see the other traffic and needing proximity warnings, is not a problem I need to be worried about.

To reiterate, as PAW does pick up airliners, and if some people do feel they NEED those warnings, then that is fine.  I am simply suggesting that not only do I feel I do not need to be warned about CAT, being warned about CAT where I fly will likely prevent me from enabling aural warnings, so having the option to turn that off would be a significant enhancement.

When I operate in the South East, I am much more concerned about traffic using the rat runs avoiding Heathrow and Gatwick airspace, an was the primary reason I decided to buy PAW.  I still consider it a worthy purchase :)
Title: Re: Enhancement Requests
Post by: mo0g on March 30, 2017, 09:05:09 am
Mark,

You have certainly opened a can of worms ! Whilst I fully appreciate your comments if operating only in the vicinity of such large and closely controlled airports as Heathrow and Gatwick, I can assure you that in the wider world, Commercial Aircraft regularly operate outside controlled airspace at levels where they can easily come into conflict with GA, including Microlight or Glider traffic operating perfectly legally within the same uncontrolled airspace environment. Using the listening squawks, we regularly hear our local ATC advise in or outbound CAT of the presence of uncontrolled GA traffic and if requested by ATC are happy to exchange information with them regarding our proposed routing, maximum altitude etc. which allows ATC to guide the descent of the inbound aircraft to our mutual benefit and with minimum disruption to either.

I consider the ability to see CAT traffic on screen as well as all other electronically visible traffic to be an essential part of PilotAware's armoury. I could give you many instances where it has already proved mutually beneficial. As ADSB targets are clearly visible and trackable from a long way out, their presence on screen has in my experience never proved detrimental and PilotAware's audio alerts for known position targets are well refined and extremely unlikely to cause major interference, though in your case being so close to Heathrow, I accept that you might want to keep the volume setting low.

Regards

Peter

Yes, I can see how for some it is useful or even essential, but again within your examples above we can see ATC have much better sight of possible conflicts, and will advise and route CAT accordingly.  That GA traffic is not in danger of being hit by an airliner, and I would also suggest that the pilot of the GA aircraft is either so lost/confused, or so irresponsible that if they had a PAW device I do not think it would have stopped them busting CAS.  I also do not think ATC would be altering the inbound course of CAT to fit in with you ;)

A wider issue here which I think it pertinent is that us pilots who have bought PAW, or are thinking about it, are already conscientious enough to be at low risk of busting CAS and ever putting ourselves in any danger (not that I think there is any danger for reasons previously given) of collision with CAT.  We will be using radios, talking or listening to the relevant units, have transponders, be using nav software, most likely of the moving map variety, have planned routes etc etc.  I am not ruling out that we might bust CAS, but again we will likely discover that via our GPS software, or having ATC telling us.  IMO obviously :)
Title: Re: Enhancement Requests
Post by: exfirepro on March 30, 2017, 09:56:35 am
Yes, I can see how for some it is useful or even essential, but again within your examples above we can see ATC have much better sight of possible conflicts, and will advise and route CAT accordingly.  That GA traffic is not in danger of being hit by an airliner, and I would also suggest that the pilot of the GA aircraft is either so lost/confused, or so irresponsible that if they had a PAW device I do not think it would have stopped them busting CAS.  I also do not think ATC would be altering the inbound course of CAT to fit in with you ;)

Mark,

You seem to be missing the point. We are NOT busting controlled airspace. We are flying perfectly legally in class G airspace, but are, responsibly, letting ATC know where we are by transponding and using the listening squawk to let them know that they can, if necessary, call up and speak to us or advise us of (usually) inbounds, which drop to 2,500 ft as they approach and enter the east stub of the CTA.

A perfect recent example was, routing to the south of the Edinburgh CTA stub at approximately 3,000ft, on a particularly damp and cold day, (testing PAW development software), I heard an inbound shuttle (which I could already see on my screen some way out) request urgent and immediate descent due to severe wing icing. Edinburgh acknowledged and then knowing my current position and track was likely to bring us into conflict, called to check my intended route and maximum altitude. Knowing the situation, I was able to advise them I was turning back east immediately and descending to clear the approach path for the inbound aircraft, which came back on and thanked me for my assistance. Only one of many examples of where PAW has 'saved the day' or at the very least assisted by facilitating traffic avoidance during my regular zone transits. Once ATC learn that you can 'see' their traffic, it's surprising how much more confidently they deal with zone transit requests.

Quote
A wider issue here which I think it pertinent is that us pilots who have bought PAW, or are thinking about it, are already conscientious enough to be at low risk of busting CAS and ever putting ourselves in any danger (not that I think there is any danger for reasons previously given) of collision with CAT.  We will be using radios, talking or listening to the relevant units, have transponders, be using nav software, most likely of the moving map variety, have planned routes etc etc.  I am not ruling out that we might bust CAS, but again we will likely discover that via our GPS software, or having ATC telling us.  IMO obviously :)

No issue whatsoever with the principle here, but by careful use of the Nav System altitude filters (for CAT) and running 'Short' or even 'Ultra Short' Range plus tight altitude filters for bearingless targets, you should be able to minimise the number of visual Mode S and audio alerts from high power CAT mode S (FlyBe etc). Several of us have also added a manual 'volume control' in the audio feed line between the PAW and aircraft intercom, which makes turning the audio alerts down much simpler.

Happy flying,

Regards

Peter
Title: Re: Enhancement Requests
Post by: mo0g on March 30, 2017, 10:28:34 am

Mark,

You seem to be missing the point. We are NOT busting controlled airspace. We are flying perfectly legally in class G airspace, but are, responsibly, letting ATC know where we are by transponding and using the listening squawk to let them know that they can, if necessary, call up and speak to us or advise us of (usually) inbounds, which drop to 2,500 ft as they approach and enter the east stub of the CTA.

I am sure I am still missing something, what does PAW have to do with listening squawks and transponding, unless you do not have a radio equipped with a transponder?  If not, then obviously I see the value to you of that, but still not sure what the real value is of you being able to see CAT traffic via PAW, or worse (from my perspective) getting audio alerts about CAT traffic.

I trust the airspace classification to keep me (in class G) adequately separated from CAT (in CAS).  As you said, if there is an emergency and ATC need to route CAT through class G, then if they can talk to me or see me, it is obviously beneficial, to THEM.  If they could do neither then I am confident they would route the emergency so as not to conflict with me, based on unknown intentions etc.  I would not need PAW to save me from a collision in that scenario, I do not believe?  ATC would not route that traffic close enough to me to cause even a risk D airprox?
Title: Re: Enhancement Requests
Post by: exfirepro on March 30, 2017, 11:32:00 am
I am sure I am still missing something, what does PAW have to do with listening squawks and transponding, unless you do not have a radio equipped with a transponder? If not, then obviously I see the value to you of that, but still not sure what the real value is of you being able to see CAT traffic via PAW, or worse (from my perspective) getting audio alerts about CAT traffic.

You've lost me here Mark - radios and transponders are usually two separate pieces of equipment. Many (if not most) GA have radio but no transponder and believe it or not, large swathes of the UK still don't have reliable Primary Radar coverage - especially at the low levels used by GA and in mountain valleys, etc, so GA - especially microlights, balloons, gliders, paramotors, etc, especially flying in these areas can be virtually invisible to ATC even with transponders! Although I use the listening squawk regularly, it isn't compulsory and in any case only lets ATC know you are listening on their frequency. It certainly doesn't oblige them to provide you with a traffic service outside controlled airspace, hence why PAW provides that service for you. Even if they can't see you, at least you can see them and take any necessary avoiding action before a conflict arises.

Quote
I trust the airspace classification to keep me (in class G) adequately separated from CAT (in CAS).As you said, if there is an emergency and ATC need to route CAT through class G, then if they can talk to me or see me, it is obviously beneficial, to THEM.  If they could do neither then I am confident they would route the emergency so as not to conflict with me, based on unknown intentions etc.  I would not need PAW to save me from a collision in that scenario, I do not believe?  ATC would not route that traffic close enough to me to cause even a risk D airprox?

Except that in most of the UK, CAT traffic routinely has to pass through 'uncontrolled' airspace to get into Controlled Airspace in the first place. This is the point where conflict can occur and outside controlled airspace there is no obligation on ATC to provide YOU with a traffic service even if they can see you. It is as much your responsibility to see and avoid the CAT traffic as it is for them to see and avoid you. PilotAware simply makes this process easier, safer and more reliable as I have outlined above.

Hope this clarifies things.

Regards

Peter
p.s. The simplest way to deal wth unwanted audio is to fit a simple mechanical volume control in the audio line between the PAW and your intercom or headset. Just remember to turn the volume back up again when you do want to hear it. P  ;)
Title: Re: Enhancement Requests
Post by: mo0g on March 30, 2017, 12:07:08 pm
No, I still dont get it.  Perhaps it is just because I have always flown club cessnas that I have been used to always having transponders.  Also that I have never had to share uncontrolled airspace with CAT at normal bimbling locations or altitudes (here and abroad).

Turning down the volume in my case is pointless, because I wanted PAW mainly for conspicuancy and awareness in and around my local area, being in and around CAS and therefore in and around rat runs.  If I only turned up the audio when not in the vicinity of CAT then I would be missing all those alerts.

I will continue to use PAW but not the audio function as, unfortunately, traffic into and out of LHR and LGW is continuous and I would only want to know about other GA as I, personally, do not need to be warned about potential conflict with that traffic.
Title: Re: Enhancement Requests
Post by: exfirepro on March 30, 2017, 12:34:03 pm
Hi Mark,

Swings and roundabouts unfortunately. Believe me, having done a lot of experimental testing against CAT at fairly close range, both on the ground and while passing through the EGPH overhead, I can fully appreciate your position. Just that I am concerned about deliberately excluding known potential risks. You can bet someone will get it wrong and imagine the backlash.

As I say, best IMO to run close altitude filters in your Nav programme for ADSB and close Mode C/S altitude filter in PAW together with Short or Ultra Short (accepting a higher level of risk) for Mode C/S, together with audio at low volume. You will be surprised at how well your ears and brain can filter unwanted alerts after they get used to them providing the volume level is kept low. You never know, Lee may come up with another option down the line.

Safe flying

Regards

Peter
Title: Re: Enhancement Requests
Post by: Keithvinning on March 30, 2017, 08:42:38 pm
Hi Mark

I sympathise your dilemma.

When I fly betwixt Heathrow and Gatwick. I close down PilotAware Radar to +/-2000 ft and Mode C/S to +/500 ft ultra short and find that the problem you are having is not a problem.

This works for me.

Recognising that altimeters are at best +/- 50 accurate, so only expect ANY analogue or electronics systems to be accurate within +/- 100ft. So giving a conservative element for inaccuracy I consider 200ft separation good.

If it still is troublesome to you then set the PilotAware RADAR to +/-1000 ft and the same with your navigation software.

If you then fly close or across the TMZ and are troubled by the additional information that  PilotAware voice alert information gives you turn it down. At this point you will be, hopefully, on a listing squawk or unique squawk and the ATC will let you know of any conflicts or  infringement that you have made.

 
Title: Re: Enhancement Requests
Post by: Paul_Sengupta on April 01, 2017, 03:48:38 pm
No, I still dont get it.  Perhaps it is just because I have always flown club cessnas that I have been used to always having transponders.  Also that I have never had to share uncontrolled airspace with CAT at normal bimbling locations or altitudes (here and abroad).

You'd be surprised. You're near Farnborough, yes? They have aircraft up to BBJ (737) size going in there. What about Biggin and their new 03 instrument approach over two of Redhill's VRPs? Ever experienced an airliner going in or out of Lasham? What about further down west - Exeter? Newquay?
Title: Re: Enhancement Requests
Post by: GeoffreyC on April 03, 2017, 10:52:52 pm
I agree with all the discussion about the problems of filtering out CAT traffic.  I'd rather know about it if it is a potential conflict.

My comment though is having used PAW for the first time in anger I found I was getting quite a lot of alerts from traffic on the ground.  I had set the Mode C/S separation to +/- 2000 feet and was flying along at circa 1500 feet which is fairly normal, but found I kept on getting audio alerts for aircraft that were 1300 feet below me,  1100 feet below, etc.
Now I'd prefer to fly with a 2000 feet separation range if possible rather than 1000 feet separation because I'd like more advance warning of something climbing up to meet me,  but getting alerts off stationary ground based traffic was distracting to say the least.

So is it possible to either:
- Have a +/- 1500 feet separation option?
- Have some "smarts" in the separation detection based upon the height PAW is at,  say +/- 2000 if PAW > 2000 feet, but if PAW is between 1000 and 2000 feet then apply -1000/+2000 - this would filter out a large number of the 'below but stationary' traffic

My preference would be the latter
Title: Re: Enhancement Requests
Post by: exfirepro on April 04, 2017, 12:53:42 am
My comment though is having used PAW for the first time in anger I found I was getting quite a lot of alerts from traffic on the ground.

Geoffrey,

You say.....

Quote
I had set the Mode C/S separation to +/- 2000 feet and was was flying along at circa 1500 feet which is fairly normal, but found I kept on getting audio alerts for aircraft that were 1300 feet below me,  1100 feet below, etc.

...so they could quite clearly have just taken off and were potentially climbing towards you.

This type of alert should only occur with 'bearingless' Mode C or S aircraft, where the alerts are based on received signal strength as well as relative altitude, because their position and distance are otherwise unknown. Whilst your suggestion for an 'automatically variable' relative altitude filter certainly has some merit, in order to effectively provide the 'variable' relative altitude filtering you are suggesting, PAW would have to take account not only of your current altitude, but the height of the ground you are flying over, which we cannot possibly do for the whole of the UK, let alone further afield. Without this information, rising ground would rapidly bring aircraft on the ground back into an 'alert' situation and falling ground would drop climbing aircraft out of your chosen alert bracket without you even being aware this was happening.

I have also just been looking at your post over in the 'Altitude Filter' thread. You seem to have at least 27 contacts showing on your XC Soar screen at the same time, with nothing inside 6 miles from you, so can I ask how you know the aircraft were all on the ground? What Mode CS Detect 'Range' setting are you using? Do you know that you can considerably reduce the bearingless target alerts by trying a shorter Range setting - we normally operate on 'Short Range', or 'Medium Range' if we need/want a bit more warning, but accepting that we will get more alerts. If operating near or transiting over a major airport (as I did yesterday), I would go down as far as 'Ultra-Short' Range, or alternatively turn the volume down a bit lower and live with the alerts for the short period of the transit.

Hope this helps

Regards
Peter
Title: Re: Enhancement Requests
Post by: Paul_Sengupta on April 04, 2017, 01:03:55 am
On the XC Soar radar display, everything further than the outer ring gets put on the outer ring, so all those around the outside are further away than the selected maximum range.

Certainly in the south east of England, with the London airports and airspace, 27 contacts on ADS-B isn't that many. From my house in Guildford with my antenna in the loft, I've seen over 100 contacts at once. You can receive more in the air. Even with my tiddly little antenna that I'm using for transponder receiving, I can pick up over 40 contacts at once in the air.
Title: Re: Enhancement Requests
Post by: exfirepro on April 04, 2017, 01:11:57 am
Hi Paul,

Yes I fully appreciate that fact, but multiple ADSB contacts are unlikely to present a significant audio alert problem, unless all inbound at the same time, which from the screen doesn't seem to be the case. Geoffrey is complaining about multiple alerts from targets on the ground, which is why I am suggesting that he may be running too wide a Mode CS Detect Range.

Regards as always

Peter

Title: Re: Enhancement Requests
Post by: GeoffreyC on April 04, 2017, 08:11:11 am
You say.....

Quote
I had set the Mode C/S separation to +/- 2000 feet and was was flying along at circa 1500 feet which is fairly normal, but found I kept on getting audio alerts for aircraft that were 1300 feet below me,  1100 feet below, etc.

...so they could quite clearly have just taken off and were potentially climbing towards you.

This type of alert should only occur with 'bearingless' Mode C or S aircraft, where the alerts are based on received signal strength as well as relative altitude, because their position and distance are otherwise unknown. Whilst your suggestion for an 'automatically variable' relative altitude filter certainly has some merit, in order to effectively provide the 'variable' relative altitude filtering you are suggesting, PAW would have to take account not only of your current altitude, but the height of the ground you are flying over, which we cannot possibly do for the whole of the UK, let alone further afield. Without this information, rising ground would rapidly bring aircraft on the ground back into an 'alert' situation and falling ground would drop climbing aircraft out of your chosen alert bracket without you even being aware this was happening.
Hi Peter,  thanks for your reply,  glad that my idea potentially has merit  ;)

The alerts I received (and there were a few of them as I was flying) were bearingless CS targets because all I was warned of was the target altitude.  I think I had the mode CS range set to the recommended setting of 'Short', but I will check this.
You're right, as I never saw any of the warning aircraft I am surmising that they were aircraft on the ground based upon my altitude and their relative altitude,  and they could have been aircraft that were taking off and so were becoming a danger.   With some kind of offset altitude alert +2000/-1000 or smarter logic like I suggested based upon my own altitude I feel that I would have had less false positives which has to be a good thing.  The last thing I want is to become complacent and start ignoring alerts because I am receiving too many of them.

I do agree, having a database of altitude information within PAW would be impracticable, and so I thought of the smart range logic as being an achievable alternative.

I have also just been looking at your post over in the 'Altitude Filter' thread. You seem to have at least 27 contacts showing on your XC Soar screen at the same time, with nothing inside 6 miles from you, so can I ask how you know the aircraft were all on the ground?
This is the other issue I faced, that XCsoar doesn't offer any ability to filter out traffic so is I believe showing everything that PAW is detecting, regardless of range or height,  and is plotting them on the 6 mile+ ring which makes for a display that is impossible to use.   When I click on some of these individual aircraft I could see that in several cases they were jets flying thousands of feet above me,  but with so many aircraft plotted and XCSoar not offering any ability to filter based upon range or height, I can't separate the proverbial wheat from the chaff. 

I guess this comes from XCSoar being originally developed for gliders where the low power FLARM would only collect alerts from fairly near aircraft.  PAW picks up stuff miles away and so the display is now overloaded.
Title: Re: Enhancement Requests
Post by: exfirepro on April 04, 2017, 09:01:18 am
Geoffrey,

The other thing that occurs to me that you may not be aware of is that if you are flying close to (i.e. within a few miles of) a major airport, you will experience very strong 'Mode S' signals from CAT traffic 'on the ground' due to their significantly higher power transponder responses to ground radar while taxiing. Unless you are running the Ultra Short Range Mode CS Detect setting, this traffic is likely to trigger alerts at a distance where it is still extremely difficult or impossible to see the aircraft, simply because of the significantly higher signal strength.

Experience of the alert patterns will help you recognise the difference between this type of traffic and incoming GA and allow you to safely disregard these alerts after carrying out a proper visual scan.

Regards

Peter
Title: Re: Enhancement Requests
Post by: Admin on April 04, 2017, 02:55:22 pm
- Have some "smarts" in the separation detection based upon the height PAW is at,  say +/- 2000 if PAW > 2000 feet, but if PAW is between 1000 and 2000 feet then apply -1000/+2000 - this would filter out a large number of the 'below but stationary' traffic

Hi Geoffrey,
Unfortunately ModeC/S use barometric altitude.
So there is no way of knowing the height above ground, its only height difference to a reference pressure of 1013.25mb

Thx
Lee
Title: Re: Enhancement Requests
Post by: GeoffreyC on April 04, 2017, 04:13:14 pm
Hi Geoffrey,
Unfortunately ModeC/S use barometric altitude.
So there is no way of knowing the height above ground, its only height difference to a reference pressure of 1013.25mb

Thx
Lee

Hi Lee,

I was assuming from the GPS data that PAW knows its height above MSL?

The suggestion was to expand the list of mode CS separation ranges that PAW can select from to give more filtering choice,  currently +/- 500,  +/- 1000, +/- 2000 with say 3 additional entries:
+/- 1500 .... works the same as the existing filters based upon difference in barometric height
+2000/-1000 ..... larger range filter for traffic approaching from above than below
"Smart filter 2000" .... +/- 2000 if GPS data height is > 2000,  +2000/-1000 if GPS data height is < 2000

Maybe this isn't a common request or others haven't noticed ground based aircraft causing alerts.  At the time I received these alerts I was flying outside and to the North of Luton CAS and there was no other airfields in sight or on the map.  So maybe it was ground based CAT at Luton that PAW was picking up and reducing the mode CS sensitivity would filter these out,  but if possible I'd like to not have to keep changing the settings whilst flying - taking gloves off etc is a hassle in a flexwing.

Just my 2p suggestion

Cheers, Geoffrey
Title: Re: Enhancement Requests
Post by: Admin on April 04, 2017, 04:23:52 pm
The suggestion was to expand the list of mode CS separation ranges that PAW can select from to give more filtering choice,  currently +/- 500,  +/- 1000, +/- 2000 with say 3 additional entries:
+/- 1500 .... works the same as the existing filters based upon difference in barometric height
+2000/-1000 ..... larger range filter for traffic approaching from above than below
"Smart filter 2000" .... +/- 2000 if GPS data height is > 2000,  +2000/-1000 if GPS data height is < 2000

Hi Geoffrey,
Additional bands are reasonably easy to add
Lets see what others think

Thx
Lee
Title: Re: Enhancement Requests
Post by: exfirepro on April 04, 2017, 06:00:41 pm
Lee/Geoffrey,

I would certainly have no problem with adding additional filtering bands if this would help avoid unnecessary ground aircraft audio alerts.

Regards

Peter
Title: Re: Enhancement Requests
Post by: Ian Melville on April 04, 2017, 07:03:04 pm
I have no issue with extra bands. If it solves an issue for someone, without negative impact to others, then it will be worthwhile. I may beef need it one day.
Title: Re: Enhancement Requests
Post by: T67M on April 04, 2017, 09:26:33 pm
This is a gross oversimplification, but I'm only interested in being alerted (by audio) to aircraft that might collide with me within 30 seconds - any further away than that and they will be too far away to spot visually, and quite likely to change course between the alert and the (non-)collision. Most light aircraft struggle to make 1,000'/min in a climb, so +/-500' works well for me. Any wider than that I get too​ many audio alerts for aircraft I'm never going to see. That said, it is sometimes useful to see the more remote aircraft on the chart/radar - but not for audio alerts.

I do wish there was a distance filter too for ADS-B/P3i contacts - I get a lot of false alerts from airliners at my altitude but 10km away. At typical low altitude speeds that's about a 2 minute warning. Again, 30 seconds (3km) would be fine for me.
Title: Re: Enhancement Requests
Post by: exfirepro on April 04, 2017, 10:57:51 pm
Mike,

Thanks for your comments. From my own involvement in close approach testing as part of the Project EVA Trials, my personal opinion is that 30 seconds to find and avoid a potentially fast moving inbound target approaching from an unknown direction would be cutting things just a bit close for comfort for most GA pilots, though I do appreciate your position. There may certainly be a case for reducing the 'outer' alert boundary for known position ADSB/P3i targets from the existing 10Km to reduce the number of alerts, but I would still want to retain the '3 Warning Zone' principle which was designed to ensure early initial warning with progressively increasing notification only if the inbound aircraft continues to approach. If the aircraft enters the outer zone but doesn't come any closer you will only get the one alert from known bearing targets.

By far the greater number of audio warnings in general come from Mode C/S - especially from Commercial Mode S traffic if in the near vicinity. These alerts tend to repeat if the inbound aircraft signal drops and then increases again - mimicking continuing approach even though this may not be the case. We already have the choice of limiting the level and number of alerts by selecting our desired Vertical Separation and a shorter Detection Range in the Configure Page of course, but my personal feeling is that we still need to do more work in this area.

Thanks again for your views.

Regards

Peter
Title: Re: Enhancement Requests
Post by: T67M on April 05, 2017, 12:41:26 pm
Hi Peter,

I'd agree that the algorithms in PAW will be tweaked over time, and will probably never be perfect for everyone. If I can be any help testing given my location close to Gatwick then please feel free to ask.

My basis for suggesting 30 seconds for the audio alerts is that beyond this range, I usually find it impossible to acquire the target aircraft visually. Interestingly, according to the Airprox website (https://www.airproxboard.org.uk/Topical-issues-and-themes/ACASTCASTAS/), this also roughly matches the TCAS thresholds at low altitude - for example, assuming we're talking airliner approach speeds (170kts) vs medium speed GA (120kts) at 2,000', TCAS makes the first audio alert (a "Traffic Alert" or TA) at 1.4-2.0nm (2.6 to 3.7km) depending upon the geometry, and within a height band of +/-600'.

Mike.
Title: Re: Enhancement Requests
Post by: Ian Melville on April 05, 2017, 01:14:13 pm
My own experience of the time to react to closing traffic was when I was almost head on to a biz jet at the same level. PAW alerted me at 10km. I took avoiding action without seeing the traffic, yet he still ended up about 2km from me, thankfully no longer in conflict. Time between the two was less than 40 seconds. The small head-on view meant that I do not see him until about 3km, perhaps a little more. Waiting until then to take avoiding action would have Resulted in a brown trouser moment  :o 15-20 seconds to get out of the way in a slow aircraft.
Title: Re: Enhancement Requests
Post by: exfirepro on April 05, 2017, 05:53:41 pm
Afraid I can beat that Ian - head to head with a Typhoon in my flexwing at 2000ft (same level) as it swung East from the Peebles Valley towards East Lothian about 2 miles out from me. No PAW help that time, purely visual. Quick wing waggle while flashing my landing light for a few seconds then I broke sharply right, still flashing the landing light. Thankfully he saw me, also broke right then levelled out and gave me a wave as he passed - still far too close for comfort. Witnessed by the wife of one of my pilot friends who was out on her horse and phoned her husband at the airfield to tell him about it, so everyone knew before I even got back.

Mike, I fully accept and understand your reasoning. I still value the early warning provided by any form of electronic conspicuity to support and enhance visual scan. During the Project EVA Tests we did with Trig, we were doing close range intercepts with me acting as 'mouse' and a colleague approaching from various angles in his Quik - only switching on his transponder (ADSB out) as he got close. In every case, PilotAware 'saw' the threat well before we could acquire it visually and in the 'worst case' it took me and my observer nearly 38 seconds to visually acquire the rapidly approaching microlight from pretty much head on and below - and that was despite knowing his approach height and direction from my PilotAware. I fully agree though that the system is always open to improvement.

Regards

Peter
Title: Re: Enhancement Requests
Post by: PaulSS on April 06, 2017, 08:36:27 am
As I said in my first post, I neither own an aircraft nor a PAW (YET) but I am extremely interested in the development and the ideas for this kit. Selfishly, I am most interested in things that might affect me in the future.

To this end, would it be possible to be able set the filters within the PAW kit itself, in addition to being able to do it on the 3rd party equipment. If one is already able to this then please accept my humble apologies and I will scuttle back under my stone.

I ask this because I was particularly interested in Carlos being able to get the PAW information onto his MGL iEFIS but there is, as I understand it, no function for adding filters, so it sounds like he gets to enjoy seeing everything that PAW sees. Reading this forum, it would appear the same can be said of some of the nav displays out there, such as XC Soar.

If one were able to access the PAW Configuration Home screen (the 192.168. Numbers, numbers, numbers thingy) and set the filters there, then they could then enjoy the advantages of the filters on any EFIS (and I’m pretty certain you’ll see a lot more people going that way, so I’m helping to future proof  ;) ) and the XC Soar etc people can do the same.

For Sky Demon owners etc, then they just carry on as they are or, if they really had filters that never changed, they could set them in the Home screen. Unnecessary, I know because it’s easy to do in the 3rd party gear.

I do appreciate that being able to change the filters in flight, as per Sky Demon, is a huge plus and it may not be quite as easy, or impossible, to do so (I don’t actually know) on the Configuration screen in flight but I think if you could set ‘permanent’ filters (for that flight, at least) into your EFIS or XC Soar through PAW then that would be a BIG plus. It certainly would be for me….the guy without any of this kit.
Title: Re: Enhancement Requests
Post by: GeoffreyC on April 06, 2017, 01:05:51 pm
If one were able to access the PAW Configuration Home screen (the 192.168. Numbers, numbers, numbers thingy) and set the filters there, then they could then enjoy the advantages of the filters on any EFIS (and I’m pretty certain you’ll see a lot more people going that way, so I’m helping to future proof  ;) ) and the XC Soar etc people can do the same.
The ability to set range and height filters on PAW would get my vote,  XC Soar is very cluttered with all the "long distance" aircraft currently clustered all around the edge of the 6 mile outer circle and I'd really like to only see the aircraft that might be posing a threat not the airliners overhead.

Maybe if this was added as an "advanced option", default turned off,  so for the majority of users that use SkyDemon etc can leave this turned off in PAW and do the filtering in the EFIS.
Title: Re: Enhancement Requests
Post by: PaulSS on April 06, 2017, 01:22:58 pm
Quote
Maybe if this was added as an "advanced option", default turned off,  so for the majority of users that use SkyDemon etc can leave this turned off in PAW and do the filtering in the EFIS.

To be honest, I don't think you'd even need to do that. In the configuration page you could adjust filters or just leave them alone and do it on the Sky Demon etc. The default is the filters are not set in the PAW but the option exists to do so.

Thinking about it a little more, the Sky Demon guys would probably want to leave the filters in the configuration page alone. This would then prevent any conflict problems of the configuration page saying one thing and the Sky Demon saying something else. If not, then some clever chap then has to add more code telling the config page to take its order from the Sky Demon and do as it's told i.e. the config page would be secondary to the Sky Demon. All that just adds complication.

Put simply, if you've got an EFIS system where you can't add filters and/or you've got a nav system like the XC Soar then you set the filters in the configuration page. Everybody else just do what you've been doing.
Title: Re: Enhancement Requests
Post by: exfirepro on April 06, 2017, 01:55:25 pm
Quote
Put simply, if you've got an EFIS system where you can't add filters and/or you've got a nav system like the XC Soar then you set the filters in the configuration page. Everybody else just do what you've been doing.

Paul,

That's always anticipating that Lee decides to take up your suggestion. Certainly sounds feasible, but I don't know how much work would be involved. Bearing in mind recent requests for a relative altitude filter for known position targets and to reduce the  outer range limit for known position (ADSB /P3i) Audio Alerts, it might be appropriate to revisit the PAW configuration setup at some point to address both these issues.

I'm sure Lee will let us know.

Regards

Peter

Title: Re: Enhancement Requests
Post by: PaulSS on April 06, 2017, 02:08:06 pm
Quote
That's always anticipating that Lee decides to take up your suggestion

But of course, and I can only begin to wonder at how much time and effort is involved in coding these 'wouldn't it be nice if' ideas. I have to admit that my final paragraph did sound as if I was giving instructions in how it should be done and that certainly wasn't my intention. I was just trying to emphasise the difference between those who are able to set filters and those who aren't. Clearly my message came across as instructing and, for that I apologise.

As I said in my original suggestion, I know I'm being selfish in putting forward an idea that would directly benefit me in the future. However, I do also think more people will go down the road of displaying the PAW information on their EFIS and, hopefully, this might encourage even more to do so.

Maybe by the time I've built my aircraft Lee would have come round to the idea (and had the time)  :D
Title: Re: Enhancement Requests
Post by: exfirepro on April 06, 2017, 04:46:03 pm
Paul,

Quote
Clearly my message came across as instructing and, for that I apologise.

I certainly didn't take it that way. Your enthusiasm is infectious and its nice to see you taking such an interest.

Regards

Peter
Title: Re: Enhancement Requests
Post by: GeoffreyC on April 08, 2017, 10:43:07 pm
Flew today from Sandy to Damyns Hall and then onto Stoke.

PAW definitely helped in the haze today.  Although it was legal flight conditions it was still challenging and there were several times that PAW warned me of other traffic well before I could otherwise see it.  One one occasion it was a Skyranger on very similar height and converging towards me,  the Danger alert I got from PAW definitely helped me find it.

Having been using the Radar feature all the time today I have two suggestions to improve it;
1.  Different colour screen.   When flying towards the sun it was quite hard to see white on black text.  So in addition to the current screen styles is it possible to have black on white?
2.  An auto save for the filter settings on the Radar screen.   Each time I go into the Radar I have to change the height and range filters from the default 50km, 50,000' settings.   Would be good if the settings I chose 'autosaved' so they were preserved next time I went into the Radar

Thanks,  Geoffrey
Title: Re: Enhancement Requests
Post by: jp62 on April 19, 2017, 07:18:00 pm
Hi Lee

You asked me to post my recommendations

Radar Screen:

1.   Have the screen initialise at 10KM and +/-3,000 ft. That is the most usefull setting. 120KM and +/- 50,000ft is not at all useful
2.   Make the buttons bigger.  They are too small partic on a phone but also ipad.
3.   Have + and – buttons do opposite to now.  + for more range.  That is the industry / aviation standard for radars and TAS’s. 
4.     Instead of KM, have the range rings and settings in nm

Hope that helps!

The screen could be really useful with those enhancements.

Audio

There is too much audio for bearingless targets which can be unnecessarily distracting.  I believe you should only give bearingless target audio alerts for a/c within +/- 500ft (green/Notice) +/- 1000 ft (yellow/Alert and red/Danger).    In addition, would it be possible to track the target a/c ident so that once a warning is given, the audio is not repeated if it changes from Danger to Alert for example?  Too much audio is worse than none!  Thoughts?

Thanks Lee

Title: Re: Enhancement Requests
Post by: GeoffreyC on May 15, 2017, 11:01:03 am
Having been using the Radar feature all the time today I have two suggestions to improve it;
1.  Different colour screen.   When flying towards the sun it was quite hard to see white on black text.  So in addition to the current screen styles is it possible to have black on white?
2.  An auto save for the filter settings on the Radar screen.   Each time I go into the Radar I have to change the height and range filters from the default 50km, 50,000' settings.   Would be good if the settings I chose 'autosaved' so they were preserved next time I went into the Radar

I've noticed an intermittent problem with PAW Radar.

With Radar running on my Motorola Moto G phone (Android 4.4.4), the Radar screen was rock solid and worked perfectly.  However since I started using a Motorola Moto E phone (Android 5.1), Radar works 95% of the time,  but occasionally and for no obvious reason, the screen sometimes inverts, turns white and the black aeroplane and traffic plots all turn yellow. 

Needless to say yellow text on a white background isn't readable !   After maybe 15-30 seconds the screen then reverts back to normal.

This only seems to occur on Android 5.1, not had the issue with 4.4.4.

Geoffrey
Title: Re: Enhancement Requests
Post by: Admin on May 15, 2017, 11:09:21 am
Hi Geoffrey

This may not be an issue with the version of Android, but with the web browser being used.

Are you using the same web browser in both cases ?
and are both browsers the same version ?

We did notice an issue in chrome when enabling 'graphics hardware acceleration'

Thx
Lee
Title: Re: Enhancement Requests
Post by: GeoffreyC on May 15, 2017, 01:26:50 pm
Hi Geoffrey

This may not be an issue with the version of Android, but with the web browser being used.

Are you using the same web browser in both cases ?
and are both browsers the same version ?

We did notice an issue in chrome when enabling 'graphics hardware acceleration'

Thx
Lee
Hi Lee,

In both cases I was using a full-screen browser (https://play.google.com/store/apps/details?id=com.isolator.fullscreenbrowser2&hl=en_GB - see my other post on this topic).  It doesn't say,  but I would assume that its using the underlying System WebView that is being used by this browser - this was definitely up to date and fully patched.

I couldn't see how to turn on or off hardware graphics acceleration on the phone.

Cheers
Title: Re: Enhancement Requests
Post by: PaulSS on June 05, 2017, 10:22:15 am
I saw development 'chat' on a different thread and thought I'd better not join in and dilute it further with my ramblings but has any further consideration been given to installing the height and range filters in PAW, instead of relying on the likes of the SD filters? I won't repeat my reasoning behind this as it is already in this thread a little further back. I know these things take time and a lot of work but I'm just wondering if it is under consideration.

I don't feel so guilty now asking these questions as at least I now own a PAW unit, albeit it's in a box in England and unlikely to see me playing with it for a while :-)
Title: Re: Enhancement Requests
Post by: Admin on June 05, 2017, 10:55:53 am
I saw development 'chat' on a different thread and thought I'd better not join in and dilute it further with my ramblings but has any further consideration been given to installing the height and range filters in PAW, instead of relying on the likes of the SD filters? I won't repeat my reasoning behind this as it is already in this thread a little further back. I know these things take time and a lot of work but I'm just wondering if it is under consideration.

I don't feel so guilty now asking these questions as at least I now own a PAW unit, albeit it's in a box in England and unlikely to see me playing with it for a while :-)

Hi Paul,
If I understand correctly - you are suggesting that we pre-filter the data, before forwarding on to the NAV device ?
Its an interesting point, because we kind of do this already for the AUDIO messages.
I can actually see 2 good reasons for doing what you suggest.

1. Some NAV devices do not have Filters !!!!
a good example is SkyMap

2. Volume of data
for slooowwwww RS232 connections, such as Dynon Skyview, you need to limit the amount of data which can be sent over the RS232 - this could be useful in not scheduling the sending of traffic at 20,000ft above. I think the fastest connection to SV is 57,600 baud - so this would be a useful feature

So Basically, I think we are saying add a vertical and horizontal filter, prior to sending messages.

interested in any other comments ?

Thx
Lee
Title: Re: Enhancement Requests
Post by: PaulSS on June 05, 2017, 11:19:27 am
Yes, Lee, that's the gist of it.

I can't talk from any knowledge (yet) because my aircraft is still a twinkle in my mind's eye but, from what I've read here and on other forums, is that wiring up to an EFIS (an MGL unit in my case and the one I've read about) from the PAW involves transmitting the data using a USB wire. This is great in that it gets the PAW information to the EFIS BUT, apparently, the EFIS gets ALL the PAW information and there's no facility to filter that at the EFIS. It would seem this is also the case with some of the nav software, such as XC Soar. I must explain that I have never actually seen this in action but it is what I've read and I'm sure someone will correct me if I'm wrong.

What I thought is the same filters as Sky Demon, for instance, could be set in the PAW instead; that way any kit without the filters would be able to enjoy the current  facilities enjoyed by those that do have the filters. It might be that some prefer to set their filters in SD and that would be fine; they'd just leave the PAW ones raw and adjust things on their iPad (or whatever). I intend to have SD on an iPad with PAW and, in addition, PAW piped to my EFIS....just because I can and I like gadgety stuff like that :-) It would be really nice to be able to exclude Speedbird 268 from my screen at FL350 because I get enough of that crap at work and don't really want to see it when I'm tootling around enjoying myself.

Again, having not seen it in action, I cannot comment intelligently on the transmission of PAW data along a serial wire but I can only imagine that reducing the amount of unnecessary/unwanted data before it travels down that tube can only speed things up.

I hope that explains my thinking but, if not, please don't hesitate to ask what the heck I'm going on about  :o
Title: Re: Enhancement Requests
Post by: roweda on June 20, 2017, 10:28:21 pm
What is the reason that traffic distances and Audio Warning Zones are set in kilometres?

Is it due to our cack handed approach to decimalisation where we as pilots measure runways and visibility in kilometres but fly legs in a route and get air traffic instructions in nm?

Are there any plans to introduce a configurable option?

Dave
Title: Re: Enhancement Requests
Post by: brinzlee on June 21, 2017, 12:28:36 pm
That would be a very welcome addition Dave....It has been mentioned before....but not sure where it is in the list of Lee's priorities...
Title: Re: Enhancement Requests
Post by: Ian Melville on June 21, 2017, 12:42:16 pm
I spoke to Lee about this way back. IIRC it is not as easy as it first appears. If you do the conversion just before reporting the distances, you will end up with fraction part to the miles, so it has to be done earlier in the code. Not impossible, but I suspect not a priority for Lee.
Title: Re: Enhancement Requests
Post by: RobertPBham on June 21, 2017, 02:37:59 pm
This may have come up before but as the enhancement page is now 23 long, I haven't been through in depth....

Would it be possible for aircraft profiles to contain the 'G' identifier as well as the HEX code? I fly a lot of club aircraft and can never remember the specific HEX id when I have to select a profile - it would be really handy to have the G code or even if we could rename the profile so it makes sense to the user?

Thanks
Rob
Title: Re: Enhancement Requests
Post by: brinzlee on June 21, 2017, 07:12:29 pm
Hi Rob
You must have configured incorrectly because under the profiles tab at the bottom of the configure screen they are all displayed by the G prefix. Are you putting the aircraft registration in the Flight-ID field or something else.
Regards
Brinsley
Title: Re: Enhancement Requests
Post by: RobertPBham on June 21, 2017, 10:10:01 pm
Hi Brinkley,

I've just booted up PAW to check.

Every aircraft I fly, I check G-INFO online and get the HEX details. I then enter the HEX id on the configure under the field called HEX-ID (Manual). If I then click on the profiles, all the profiles are listed by Hex id.

I'm guessing from your post that I should just enter the G indentifier in the Flight-ID field? If so, thanks - I've learnt something new! I did wonder for the past year why PAW couldn't automatically resolve the HEX from the G code but just thought that's the way it was! :-)

Thanks
Rob
Title: Re: Enhancement Requests
Post by: RobertPBham on June 21, 2017, 10:25:55 pm
Oh and do I need to complete  the flight id and hex id (manual) fields or will PAW work out the Hex id automatically?
Title: Re: Enhancement Requests
Post by: exfirepro on June 21, 2017, 11:17:20 pm
Rob,

You should enter both Hex ID and Aircraft Reg and save them to the profile folder, so they are available at any time.

Regards

Peter
Title: Re: Enhancement Requests
Post by: RobertPBham on June 21, 2017, 11:46:49 pm
Wilco!

Thanks - just a thought but should Flight id be labelled aircraft reg? It might make it clearer although maybe its just me that missed the idea of the flight id field! :-)

Thanks
Rob
Title: Re: Enhancement Requests
Post by: Paul_Sengupta on June 23, 2017, 02:33:54 am
The labelling is due to the correlation with a Mode S transponder. Flight ID and Aircraft Registration are different fields. If you look at Flight Radar 24, you'll see, for example for airliners, that the flight ID is the current flight number, so something like BAW009. The Aircraft Registration is also displayed, from another field.

The convention in GA is that the aircraft registration is entered for Flight ID as well.
Title: Update Over Wifi
Post by: Sparky67 on August 30, 2017, 04:51:02 pm
Hi Lee,

Like many others I guess I download updates and write them to a USB mem stick on my (Windows) laptop. Getting to the PAW box, which is tucked away on the aircraft, involves step ladders and taking a panel off. Then getting the mem stick plugged in is another challenge! I guess we could run a M-F USB extension but I'm trying to avoid additional wiring.

Are there any plans for users to be able to update the PAW software over-the-air (OTA) via wifi, with the necessary file(s) on the root or in a dedicated folder on the connected PC? And having that as an option via the 'update' control panel selection.

Would anyone else find that useful?

Cheers,
Martin
Title: Re: Enhancement Requests
Post by: exfirepro on August 30, 2017, 05:08:12 pm
Martin,

This has been requested several times, but is unfortunately not possible as the PAW Wifi is configured as a 'host' (i.e. a transmitter) and can't accept incoming data.

Update by USB, if necessary using an extension cable as you have identified, is the best option available. Sorry

Regards

Peter
(PAW Engineering Team)

Title: Re: Enhancement Requests
Post by: Admin on August 30, 2017, 05:20:46 pm
Hi Peter (et al)

There could be the possiblity to run some listening socket on PAW.
Then have a Windows Program which connects to this socket and sends the update accross.

This would not be a small amount of work, and I would want to be sure that the effort to do this matches the requirement from users.

Thx
Lee
Title: Re: Enhancement Requests
Post by: Vince on August 31, 2017, 12:11:01 am
Why not just make it so you can upload the update via the web interface?
Title: Re: Enhancement Requests
Post by: agbourne on August 31, 2017, 01:47:45 pm
Feature request - Audio output selection

Hi. I'd like to ask for an enhancement for the audio output please. Currently, the 3.5mm output is connected to the music inout of my aircraft intercom, but the volume is way too low - even when set at 10. There is no way to change the intercom itself (Flightcom).

I was looking for a way to amplify this signal but I really didn't want to mess about with an external amp and additional power supply or batteries that will die at the wrong moment. I therefore came across a DAC device that connects to the USB port of the Pi and has an (amplified) output on 3.5mm port that I could connect to the intercom. FiiO K1 DAC. The power will come from the USB itself. I have read on other websites that an additional driver for this is not required.

I have tested this unit on a MAC and it works fine. When I plug it into the PAW, the Pi sees it in the USB list, but still directs output to the standard 3.5mm port (see attachment).

If we could have an option on the configuration page to set the default audio output to the list of available devices, then I'm sure that would work.

Thanks

Andrew
Title: Re: Enhancement Requests
Post by: Paul_Sengupta on September 18, 2017, 11:18:14 am
For the Radar screen on the web page, would it be possible to include a "reverse" option, so that it would work reflected in one of these sort of screens as a Head Up Display?

http://www.ebay.co.uk/itm/Universal-Car-Phone-GPS-Navigation-HUD-Head-Up-Projection-Display-Bracket-Holder-/152704930708 (http://www.ebay.co.uk/itm/Universal-Car-Phone-GPS-Navigation-HUD-Head-Up-Projection-Display-Bracket-Holder-/152704930708)
Title: Re: Enhancement Requests
Post by: PeterG on October 11, 2017, 10:38:29 am
Another vote for enhancements to the audio - on my set up the volume is so low as to be inaudible in flight and I have the volume set to max.

I'd also to have the option to jump to a specific part of the flight when using the replay option. As it is it will show the whole flight in real time. Perhaps it might be worth adding a 10x replay speed to get over this
Title: Re: Enhancement Requests
Post by: neilld on October 31, 2017, 08:49:05 pm
I'm sure this has been asked before and I have searched various fora but have failed to find any info so apologies in advance BUT:-
Is there any technical reason why Pilot Aware cannot be made to transmit ADS-b data (as well as receive).
I'm thinking of the many GA aircraft that do not currently have mode s transponders, therefore should ADS-b be the mandated (or even preferred) method of EC, owners are faced with the prospect pf purchasing a (non Garmin) mode s transponder in order to use the existing feed from PAW at a cost of at least £1500 plus fitting.  Alternatively they could purchase a uAvionix Sky Echo device at a mere £600 in order to comply.
If ADS-b out could be incorporated into PAW it would open the door to a much wider customer base at lower cost than that currently available.
Title: Re: Enhancement Requests
Post by: tnowak on November 01, 2017, 10:17:58 am
A very quick answer - certification!
All transponders are designed, built and tested to International / European specifications and then certified they meet those specifications.
Very expensive and time consuming to meet certification requirements, even if PAW could transmit ADS-B data (I am sure it could...)
Tony Nowak
Title: Re: Enhancement Requests
Post by: Admin on November 01, 2017, 04:43:24 pm
Hi Neil
Now for the much longer answer ;)

I'm sure this has been asked before and I have searched various fora but have failed to find any info so apologies in advance BUT:-
Is there any technical reason why Pilot Aware cannot be made to transmit ADS-b data (as well as receive).

This is no more technically challenging than anyone else has had to overcome, and there is lots of prior art.

Quote
I'm thinking of the many GA aircraft that do not currently have mode s transponders, therefore should ADS-b be the mandated (or even preferred) method of EC, owners are faced with the prospect pf purchasing a (non Garmin) mode s transponder in order to use the existing feed from PAW at a cost of at least £1500 plus fitting.  Alternatively they could purchase a uAvionix Sky Echo device at a mere £600 in order to comply.
If ADS-b out could be incorporated into PAW it would open the door to a much wider customer base at lower cost than that currently available.

Hmm, these are not valid alternatives, they are mutually exclusive
The SkyEcho from uAvionix is an ADS-B Transceiver NOT an ADS-B Transponder, they are not equivalent.

There are a lot of 'what if' scenarios to consider here, firstly
What if ADS-B is mandated ?
- Would it be mandated for all airspaces (including Class G) ?
- Would it be mandated for all airframes ?
- Would it be mandated as a Transponder only (rather than Transceiver)

I cannot see a SkyEcho as a replacement for a Trig or Funke, it does not output Mode-A, Mode-C, Mode-S (short squitter) or Mode-S. It cannot be interrogated by either ground RADAR or TCAS.

ADS-B Transceivers can only be used in the UK under CAP1391, and then with certain restrictions (which may well be relaxed in the future), they do not provide the same capabilities as Transponders

Finally the big question  ;)
Development and Certification costs would not be small for adding ADS-B to PilotAware, how much would you be prepared to pay for an addition of ADS-B out to PilotAware ?

Thx
Lee
Title: Re: Enhancement Requests
Post by: neilld on November 01, 2017, 06:03:00 pm
Lee,
Thanks for your customary full and clear response.
Perhaps I'm being naive here and lacking any technical knowledge of avionics but if the objective is Electronic Conspicuity for the GA community (leaving aside the regulatory and implementation aspects for now), then it would seem that what is required is a device capable of interfacing with all existing standards.  As far as I can see, PAW has all the required capability (mode A/C/S, ADS-B, FLARM etc.) with the exception of ADS-B out.

For example, an aircraft fitted with a mode S transponder with a GPS input (not PAW) for ADS-B out purposes could be "seen" by a PAW equipped aircraft but could not "see" the PAW equipped aircraft.   In other words, the only 100% EC setup (currently) is between PAW equipped aircraft.  I think it is unlikely that P3i will be adopted as a standard thus leaving ADS-B as the de facto standard.

Regarding cost, I don't know enough about what would be required (software only / hardware + software / if hardware is this more complex(costly) than the current PAW bridge?).
Currently PAW is a bargain but, as ever, there will be a threshold above which potential users will back off.  In my personal opinion an increase of 50 - 100% in price would still put the device well inside the cost of any other (less capable) device on the market.
Do you have a feeling for the magnitude of cost to implement ADS-B out?
Title: Re: Enhancement Requests
Post by: JCurtis on November 01, 2017, 08:01:27 pm
Do you have a feeling for the magnitude of cost to implement ADS-B out?


I'd be impressed of anyone got an approved ADS-B out box to market for under £250K, at the very least.

Why?

ADS-B is a high power RF device and, as said above, has to comply with international standards.  The standard for them (DO-260B I think) is over a thousand pages long, giving all the details.  The path to certification for an ADS-B Out box would really need via Design Authority / Organisation.  If you are not one of these already, you can go through the hurdles to become one - this is no small undertaking from previous research, I gave up costing it when it got to £75k.  It also take a long time to do too. 

Then if you want to make them yourself you, your supply chain, manufacturing & assembly area, and testing need to also be approved.  The paperwork, verification visits, etc. would also eat considerable resources as you have to have all the gear ready to be inspected before you can make anything. 
So a contract manufacturer would be ideal, but one with all the approvals won't be cheap.
One you have all that you can start the design, make prototypes, then go through the torture of aviation certification (you can't just stick a CE label on and away you go, it must be certified to the international standards).  This is lab certification and real air testing, the latter would also need a raft of approvals in case it went wrong and blatted some daft data out that the big boys TCAS complained about.

The only "cheap" way would be to parter up with someone already has the appropriate facilities and authorisations, then make a box that would be suitable add on to PAW.  Although I suspect you would need to make a box that could, potentially, take various input sources to make it more saleable.  Note for this everything you do design wise etc. must fall within the quality standards of the partnered organisation and you could end up doing all the work and negotiating a suitable percentage to "use" their standing to help with the product certification side.


Remember the PAW bridge is based on a modified off-the-shelf module and is, in relative terms, very low power RF wise.  It uses a free to use radio frequency used for a multitude of devices, so lots of people make the packet radio chips that these modules use.  ADS-B in comparison is an exceedingly small pool of potential customers, with large development costs.

I wonder what the quote would be for suitable product liability insurance would be too....
Title: Re: Enhancement Requests
Post by: Admin on November 01, 2017, 09:13:22 pm
A far more detailed response Jeremy!

There is a very good reason why uAvionix needed to raise $5,000,000 in series A funding, and Jeremy hits the nail on the head
From my experience in previous startups of series A round investors, they typically expect a minimum 10X return, in fact googling around forbes now indicate a higher expectation.
That makes a $50,000,000 expectation !
As a company selling hardware, there is only one source of income for that, and it will not come from selling skyecho at £600 for CAP1391 in the UK, the economies do not seem to scale.
I still cannot get my head around the equivalent product to Skyecho in the US, is echoUAT+SkyFX, total cost $1449
Sums do not add up do they, or maybe I am not too good at arithmetic 🤔

Title: Re: Enhancement Requests
Post by: JCurtis on November 01, 2017, 09:23:24 pm
I didn't really touch on it, but probably reckon of it taking a couple of years too - and the costs for staff, premises, etc.

To do anything in the certified aviation world is just astounding, I took a peek at what was involved and still have the scars!
Title: Re: Enhancement Requests
Post by: neilld on November 03, 2017, 12:13:38 pm
Do you have a feeling for the magnitude of cost to implement ADS-B out?


I'd be impressed of anyone got an approved ADS-B out box to market for under £250K, at the very least.


That would indeed be a large spend and probably well beyond the scope of any UK based venture capital or crowdfunding scheme which makes it all the more remarkable what uAvionix have achieved in the last three years with a wide range of products including some for a UK market that doesn't theoretically exist yet. 
I guess the Californian entrepreneurial mentality has something going for it.
None of this takes away from the heroic efforts of Lee and the team to bring PAW to market in record time at affordable cost.
Title: Re: Enhancement Requests
Post by: Paul_Sengupta on November 04, 2017, 10:31:03 pm
I guess the Californian entrepreneurial mentality has something going for it.

That, and a captive market of tens of thousands of people for whom ADS-B is becoming compulsory. Note the difference in price in the US market and the UK market, where in the UK market it's voluntary...  ::) ($1300 vs £600)

I expect if Lee and the chaps could be guaranteed to sell 40,000 at $1300 a piece, it would be worth their while. But then when the price gets up past £600 a piece, you might as well leave it to your competitor who's already made the R&D costs back in their native market and concentrate on your own proprietary low cost solution. You're far more likely to get voluntary take up at £200 than $1300.
Title: Re: Enhancement Requests
Post by: Winged_Jaguar on March 25, 2018, 12:54:20 pm
Hi Lee

Small request re Radar view. I run my PAW as a ground station when not flying with it. At the moment the rose on the radar view is based on GPS heading but with a static ground station this results in a largely random heading being displayed depending on the GPS output. Would it be possible to have an optional feature to allow one to set the rose heading to a fixed bearing in degrees. This would enable one to enter 0/360 for a 'north up' view or any other bearing that might say be the direction one was seated at looking at the screen so one could quickly ascertain a planes position from the ground observers view. When flying the GPS view would no doubt be preferable for many people.

Many thanks.
Chris
Title: Re: Enhancement Requests
Post by: Admin on April 03, 2018, 09:30:09 am
I bet you're all laughing your socks off, and I wouldn't blame you, thanks again,

Actually, no.

Lee is it possible to have a "You are running the latest software version" message?
Ian
Title: Re: Enhancement Requests
Post by: Burbank on May 18, 2018, 02:58:53 pm
Just wondered if the Rosetta is using the Raspberry Pi 3?  If so, any chance we can use a bluetooth GPS (like a Garmin GLO) so we dont need a wired connection to PAW??
Title: Re: Enhancement Requests
Post by: exfirepro on May 18, 2018, 04:17:19 pm
Hi Burbank,

The new ‘Rosetta’ is based on the Raspberry Pi3B (n.b. NOT the new Pi3B+) and now uses the inbuilt WiFi. The Bluetooth option is not used in the current setup. Rosetta already contains its own dedicated internal GPS, which we find extremely reliable, so I can’t see why we would want to introduce the complexity of an external GPS source. I certainly know of no plans to include Bluetooth GPS connectivity at present, though as always, Lee considers all options as part of our ongoing development.

Best Regards

Peter
PilotAware Engineering
Title: Re: Enhancement Requests
Post by: PaulSS on May 18, 2018, 11:26:01 pm
Quote
I certainly know of no plans to include Bluetooth GPS connectivity at present

That's a shame; I was wondering if BT could be used for audio out  :(
Title: Re: Enhancement Requests
Post by: Ian Melville on May 19, 2018, 06:52:57 am
Paul, you could always put it forward as an enhancement request?

The Pi3B+ draws more power, so those running off a battery may not wish to upgrade to this model anyway.
Title: Re: Enhancement Requests
Post by: Admin on May 19, 2018, 12:19:40 pm
Quote
I certainly know of no plans to include Bluetooth GPS connectivity at present

That's a shame; I was wondering if BT could be used for audio out  :(

Yes I think this will be a good future enhancement
Thx
Lee
Title: Re: Enhancement Requests
Post by: PaulSS on May 19, 2018, 03:03:50 pm
Quote
Paul, you could always put it forward as an enhancement request?

 :) Well, seeing as we're in the right place (Enhancement Requests thread) can we have Bluetooth audio please  :)
Title: Re: Enhancement Requests
Post by: Chris Parsons on June 05, 2018, 09:31:48 am
Yes, I would second the request for bluetooth audio...you can get a tiny bluetooth dongle and I wouldn't think it would be too difficult
to route the audio out via bluetooth using something like this perhaps?

https://www.novatech.co.uk/products/novatech-micro-100m-usb-bluetooth-adapter/bt-usb-m2.html?gclid=EAIaIQobChMI97OR54282wIVU5nVCh1QaQXpEAQYASABEgJsSPD_BwE#utm_source=google&utm_medium=base&utm_campaign=products

Regards

Chris
Title: Re: Enhancement Requests
Post by: Chris Parsons on June 05, 2018, 09:55:52 am
Searching around a bit I found an old thread...

http://forum.pilotaware.com/index.php/topic,780.msg9421.html#msg9421

I have a Bose A20 headset so I have ordered one of the transmitters from here

https://www.ebay.co.uk/itm/163048079117

For a tenner delivered it's got to be worth a try?

Chris
Title: Re: Enhancement Requests
Post by: Ian Melville on June 05, 2018, 10:10:07 am
Make sure your A20 is one withe the BT symbol on the conrol unit, not a phone handset.  Those with a phone handsetvwill only connect to phones and the upgrade is expensive.
Title: Re: Enhancement Requests
Post by: PaulSS on June 05, 2018, 10:11:25 am
Hi Chris,

The BT transmitters will certainly do the job of piping audio from the PAW 3.5mm jack to a BT headset and if you're 'normal', as opposed to me, then it's a great solution. I've got one and they work  :)

My problem is that I will be mounting my PAW behind the panel and it will be less accessible than normal. I will have my PAW powered from a Charge4 USB charger and have the spare port to ensure the BT transmitter is charged but the problem comes after a flight. When the aircraft battery switch is turned off and I walk away from the aircraft then the BT transmitter will still be plugged in to the PAW and the battery will wear down as it has not been specifically switched off. Fast forward a few days and I'll switch everything back on, the USB charger will provide power to the BT transmitter BUT I will actually have to turn it on again........cue clambering beneath the panel which I hope to avoid with a different audio solution.

If I could wire the BT transmitter permanently on then it wouldn't be a problem as it would only work when it's plugged into the USB charger and that would be fine with me. I've had a look at the little box and it's sealed up rather well  :(

If it didn't need switching on again once the battery has worn down then all would be good, but this is not the case.

The BT dongle you linked to earlier would do the job IF PAW audio could be piped through a USB port. Yes, it would mean the loss of a USB port but I could live with that  :)

If that doesn't work then I'm more than happy to buy a Pi 3 with built in WIFI and BT and hopefully get PAW audio through the Pi.
Title: Re: Enhancement Requests
Post by: Ian Melville on June 23, 2018, 06:11:38 am
Is it possible to increase the number of devices that can connect simultainiously? Now we are using Pi3B, it should be able to handle the load of an extra device or two?
Title: Re: Enhancement Requests - Radar Screen
Post by: Seanhump on June 26, 2018, 10:25:00 pm
Would it be possible to resize the radar screen in any way …? Ideally by the user.

It's fine in Portrait mode on an Ipad, but cuts the bottom off in landscape mode …. something that can be looked at possibly .?

Cheers
Title: Re: Enhancement Requests
Post by: brinzlee on June 30, 2018, 10:10:45 am
Could I also put in the popular request to enable the onboard bluetooth on the pi3 for audio transmission....I have a separate bluetooth transmitter on the 3.5mm socket at the moment but everytime I go to use it, the battery is flat...!!! Grrr....On board bluetooth would be a very nice upgrade....!!!

Thank you.....
Title: Re: Enhancement Requests
Post by: neilmurg on March 07, 2019, 11:49:44 am
Audio
Now that Skydemon will itself announce traffic, and apparently in an intelligent way ie only targets which are heading your way rather than within a threat circle,
- and other things like airspace, runway incursion, obstacle clearance - but not bearingless targets

Could we have a PAw option to only annunciate bearingless, so that PAw and SD aren't both warning about the same thing?

Also:
I am lucky in that due to the 8.33 discount we now have an audio panel with Bluetooth and 3.5mm phono in so I can receive both audio sources, but there are complex implications in having 2 audio sources for warnings. Most panels / aircraft won't have the capability to receive both
- will users forgo the obstacle etc. warnings in favour of bearingless targets?
- will users want 2 sets of warnings for the same aircraft
- can these sources be combined into a single panel/headset input?