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? :-)

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

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

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

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

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,

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