On Tue, 21 Jan 2020 14:54:13 +0000, Jim White wrote:

At 09:13 21 January 2020, Martin Gregorie wrote:
On Mon, 20 Jan 2020 17:01:24 -0800, Dan Daly wrote:

On Monday, January 20, 2020 at 7:46:03 PM UTC-5, Tijl wrote:
That wouldn't circumvent manual Flarm-ID changes at any given moment
within the flight (with an LX9000 connection for instance).

You can also quickly power your Flarm off an on after take-off,
thereby
creating a new random ID.

I am sure if the IGC asks for it, FLARM can quickly bring out a
feature
that triggers a ID-randomizer every 15 minutes during the flight. But
that would not even be necessary in my opinion.


Also, if the punishment of having a private ground-based Flarm
receiver
in a team is disqualification for the whole team, and if the rules on
this are 100% clear and widely known, who in their right mind would
do this?

I would be surprised if changing the ICAO ID didn't violate the IGC
file
security and validation.

Its not recorded anywhere in an ICG flight log, so no problem there.

I've written and tested a Java class for decoding IGC logs, so needed to
understand precisely what's in every record type (except the G record,
whose exact format is logger-specific. Thats because the checksum format
is not defined by the standard: its specified and known only by the
manufacturer.


--
Martin | martin at Gregorie | gregorie dot org


Below is detail from my Flarm generated IGC trace:

LFLA111322011 LFLA111323 STEALTH OFF LFLA111323ID 2 DDE24

As you can see it does show my ICAO number. You are however correct that
Log records (prefixed by L) are not used when generating the G record
for integrity checking.

Hi Jim,

According to the second edition, 3rd amendment of the "TECHNICAL
SPECIFICATION FOR GNSS FLIGHT RECORDERS" dated 30 June 2014, the L record
is defined as a 'logbook' or 'comment' where the hardware source defines
the format of everything in the L record from the 5th character onward.

In your example L records, the first letter will always be
'L' (obviously!). The next three letters are a manufacturer code (in this
case FLA, so the rest of its content is in a FLARM-defined format. The
only GNSS-defined source codes a

PLT (pilot input),
OOI (Official Observer input),
PFC (after-flight pilot input).

So it follows that any other code identifies the hardware manufacturer
whose kit wrote the IGC log. The definition includes a list of approved
codes.

I understand your point, but the GNSS standard is a little more complex
when talking about validation; it says that L records with a
manufacturers ID in characters 2-4 *must* be included in the validation
check but those with PLT, OOI or PFC codes *must not* be included,
presumably because they're expected to be unformatted free text.

My take on this is that, since LFLA records are defined by FLARM, then
there's no guarantee that L records output by any other manufacturers kit
will contain an ICAO number or, indeed, that an non-FLARM log will
contain any L records.

I've just searched my personal IGC log connection, which are all
recorded by LK8000, XCSOAR, LK8000, my EW Microrecorder or an EW model D
I used to own. None of these contain any L records. However, logs from my
RedBox FLARM contain huge numbers of them - roughly one L record for
every 3.5 B records. The nearest set of L records in it that I can see to
your three records a

LFLA111458011
LFLA111459 STEALTH OFF
LFLA111459 NOTRACK OFF
LFLA111459ID 2 DDD4EF

which are preceded by 18 unintelligible (to me, anyway) L records and
followed 14 L records that look very much like the contents of my
flarmcfg.txt file combined by some of the stuff in the FLARMDEV.CSV file,
which was generated by my RedBox, and which contains the warning:

Auto-generated file, don't edit!

I haven't configured my FLARM box with an ICAO ID since AFAIK I don't
have one. The ID it seems to have assumed, DDD4EF, is defined in the
autogenerated file, FLARMDEV.CSV

My reason for writing this stuff is that I'm curious how similar the
output from my old RedBox is to what FLARM systems from other instrument
makers put in IGC logs that they generate.


--
Martin | martin at
Gregorie | gregorie dot org