Excessive audio alerts - could be reduced

[rogellis]

.

I have noticed that an aircraft will give an alert as it leaves an alert zone, as well as when it enters an alert zone, giving a number of additional alerts.   This is unnecessary, as the departing aircraft is not a threat.  I think it would be easy to stop the alerts, when transiting from a close-in zone to a zone further away.

Also:
When tracking an aircraft in the circuit, the PAW gave two alerts on long final, because the aircraft crossed the 5km threshold and the 1,000 ft threshold almost simultaneously.  It also gave two alerts on short final, because it crossed the 3km threshhold and the 500 ft threshold together.   To prevent this, the system would have to realise the aircraft was in the complete zone, and not give a second alert because the vertical or horizontal limit of that zone has also been breached. 

Also:
We also had an aircraft in the circuit, oscillating between 4.9 and 5.1 km, and between 950 ft and 1050 ft.  So it was crossing the alert boundaries quite often, resulting in 20 alerts per circuit.  To prevent this, the system would have to remember that an alert had just been given for that aircraft, 5 or 10 seconds ago, and not give another.   (The problem was doubled, because it was giving an alert leaving the zone, and another alert for reentering the zone, again and again.)


This was in ADSB-PAW mode, but the same was happening with the c/s mode too. If the altitude or signal strength was oscillating about a zone boundary, the audio alerts were almost continuous.  (Two c/s mode helicopters doing very close-in circuits.)

Roger

[Admin]

Hi Roger

Firstly, which software release of PilotAware are you running ?
This can be found on the web home page

I have noticed that an aircraft will give an alert as it leaves an alert zone, as well as when it enters an alert zone, giving a number of additional alerts.   This is unnecessary, as the departing aircraft is not a threat.  I think it would be easy to stop the alerts, when transiting from a close-in zone to a zone further away.

That is definitely NOT intended behavior, can you supply a track file an an approximate time (if you recall) of when this happens ?
I will replay and try to work out what is happening

Also:
When tracking an aircraft in the circuit, the PAW gave two alerts on long final, because the aircraft crossed the 5km threshold and the 1,000 ft threshold almost simultaneously.  It also gave two alerts on short final, because it crossed the 3km threshhold and the 500 ft threshold together.   To prevent this, the system would have to realise the aircraft was in the complete zone, and not give a second alert because the vertical or horizontal limit of that zone has also been breached. 

Hmm, again this is not the design, these are bounding boxes so it should be a case of AND not OR, ie within (5km AND 1000ft), within (3km AND 500ft), again if you can provide a track file this helps immensely

Also:
We also had an aircraft in the circuit, oscillating between 4.9 and 5.1 km, and between 950 ft and 1050 ft.  So it was crossing the alert boundaries quite often, resulting in 20 alerts per circuit.  To prevent this, the system would have to remember that an alert had just been given for that aircraft, 5 or 10 seconds ago, and not give another.   (The problem was doubled, because it was giving an alert leaving the zone, and another alert for reentering the zone, again and again.)

Ahh, now this definitely was a valid problem reported by Peter Robertson, we talked about fixing this, but cannot remember the details, and whether it made it to 20180129 - I will ask Peter of his recollection

This was in ADSB-PAW mode, but the same was happening with the c/s mode too. If the altitude or signal strength was oscillating about a zone boundary, the audio alerts were almost continuous.  (Two c/s mode helicopters doing very close-in circuits.)

There were a lot of improvements added for ModeC/S in 20180129, I would be interested of your findings once you have upgraded (assuming you have not yet)

Thx
Lee

[exfirepro]

Roger,

I was just about to post a reply when I noticed Lee had already done so, so I have integrated my comments below instead.

Hi Roger

Firstly, which software release of PilotAware are you running ?
This can be found on the web home page

I have noticed that an aircraft will give an alert as it leaves an alert zone, as well as when it enters an alert zone, giving a number of additional alerts.   This is unnecessary, as the departing aircraft is not a threat.  I think it would be easy to stop the alerts, when transiting from a close-in zone to a zone further away.

That is definitely NOT intended behavior, can you supply a track file an an approximate time (if you recall) of when this happens ?
I will replay and try to work out what is happening

I take it you are talking about PilotAware AUDIO Alerts Here? If so, this definitely shouldn't happen - to my knowledge it never has before. ADSB and P3i are both set up to give a single audio alert only when an aircraft ENTERS a higher risk zone - NEVER when it moves from a higher to a lower risk zone.

Also:
When tracking an aircraft in the circuit, the PAW gave two alerts on long final, because the aircraft crossed the 5km threshold and the 1,000 ft threshold almost simultaneously.  It also gave two alerts on short final, because it crossed the 3km threshhold and the 500 ft threshold together.   To prevent this, the system would have to realise the aircraft was in the complete zone, and not give a second alert because the vertical or horizontal limit of that zone has also been breached. 

Hmm, again this is not the design, these are bounding boxes so it should be a case of AND not OR, ie within (5km AND 1000ft), within (3km AND 500ft), again if you can provide a track file this helps immensely

Ok, if an aircraft passes the outer (10Km) 'horizontal' zone boundary but remains outside the 'vertical' (+/-2000') boundary for that zone (let's say it's 5000ft above us), no alert will be generated as the aircraft has not 'entered' any danger zone.

If however the aircraft had entered the horizontal 10Km boundary 'within' the vertical boundary of the zone, a single alert would be triggered, because the aircraft has met BOTH criteria for the 10Km 'outer zone'.

If the aircraft then continues straight and level at say +1,500' and gets 'closer than 5Km' horizontally, but remains above the 1000ft vertical limit of the 5Km zone, again no further alert will be given (though the aircraft will continue to be tracked and shown on the Nav Screen). If the aircraft passes straight through the zone and away at that same level, you should still hear no further alerts.

If at some point (let's say just on 3Km from you) the aircraft then descends directly into the 3Km inner zone from above, (as it might on final) it will give an alert as it descends through +1000 ft (entering the 5Km/1000ft zone at 3Km) and another as it passes through +500 ft into the 3Km/500ft zone (in this case at say 2Km), so both alerts will be in the form 'Traffic (bearing) 3 Kilometres 1000 feet above', then 'Traffic (bearing) 2 Kilometres, 500 feet above. (Figures are examples - not necessarily realistic).

Other than this PilotAware should only repeat alerts for known position targets if the aircraft goes back outside an 'inner zone' and re-enters it (see below*).

Also:
We also had an aircraft in the circuit, oscillating between 4.9 and 5.1 km, and between 950 ft and 1050 ft.  So it was crossing the alert boundaries quite often, resulting in 20 alerts per circuit.  To prevent this, the system would have to remember that an alert had just been given for that aircraft, 5 or 10 seconds ago, and not give another.   (The problem was doubled, because it was giving an alert leaving the zone, and another alert for reentering the zone, again and again.)

Ahh, now this definitely was a valid problem reported by Peter Robertson, we talked about fixing this, but cannot remember the details, and whether it made it to 20180129 - I will ask Peter of his recollection

Lee is correct, the phenomenon of repeating alerts when 'known position' (ADSB/P3i) aircraft in flight repeatedly cross known thresholds is known and was discussed between Lee and myself in early October. The effect was most noticeable when travelling in company with another PAW/ADSB equipped aircraft near any of the zone boundaries, though particularly at close range, for example where both aircraft are already well inside the 3Km inner zone at say less than a Kilometre and flying at close to +/- 500ft in relation to each other. As the aircraft rose and fell in flight, we got repeating alerts like 'Traffic 3 o'clock 400 Metres 500 feet above' each time the aircraft separated and moved back together. The initial solution was not to fly close to the zone boundaries, which proved the point and stopped the problem until Lee came up with a more technical solution, which was to selectively extend the zone boundary by introducing hysteresis into the software.

This work was done back in October and I would have expected it to have migrated to the new version released yesterday (which is why I asked what software version you are running), though I'm pretty sure we never managed to test it fully in the air as my plane has been out of commission since early November, so I can't say for certain if it was 'signed off'. If not it will no doubt be there next time round.

This was in ADSB-PAW mode, but the same was happening with the c/s mode too. If the altitude or signal strength was oscillating about a zone boundary, the audio alerts were almost continuous.  (Two c/s mode helicopters doing very close-in circuits.)

There were a lot of improvements added for ModeC/S in 20180129, I would be interested of your findings once you have upgraded (assuming you have not yet)

Thx
Lee

Mode C/S Alerts do NOT work on 'physical' boundaries, but on triggers determined from received signal strength, which is an entirely different animal. The trigger 'distances' are user selectable by setting mode C/S 'Range' (which is in effect a sensitivity control). Unfortunately as Mode C/S aircraft move in and out of 'range' when flying circuits - signal levels naturally rise and fall and alerts are generated each time the aircraft gets close enough to enter (or re-enter) a higher risk zone. The only answer at present is to (temporarily) select a shorter Mode C/S Range which will reduce the number of alerts.

The 20180129 release contains significant software improvements designed to improve Mode C/S alerts. If you haven't already done so, please update, give it a try and let us know how you get on.

Regards

Peter

[rogellis]

.
Peter,

I have downloaded the Track but cannot find the software to open it.

I can play it on my iPad, but cannot increase the speed (it is about 3 hours long).

I can send you the file.  The best example would be around 14:00, when there was an aircraft in the circuit, giving lots of aurals.  And an aircraft leaving the circuit that gave multiple aural warnings.    The colours all changed in the right order, as it left the circuit, but with lots of aurals.

R

[Ian Melville]

Roger,
The boffins will read it in a text reader, or spreadsheet. That was why Peter requested a time as it saves a lot a wading through data.

The files are usually too big to email or add as an attachment to a forum post. Best to put it on Dropbox (other cloud storage is available  ) and post just the link.

[rogellis]

Ok, I think I know what is happening on many of these instances. 

The ADS-B signals are not always 100% accurate, say +/- 50 ft or +/-100m.  So if there is a 'jitter' as the target crosses a boundary, it will oscillate across the zone boundary and give two calls. 

 •  Constant transitioning of a zone boundary, for aircraft in the circuit.  See 13:41 to 13:45
 •  Multiple pop-up alerts caused by intermittent transmissions.  See 13:55 to 13:57.
         (It is treating each new transmission as a new contact.)
 •  Orange to green transition (??)   See 14:17
 •  Two calls transitioning to green to orange.  See 14:19:40
 •  Two calls transitioning to orange to red.  See 14:20:20
 •  See  14:31 for something.
 •  Two calls transitioning to orange to red.  See 14:36:20
 •  Two calls transitioning to green to white.  See 14:40:45

I will see if I can upload the file somewhere. 

R



Ok, I have uploaded the file to here.  Hope you can access it:
https://files.fm/u/2hwpu7rz#_


R

[Admin]

Hi Roger

The release 20180129 has many fixes to address this, would be interested i. Your feedback after upgrade

Thx
Lee

[exfirepro]

Hi Roger,

It was actually Lee who asked for the track file and approximate time(s), not me, though I would have suggested it if he hadn’t. Lee can search the track files much quicker and knows what he is looking for! If you want to look through the files yourself, you can open them using Wordpad or Notepad, but this involves manual searching, which takes absolutely ages and you need to know what you're looking for, which can be a bit of a challenge.

I take it by...

'The ADS-B signals are not always 100% accurate, say +/- 50 ft or +/-100m.'

...you mean the figures or positions displayed on your Nav system screen?

The list of times and events you have supplied will certainly help speed up the search considerably.

Thanks again

Regards

Peter

[rogellis]

'The ADS-B signals are not always 100% accurate, say +/- 50 ft or +/-100m.'

...you mean the figures or positions displayed on your Nav system screen?

Peter

Yes.  As you know the contacts often jump around, because either the info they are sending changes unnecessarily, or perhaps your own position changes unnecessarily.  (Small gps reception errors, generating slightly false positions or altitudes etc:).  And if the aircraft contact jumps at a zone boundary, it will cross the boundary twice, and give another warning.

The last contact I noted above is a good illustration.  You can see that it was leaving the green zone into the white, but then did a little jump back into the green zone for just one second.  And so the system saw a contact re-entering the green zone and gave an additional aural zone alert, when it should not have done so.

The contacts may need a smoothing or averaging algorithm, to stop them jumping around so quickly.

For instance one of the helicopters (close in red contact) was hovering for ages, and moving around ever so slightly.  PAW interpreted this as sudden jumps 90 degree or 160 degree left or right, and then back again to the into wind position.  (Likewise for the altitude.). A smoothing algorithm would take that variable info and display a contact that turned just 20 degrees for one second, and then back into wind - which would be a much more accurate portrayal of what the helicopter was actually doing.    PAW should not be dispaying aero-manoeuvres that are physically impossible.

Same with the mode c/s aircraft that taxied around in circles on the apron, while trying to position for the fuel bowser.  This must have changed the c/s signal strength, and it was interpreted by PAW as an aircraft crossing many (signal strength) zone boundaries within a couple of seconds - causeing multiple c/s alerts.   Again, an averaging algorithm would smooth out and eliminate those multiple zone transitions.

I have not tried the new software as yet.


Take heart ... PAW is not the only company to have had this problem.  When the first 737-800s were delivered, the air data computer displayed an airspeed that would jump +/- 20 kts on final approach. So you just had to ignore the ASI and fly a self-calculated average.  Finally they came up with some averaging algorithm that smoothed out the fluctuations, and brought it down to +/- 5 kts.     

But you can imagine the two departments arguing.  Legal department would be shouting “if you do not show the pilots the actual instantaneous speed, we could be sued”, while flight oerations would be shouting “I cannot fly a 140 kt approach if the airspeed indicates 120-160 kts........”

R


Oh, and the first TCAS systems did the same.  A contact in the 1 oclock was continually dashing over to the 11 oclock and back again.  Again this was fixed via a change in software, rather than changing the hardware.

.

[exfirepro]

Morning Roger,

Thanks for the clarification, that makes things much clearer!  Out of interest, where (airfield) were you running PAW?

It is certainly a fact that when ‘static’ on the ground, or moving very slowly, most GPS/Nav systems try to orient themselves ‘North Up’ - or sometimes just can’t make their mind up which way they should be facing and keep rotating from side to side. I see the ‘return to North’ phenomenon regularly when testing in the car, when for example the car stops at traffic lights. The Nav system thinks I have ‘landed’ and spins my ‘aircraft’ to face North irrespective of which way the car is facing. The same phenomenon is noticeable when running PilotAware on the ground, though in my experience, with a good solid GPS signal my own ‘aircraft’ usually sits pointing solidly North, then reverts to the correct orientation as ground speed rises. I have never experienced any issues in this respect in the air.

I took a quick look at your log late last night and there is certainly plenty of traffic data to evaluate. Once Lee gets a chance to evaluate your log we can see what is going on and assess whether and to what extent a ‘smoothing’ algorithm might help reduce duplicate alerts.

Keep up the good work.

Best Regards

Peter

[rogellis]

It is certainly a fact that when ‘static’ on the ground, or moving very slowly, most GPS/Nav systems try to orient themselves ‘North Up’ - or sometimes just can’t make their mind up which way they should be facing and keep rotating from side to side.

Peter

Yes, it was doing that with my unit.  And I suppose when the helicopter was stationary, it may have orientated north too.  I cannot remember.

The main problem with the helicopter was the signal dropout.  For whatever reason, perhaps because the rotor blades, the signal from the hovering helicopter was intermittent.  The PAW interpreted this as a new aircraft each time it found the signal, and gave another audio warning.

Cheers,
Rog

[Admin]

The main problem with the helicopter was the signal dropout.  For whatever reason, perhaps because the rotor blades, the signal from the hovering helicopter was intermittent.  The PAW interpreted this as a new aircraft each time it found the signal, and gave another audio warning.

Hi Roger
Do you know what the Helicoptorwas transmitting, ADS-B or P3I or both.
Also what distance away was it ?

If you are able to put the track file in a dropbox or google drive and give me a link, I will take a look

Thx
Lee

[exfirepro]

Lee,

There is a link to the track file at the bottom of reply 5. I had a quick look last night. Lots of data.

Regards

Peter

[rogellis]

Hi Roger
Do you know what the Helicoptorwas transmitting, ADS-B or P3I or both.
Also what distance away was it ?

If you are able to put the track file in a dropbox or google drive and give me a link, I will take a look

I have uploaded the file to here. 
https://files.fm/u/2hwpu7rz#_

There were five or six RAF helicopters playing around on and around the field at Sleap.    (The ‘Z’ registrations.).       I think Shawbury use Sleap as a secondary field, to give the people at Shawbury a break from annoying hovering helicopters.
 
Most only had c/s, but one or two had Adsb.  The helo in question was Adsb, and was hovering just west of the runway only 500m away from the control tower cafe where I was ensconced.   It was in direct line of sight, through the windows.  And since I was clocking commercial traffic a couple of hundred km away, I dont think the glass effected the reception.   

R


.

[rogellis]

.
The two Z-reg aircraft at the top are ADSB RAF helicopters.
Shame that nobody could initialise these ADSB units, to display their type or owner.

As you can see, it was quite busy, so the PAW was working hard...

R