Message compatibility with AirTrafficDisplay 57 from Air Avionics

[Andreas Titze]

Hi group,

I recently tried to connect a T-Beam with MB180 SoftRF and attached GNS5892R to a Traffic Display AirTrafficDisplay from Air Avionics via the serial link. It would get the position data and react to the Test Alarm but not show any traffic.

Turns out the $PFLAA Message must not have any callsign information in it.

Got the tip from Moshe, disabled it and it works!

pflaa_cs,0         # 1=yes 0=no

Maybe a useful info for someone

Andreas

[Bumpff Slam]

Neither $PFLAA or $PFLAU Flarm sentences have the aircraft callsign.  However, both have the ID which is a unique 6-digit hex identifier (either the aircraft's ICAO code, the default equipment ID or what someone has set).  Flarm and SoftRF displays use a table file from FlarmNet or OGN to look up the aircraft registration based on the ID.  See Flarm Technical Document FTD-012 which includes following examples:

$PFLAU,2,1,2,1,1,-90,2,50,75,1A304C*       FLARM is working properly and receives two other aircraft. The most dangerous of these aircraft has the ID “1A304C” and it is at 9 o’clock, position 50m above and 75m away. Level 1 alarm.

$PFLAA,0,-1234,1234,220,2,DD8F12,180,,30,-1.4,1*    There is a glider in the south-east direction, 1.7km away (1.2km south, 1.2km east), 220m higher flying on south track with a ground speed of 30m/s in a slight left turn with 4.5°/s turning rate, sinking with 1.4m/s. Its ID is a static FLARM-ID “DD8F12”. There is no danger.   

[Moshe Braner]

SoftRF, by default, send out the PFLAA like this:

$PFLAA,0,-1234,1234,220,2,DD8F12!FLR_DD8F12,180,,30,-1.4,1*

where the FLR_ means it is a FLARM-protocol device (it would be FAN_ for FANET, etc), and then the ID, DD8F12in this case, is repeated.  If there is callsign information, from a database or from transmssions (FANET, ADS-B), it is sent instead of the second copy of the ID.  I don't know where this idea started and which devices receiving these sentences make good use of it.  It is not FLARM standard, and some devices are confused by it.  That is why I added the pflaa_cs setting, to allow turning that off.

[Bumpff Slam]

I'm puzzled by how SkyView handles the extended length ID field in the $PFLAA sentence that Moshe has revealed.  Looking at the Soft RF SkyView code, I don't understand how it can handle the extended ID since when TinyGPSCustom is used to parse the sentence, I would expect it to return the entire ID code between the commas as T_ID.  But this would then cause the NMEAhelper.CPP code a problem at: if(T_ID is updated(){fo.ID=strtol (T_ID.value(), Null, 16)]  since the string is not just the 6 digit ID.

[Moshe Braner]

Maybe because the strtol() function "takes as many characters as possible to form a valid base-n (where n=base) integer number representation and converts them to an integer value"

https://en.cppreference.com/cpp/string/byte/strtol

[Bumpff Slam]

I asked co-pilot and the answer is:   "In C++ (and C), the strtol function stops parsing as soon as it encounters a character that is not valid for the given base."  So when it gets to the '!" in the extended ID (eg  DD8F12!FLR_DD8F12) it stops parsing and performs the conversion on the characters found to that point.  So it's because of the Strtol function that this odd ID encoding works with SkyView.