FLARM for SAR

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.

Gerhard,

Yesterday, Jim Staniforth ASW-27 JS and I, Walt Rogers Discus 2A WX, compared the performance of our PF Brick (V 2.40)during 11/2hrs of flying. See OLC posting for 10/29/2012. Overall, we were satisfied with performance. It correctly alarmed or warned in every case with 5-10 seconds notice in one case of a simulated head-on. Range was 2-3sm consistently and intermittently 5-6sm highly dependent on orientation of the gliders. Jim's ASW-27 antenna installation used the Peter Kelly technique placing the dipoles on the inside vertically within the nose. My Discus 2A used dipoles vertically installed (not touching panel cover or canopy) on the instrument cover.

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?

Walt Rogers, WX

On Tuesday, October 30, 2012 2:08:16 AM UTC-7, wrote:
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.



Tobias,



we're actually discussing this internally.



Best

--Gerhard

Walt, thanks for the feedback!

The question below would rather be for LX. If you look for anything
specifically, you can send me the logs by email!

Best
--Gerhard
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?

XCSoar simulation does that. I expected LK should do as well?
-kh

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?

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.