FLARM for SAR

On Tue, 30 Oct 2012 13:00:18 -0700, WaltWX wrote:

QUESTION: I recorded the NMEA output of the PF with my LK8000 software.
Do you know of any software or technique for playing back the NMEA
output into the PC simulator of my LK8000 so that I can see the FLARM
information and warnings?

Do you mean:

1)Can I capture the NMEA stream as it is being read by LK8000 so I can
replay it into LK8000 again at home.

2)Does LK8000 record the PF data in its IGC log so it can be replayed
later or examined by the FLARM range checker?


If you mean (1), I'd guess the only answers would be to use the PF's IGC
log (I can do that now with my LX Red Box FLARM and, no, I do NOT have
the IGC log certification firmware installed, just an SD card slot)
instead of the LK8000 log, or to buy, borrow or build a gizmo that is
connected between the PF and LK8000 and that records the NMEA sentences
as they flash through it.


OTOH if you mean (2), I don't know the answer, but there's an easy way to
check if the FLARM contact data is being captured by LK8000. Read the
LK8000 IGC log into your PC and open it with a text editor such as
WordPad. Then scroll down past the heading stuff until you find lines
starting with B. If FLARM contact data is being passed through to the IGC
log you'll see a *lot* of lines throughout the rest of the file that
start with LFLA followed by 36 characters of complete gibberish. In a
FLARM IGC log there is around one L line for every two or three that
start with B, so I'd expect something similar from LK8000 if its logging
this stuff.

Normally an LK8000 IGC log doesn't contain any L lines.


HTH

--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

Once again, your software is your property and nobody suggests that
you give that up for free, but the information in the IGC files of
each individual pilot should be open and readable by the pilot if he chooses to do so.
This would be the basis to provide such a service directly in
platforms like the OLC or SkyLines.

In case someone wants to fiddle with the LFLA records:

I found that it is some sort of base64 encoding of something binary, using ASCII 58-121, with the exception of \ and ^ (they are not allowed in an IGC file) according to Chapter 6. Those two are
probably replaced by # and %.

This decodes the 28 characters in the '02' records (those are used by the FLARM range checker). Into 21 bytes.
Pre-base64 bytes 5-11 effect the distance the FLARM checker reports.

It seems that FLARM ultimately took the wrong decision...

Two weeks ago Andrea Schlapbach from FLARM contacted me via email to discuss how we would want to use these data sentences. In the initial email he already clearly stated that "they had no interest in publishing the data format" and would only "share the format with a few interested and suited partners". "Suited partners" in their definition are those that are able to keep the format a secret.

In my answer I explained that XCSoar and SkyLines are both open source applications and that keeping a secret in open source code isn't really possible. I also asked what their intentions are for keeping the format a secret, but unfortunately that question was never answered. My second email answering some follow-up questions and asking the same thing again was never answered either.

I feel very sorry that FLARM has become such a closed-up proprietary company. I don't see any reason for keeping the data format a secret and I certainly hope that they reconsider this non-sense at some point. The only two reasons I can see for this is: a) they want to use the data commercially at some point or b) they are logging data that contains private data that shouldn't be logged in the first place. If they would really care about these SAR reasons they would simply open up their format so that any public party could use them...

I feel very sorry that FLARM has become such a closed-up proprietary
company.

I agree.
But I've also experienced not many manufacturers feel different about
being open. They feel the market for their hardware it too small to be
open about their products.

There are some notable exceptions: Borgelt, Funkwerk, Becker,
Garrecht, Butterfly avionics.

On Thursday, November 15, 2012 6:20:36 AM UTC-5, Tobias Bieniek wrote:
It seems that FLARM ultimately took the wrong decision...

According to whom ?

All you experts out the
Quick, list 5 bad things that could happen quickly
if the RF or PFLAL formats were public.
Hint: it has already been discussed ad nausea...

Did you misstype between bad and good Dave?

On Thursday, November 15, 2012 10:45:14 AM UTC-5, Roel Baardman wrote:
Did you misstype between bad and good Dave?

No.

At 11:20 15 November 2012, Tobias Bieniek wrote:
It seems that FLARM ultimately took the wrong decision...

Two weeks ago Andrea Schlapbach from FLARM contacted me via email to
discus=
s how we would want to use these data sentences. In the initial email he
al=
ready clearly stated that "they had no interest in publishing the data
form=
at" and would only "share the format with a few interested and suited
partn=
ers". "Suited partners" in their definition are those that are able to
keep=
the format a secret.

In my answer I explained that XCSoar and SkyLines are both open source
appl=
ications and that keeping a secret in open source code isn't really
possibl=
e. I also asked what their intentions are for keeping the format a
secret,
=
but unfortunately that question was never answered. My second email
answeri=
ng some follow-up questions and asking the same thing again was never
answe=
red either.

I feel very sorry that FLARM has become such a closed-up proprietary
compan=
y. I don't see any reason for keeping the data format a secret and I
certai=
nly hope that they reconsider this non-sense at some point. The only two
re=
asons I can see for this is: a) they want to use the data commercially at
s=
ome point or b) they are logging data that contains private data that
shoul=
dn't be logged in the first place. If they would really care about these
SA=
R reasons they would simply open up their format so that any public party
c=
ould use them...

Surely all you need is a qualified software engineer to read the output,
which you may have noticed is broadcast, and compare the raw output to what
is displayed in many of the magic apps that use it. It's called reverse
engineering, if you want to be posh or hacking if you don't. You can then
work out what the data sentences consist of and decde them. I spent many
years happily working doing just that some years ago, not with FLARM I
hasten to add.

What FLARM is doing is simply crypting the traffic info in their IGC logs.
All applications using FLARM data can do the same, the traffic information
is the same.
I am pretty sure that what a PNA receives is the same stuff that FLARM is
saving (encrypted) in the IGC.

The point here is that most pilots send to OLC their logs saved by LX,
Zander, Winpilot, Seeyou, LK8000, Xcsoar, etc.etc. and not necessarily from
their flarm units. For a SAR investigation you do need all logs from the
flarm units around, and this requires an active action to collect these logs
from pilots in the day of the accident.
Even knowing how to decrypting the IGC by FLARM, you still need to ask all
pilots to provide their Flarm logs, not their LX, Zander, etc.etc logs.

So, for SAR purposes knowing the encoding is not enough, you do need all
pilots to provide IGC logs from Flarm.
Then, why flarm is encoding-shuffling-cyphering these SAR valuable
informations, is beyond my understanding.
The only reason I can spot is they want to maintain a privileged position on
this matter, as they did with the communication protocol. After all, Flarm
units are about safety, SAR is safety, and this is a "safety" market, with a
monopolistic leader.

That's it..





"Don Johnstone" wrote in message
. com...

At 11:20 15 November 2012, Tobias Bieniek wrote:
It seems that FLARM ultimately took the wrong decision...

Two weeks ago Andrea Schlapbach from FLARM contacted me via email to
discus=
s how we would want to use these data sentences. In the initial email he
al=
ready clearly stated that "they had no interest in publishing the data
form=
at" and would only "share the format with a few interested and suited
partn=
ers". "Suited partners" in their definition are those that are able to
keep=
the format a secret.

In my answer I explained that XCSoar and SkyLines are both open source
appl=
ications and that keeping a secret in open source code isn't really
possibl=
e. I also asked what their intentions are for keeping the format a
secret,
=
but unfortunately that question was never answered. My second email
answeri=
ng some follow-up questions and asking the same thing again was never
answe=
red either.

I feel very sorry that FLARM has become such a closed-up proprietary
compan=
y. I don't see any reason for keeping the data format a secret and I
certai=
nly hope that they reconsider this non-sense at some point. The only two
re=
asons I can see for this is: a) they want to use the data commercially at
s=
ome point or b) they are logging data that contains private data that
shoul=
dn't be logged in the first place. If they would really care about these
SA=
R reasons they would simply open up their format so that any public party
c=
ould use them...

Surely all you need is a qualified software engineer to read the output,
which you may have noticed is broadcast, and compare the raw output to what
is displayed in many of the magic apps that use it. It's called reverse
engineering, if you want to be posh or hacking if you don't. You can then
work out what the data sentences consist of and decde them. I spent many
years happily working doing just that some years ago, not with FLARM I
hasten to add.

On Friday, November 16, 2012 4:14:15 AM UTC+1, pcool wrote:
Then, why flarm is encoding-shuffling-cyphering these SAR valuable
informations, is beyond my understanding.
The only reason I can spot is they want to maintain a privileged position on
this matter, as they did with the communication protocol. After all, Flarm
units are about safety, SAR is safety, and this is a "safety" market, with a
monopolistic leader.

Very well said, Paolo. Couldn't agree more.

FLARM is acting in their own commercial interest, not in the interest of aviation safety. Of course they do, they're a commercial company, they ultimately have to. It is worth pointing that out because many people still believe FLARM is all about safety, while the FLARM company protects its protocol in a (cold) patent war. (Google for the DSX T-Advisor story for more information)

By the way, FLARM wants us to log the LFLA sentences in XCSoar log files. We denied, and we may decide again when FLARM opens up the specification for everybody. We will not sign a NDA, because there must not be secrets in XCSoar. We're an open project, and we want to free the gliding world from proprietary manufacturers, not make it more proprietary and more reliant on a monopoly that is only just starting to act weird, who knows what they will do next.

By the way 2.0, using a FLARM may be illegal in Germany due to our very strict privacy laws.