On Tuesday, January 21, 2020 at 3:12:18 PM UTC-5, Martin Gregorie wrote:
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 the many message specifications with which I've ever worked, comments
have always been used as a dumping ground for anything and everything that
was needed by someone but not included in the specification.
For example SWIFT messages ;-)

The users (in this case logger manufacturers) always get ahead of the
standardization, especially if the standards process is not hugely
responsive or takes too long. SWIFT for example had a one year comment
period, then a one year test cycle (anyway decades ago when I worked
on that stuff). You'd really prefer SWIFT not to break, hence the caution ;-)

Sometimes the comment overload becomes standardized, leading to further
confusion. See for example PLT below.

The PLT/OOI/PFC stuff was standardized to allow persistent additional info
in the log (ie your comments, entered in your favorite flight review sw),
without deranging the security system.

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.

RedBox, as a dozen other devices, contain a FLARM OEM module with FLARM software. Hence the results had better be similar ;-)

Hope that helps!
Best Regards, Dave