Hi Guys,

As I have said before elsewhere, with the minimal info we get for bearing less targets, clear indication of threat level (colour changing icons of whatever style - I can live with rings) is essential, as is relative altitude to 'direct' visual search and prompt potential action to maintain or increase separation. Anything else (e.g. Reg) is a bonus which just might help in locating the threat but not essential.

I'm sure the two of you will be able to agree the best way forward. We are all very grateful and are counting on you both.

Best regards

Peter

Hi Tim

OK, understand.
Let me dig out some examples which contain the identifier, although you can pretty much fake these up by adding in the ICAO and Reg into the correct field, eg, if the identifier is "40526F!G-PAWZ"
then something like ...
$PFLAA,1,4500,,2841,1,40526F!G-PAWZ,,,,,0*48
(NB, the Checksum will be incorrect for this)

Thx
Lee

One thing I would ask, which I've mentioned on Flyer, PilotAware, at AeroExpo but now on here (!), would it be possible to have the option of the flight ID/relative altitude appearing in a white box, maybe with a black border? The contrast of the existing fields isn't good with a background map and makes them very difficult to read. Having them in a white box which blanks out of the background map would be better, especially for the bearingless altitude which appears in a seemingly random place around the ring.

Having these things stand out would make it instantly readable rather than having to stare and squint.

Ta!

Hi Shifu

it had no signal on his little traffic box

Can you tell me what 'little traffic box' your fellow pilot was using ?

I feel it is incumbent upon the suppliers of this type of technology to stress the need for good airmanship.
When accepting the license agreement with PilotAware there is a huge banner explaining the use policies.
I am very interested to know the circumstances of use.

I like to push a reminder into this circle

I am not sure what you mean here, this is in the forefront of my mind, in fact, here is a posting I made recently on this very subject
http://forums.flyer.co.uk/viewtopic.php?t=101106&start=45#p1474702
If you think there is more we could do, I would be interested in your feedback, but may be better placed on the PilotAware forum rather than cluttering the SkyDemon forum

Thx
Lee

Hi Tim,

OK, I have generated 2 logs

mode_cs_id.trk
This contains the ID field, I double checked, and in the NAV display you ALWAYS have a grey/white ring, irrespective of the threat level value

mode_cs_no_id.trk
This does not contain the ID field, and the rings are red/yellow/green accordingly based upon the threat level.

In the trk files you will see some extra NMEA style messages for instance
$PAWRT
these are not sent to the navigation device, its only in the logging format, this is to describe the received data for the ID, using a boolean of the form
$PAWRT,<ID>,Mode-A,Mode-C,Mode-S,ADS-B,P3I,FLARM,<checksum>

So for your usage I would seggest 'grepping' out the PFLAA messages
Please let me know if you need more info

Thx
Lee

Hi Shifu



Could you PM me his contact details, I know of no such technology which is capable of receiving all of these formats.
PilotAware in conjunction with FlarmMouse is capable of all these (except Mode-A), but that version is not yet released!


Yes we would support this, are you referring to an RF standard, or a Traffic Format standard ?
There is disparity in both, for example 
RF - US (1090Mhz, 978Mhz, 915Mhz-FHSS), Europe (1090Mhz, 868Mhz)
Traffic - GDL90(open), GDL39(closed), FlarmDataport(open)

I think an RF standard will be near impossible to standardise - especially as FLARM Encrypt their data,
but a common Traffic format would be an acheivable goal.

Thx
Lee

For Mode A detection based purely on signal strength, could there be some sort of field fed to Sky Demon which would, when received, print something like "N/A" for the Alt readout in the software?

As an aside, looking at my previous forum post, it says:

Forum Newbie

Group: Forum Members
Posts: 1, Visits: 0

Zero visits and one post? How does that work? :-)

Thanks, Lee. I can confirm that when SkyDemon saw the ! that I specified be used as a delimited for our protocol extension to feed callsigns through, it reset the "threat level" to unspecified because that ! also triggers our own internal collision detection code. Since that code doesn't run for bearingless targets, I have modified the Flarm parser to not reset the "threat level" you pass when it's a bearingless target. Incidentally, now that you are (presumably) running your own on-device collision detection code (to power your audible alerts) do you also send Flarm protocol alerts through too, and a meaningful "threat level" for positioned targets?

I have also modified the text rendering so it's the same size, and uses the same black-on-yellow glow, as the positioned targets. The position of the text remains unchanged, which is to draw it on the outside of the "circle of probability" in the direction that you are currently travelling.

Paul, we would consider adding a white background behind the traffic details if enough people asked, but my feeling is that it would obscure much more of the map if we did that. When it comes to rendering other traffic we are very mindful of what things will be like when everybody is broadcasting their location (what we ultimately want). I think to have such a solid background, when we get to that wonderful stage, would not be ideal.