Hi again Tim,

Many thanks for agreeing to look into this problem. Sorry I was busy software testing yesterday, so missed your reply, but see the others have already posted screen shots. Here is another recent one from my home 5 miles south of EGPH this afternoon showing an ADSB contact together with a Mode S one in the same shot, which I think perfectly illustrates the problem. Apologies for the route and track - they were still on screen from yesterday, though not in any way unrealistic.



The ADSB altitude and Flight ID is clearly identifiable, while the Mode S relative altitude is virtually unreadable against the (very necessary) background 'clutter' of the chart. Whilst this is in part due to the smaller size of the Mode S text, the ADSB text is also made much more readable by the contrasting yellow background, which effectively masks the chart behind (or should that be below). The inclusion for Mode S of Flight ID/Reg as with ADSB (as raised by Lee above) would also help to make the text block bigger and thus easier to pick up quickly on screen. It can often also help to 'identify' the potential position or route of otherwise bearingless aircraft. Locally, for example, I know G-OSSA - a regular Mode S contact - is the Parachute Jump Plane out of Fife - Glenrothes, so would look for it first towards that general area. In this case the Mode S contact (from my PilotAware Traffic Table) was a FlyBe Dash 8, which would have been identifiable from an on-screen callsign and which would be following one of the standard Edinburgh approach or exit routes. Hope this helps.

Many thanks once again

Regards

Peter

Thanks all. I've done the easy bit which is to make the font size and colours consistent between bearingless and "normal" targets. Inclusion of the ID is slightly trickier though and I don't want to change that code without being able to test it. As far as I recall, PowerFlarm never sends ID with bearingless targets so that codepath will not have been tested.

Perhaps Lee you could provide some example sentences with bearingless Mode S going on? I recall that PowerFlarm never sends information on more than one bearingless target at the same time, does that still hold true for PilotAware?

Hi Tim,
Regarding the bearingless target:
Messages are sent to the Navigation device every second, this will include the GPS sentences, the ADS-B/P3I sentances and a single Bearlingless target which is determined to be the highest threat.

However, bear in mind that this could change in the next iteration, one second later.
example sentences below grep'ed from a logfile, not necessarily chronological
filters wide open to 50,000ft in order to capture some data.
Thx
Lee

$PFLAA,1,4500,,8739,1,,,,,,0*42
$PFLAA,1,4500,,8739,1,,,,,,0*42
$PFLAA,1,4500,,8739,1,,,,,,0*42
$PFLAA,1,4500,,8739,1,,,,,,0*42
$PFLAA,1,4500,,8739,1,,,,,,0*42
$PFLAA,1,4500,,8739,1,,,,,,0*42
$PFLAA,1,4500,,8739,1,,,,,,0*42
$PFLAA,1,4500,,8739,1,,,,,,0*42
$PFLAA,1,4500,,8739,1,,,,,,0*42
$PFLAA,1,4500,,2506,1,,,,,,0*46
$PFLAA,1,4500,,2529,1,,,,,,0*4B
$PFLAA,1,4500,,13158,1,,,,,,0*79
$PFLAA,1,4500,,13158,1,,,,,,0*79
$PFLAA,1,4500,,8769,1,,,,,,0*47
$PFLAA,1,4500,,8769,1,,,,,,0*47
$PFLAA,1,4500,,8770,1,,,,,,0*4F
$PFLAA,1,4500,,8769,1,,,,,,0*47
$PFLAA,1,4500,,8769,1,,,,,,0*47
$PFLAA,1,4500,,2673,1,,,,,,0*47
$PFLAA,1,4500,,2674,1,,,,,,0*40
$PFLAA,1,4500,,2673,1,,,,,,0*47
$PFLAA,1,4500,,2674,1,,,,,,0*40
$PFLAA,1,4500,,2673,1,,,,,,0*47
$PFLAA,1,4500,,2673,1,,,,,,0*47
$PFLAA,1,4500,,2765,1,,,,,,0*41
$PFLAA,1,4500,,2788,1,,,,,,0*42
$PFLAA,1,4500,,2803,1,,,,,,0*4E
$PFLAA,1,4500,,2825,1,,,,,,0*4A
$PFLAA,1,4500,,2841,1,,,,,,0*48

I disabled it (for SkyDemon), because it does not seem to be interpreted, I can easily re-enable
A different vendor does use the ICAO field in its display annotation (or the text following the '!' if present)

Thx
Lee

Are you saying it caused a problem in SkyDemon when it was enabled?

Tim,

You probably won't remember, but this was why I first contacted you about the display of bearingless targets 5 months ago. Lee will probably come on and clarify the position, but as far as I recall it went something like this.

In a development version of PilotAware, back in January, Lee introduced the small piggybacked aircraft to denote bearingless targets, which changed colour in a similar way to the Flarm rings to denote increasing threat level. IIRC at this time they displayed relative altitude and Reg. At a later date - I thought early March, but see below - Lee then introduced alternating Flight ID/Reg for both ADSB/P3i and bearingless targets, I think in response to a change you made to allow this in SkyDemon. This worked fine with ADSB (and P3i) targets (and still does), but interfered with the colour changes of the piggybacked bearingless aircraft, so Lee had to make a choice and opted for retaining the alternating Flight ID/Reg for both ADSB/P3i and Bearingless but we had to accept that the piggybacked aircraft no longer changed colour. I amongst others felt this was a retrograde step as we no longer had any visual indication of changing risk, though PilotAware now has direct audio warnings from the Raspberry Pi, which partly compensate for this loss.

Postscript: Just checked my screen grabs -  which confirm my recall was slightly awry. In the early January configuration, we got the piggybacked colour changing aircraft and relative altitude for 'bearingless' Mode S targets. By 16th January we had Aircraft Reg + relative altitude for bearingless targets, but the piggybacked aircraft had lost their colour and become white. I can't be specific re ADSB, but certainly by 16th January these were displaying alternating REG/Flight ID and relative altitude. I think it was trying to adopt the alternating Reg/Flight ID that stopped the piggybacked 'bearingless' aircraft from changing colour. Lee should be able to confirm this.

Lee subsequently decided to return  to the FLARM standard colour changing rings for bearingless targets in SkyDemon, but has allowed other Nav systems to display this information in their own way, by producing variable data sets for the different nav systems, selectable by PIN. (EVFR for example display multiple bearingless targets on colour changing warning banners at the top left of their screen with Aircraft Reg and other details displayed on the banners). For SkyDemon, he elected to suppress the alternating Flight ID/Reg presumably assuming this would still 'corrupt' the colour changing rings. If this is NOT the case, the general feeling within the PilotAware SD community is that adopting the alternating Fight ID/Reg for Bearingless to make them the same as ADSB/P3i would be beneficial for the reasons I stated in my earlier post. If alternating is possible, I think it's a fairly simple fix for Lee to re-enable this data. If alternating Flight ID/Reg is NOT possible for bearingless, I personally would favour fixed Aircraft Reg + Relative Altitude as we had back in late January (assuming this doesn't affect the colour changing rings) as this would cover most aircraft we are likely to encounter.

I know Lee has been very busy today, so will drop him a text to let him know you are asking for confirmation.

Regards

Peter

Alternating text for targets is a terrible idea. SkyDemon has never "supported" it, but it does show whatever is coming from the Flarm protocol, so we can't really stop it. The piggybacked aircraft was also a bad idea, as I had strong suspicions it would interfere with our collision detection code, but again, I can't stop a device from sending such fictitious aircraft data.

Flarm doesn't give any callsign or unique identifier for Mode S/C targets I don't think, possibly because there can only ever be one of them. It would be a very poor idea to try to depict more than one bearingless target.

I said it a few posts ago, but I will need sample protocol data in order to test whether SkyDemon can cope with callsign/unique identifier from a bearingless target, as this is something that doesn't happen in the Flarm protocol.

I would have to try again, but I think it ignored the 'threat level' part of the sentence, in other words, the rings were not color coded as red/yellow/green

I would have to try again to be certain

Thx
Lee

Hi Tim,

Alternating text for targets is a terrible idea...

This is a configuration option in PilotAware, the identifier can be set to :-
(a) Tail Reg
(b) Flight ID
(c) alternating a & b every 5 seconds
all under user control

I said it a few posts ago, but I will need sample protocol data in order to test whether SkyDemon can cope with callsign/unique identifier from a bearingless target, as this is something that doesn't happen in the Flarm protocol.

I did post some examples earlier in the thread.
Are you looking for the messages which would normally be sent to EVFR which contain the 'ICAO!Reg' fields ?

One other thought Rob (your colleague) has a PilotAware, you could run this up, connect and put it into TESTING mode which reduces the thresholds for the bearingless target sentence generation.

I can generate the data in whatever format you are happy consuming, so if you wish it to be the strict Flarm format - not containing and an Ident field for ICAO, thats fine, that is the way it works today, if you want the extended information of ICAO and Reg, this is easily added, I think you just need to state your requirement, and I will implement.

Thx
Lee