FLARM for SAR

On Monday, November 19, 2012 9:15:06 PM UTC+1, Don Johnstone wrote:
Do you really need to solve the root cause? Would not getting round it have
the same effect. What is the problem you want to solve?

The problem is that glider pilots all around the world are building a dependency on proprietary technology, a monopoly that is protected by alleged patents. Depending on a commercial patent-protected monopoly is dangerous. In my opinion, basic technology should be free, even more so when it's all about aviation safety and when we discuss making it mandatory.

(This is my opinion, yours may be different, but mind that flaming and insulting me for expressing my opinion like this anonymous coward from Australia who calls himself "GC" did is just stupid.)

That was the problem with FLARM in general. In this thread, it's about using FLARM for another aviation safety thing that FLARM was not initially designed for. Good thing, clever idea, but the new problem here is that FLARM demands to keep full control over this feature. They are trying to enforce that nobody else but them can decode the files, and without FLARM's cooperation in every single case, nobody will be able to use the feature. My point about this is that this policy contradicts the goal of utmost safety.


Oh, and yes, I would like to solve the root cause. At least give it a try, and give FLARM a chance to prove me wrong. Therefore, I asked the FLARM guy in this thread to open the specification and share his code. FLARM could easily demonstrate their honest dedication to aviation safety by making all necessary information publically available. Let go of full control, and acknowledge that somewhere out there, somebody may exist who can improve their formulas further and help save more lifes. What I see instead is elitist FUD, sadly.

At 20:55 19 November 2012, wrote:
On Monday, November 19, 2012 9:15:06 PM UTC+1, Don Johnstone wrote:
Do you really need to solve the root cause? Would not getting round it
ha=
ve
the same effect. What is the problem you want to solve?

The problem is that glider pilots all around the world are building a
depen=
dency on proprietary technology, a monopoly that is protected by alleged
pa=
tents. Depending on a commercial patent-protected monopoly is dangerous.
In=
my opinion, basic technology should be free, even more so when it's all
ab=
out aviation safety and when we discuss making it mandatory.

I think you are giving FLARM too much credit. If pilots are building a
dependency on FLARM it is a bad idea, it is still dubious engineering using
unprotected radio frequencies subject to interference. Yes it works after a
fashion but in certain circumstances does more harm than good. It is at
best a small enhancement to situational awareness. It should never ever be
relied on.

(This is my opinion, yours may be different, but mind that flaming and
insu=
lting me for expressing my opinion like this anonymous coward from
Australi=
a who calls himself "GC" did is just stupid.)

That was the problem with FLARM in general. In this thread, it's about
usin=
g FLARM for another aviation safety thing that FLARM was not initially
desi=
gned for. Good thing, clever idea, but the new problem here is that FLARM
d=
emands to keep full control over this feature. They are trying to enforce
t=
hat nobody else but them can decode the files, and without FLARM's
cooperat=
ion in every single case, nobody will be able to use the feature. My
point
=
about this is that this policy contradicts the goal of utmost safety.

Given that the use to which you want to use FLARM (SAR) is not part of the
original concept then it is hardly surprising that there is no
infrastructure to support that use. If FLARM do not want to do it then
reverse engineer the parts you need and solve the problem. What you have to
appreciate is that we do not have large tracts of wilderness here in Europe
so there is little understanding of your particular problem and very little
incentive to provide a solution to a problem that for the majority of
Europe does not exist.


Oh, and yes, I would like to solve the root cause. At least give it a
try,
=
and give FLARM a chance to prove me wrong. Therefore, I asked the FLARM
guy=
in this thread to open the specification and share his code. FLARM could
e=
asily demonstrate their honest dedication to aviation safety by making
all
=
necessary information publically available. Let go of full control, and
ack=
nowledge that somewhere out there, somebody may exist who can improve
their=
formulas further and help save more lifes. What I see instead is elitist
F=
UD, sadly.
No, as I said before they are Swiss, they do not share. You are talking
about a mindset that thinks it is perfectly acceptable to refuse to
disclose the financial information about crimminals and terrorists, what do
you expect?

If you wait for FLARM to solve your problem it is not going to be solved.
Work on your own solution and cut out the middle man. Remember, the company
that makes FLARM, like all companies, is not about safety it is about
making money, preferably lots of it, for their shareholders and if at all
possible, making sure that no-one else can do what they do so ALL the
benefits come their way. It is called capitalism, and if I understand it
right, part of the American dream.

At 10:47 19 November 2012, wrote:
On Sunday, November 18, 2012 8:00:49 PM UTC+1, Don Johnstone wrote:
For crying out loud, just get some smart kid at MIT to reverse engineer
the
damm thing and have done with it.

One could do that, but it wouldn't solve the root cause of the problem. I
could try to explain it again, and I would if I were confident that you
are
really interested, but the polemic/aggressive wording of your reply
suggests otherwise.

Yes, one could do that. And get it completed just in time for the next
firmware upgrade to Flarm changes the coding and you have to start all over
again. This is how Flarm protect their Intellectual Property.

It is not just a question of doing it once, but at regular intervals.

It is threads like this that drives people and businesses away from RAS. I wonder how many of those attacking Flarm are flying with spots or similar devices which are much more effective for SAR.

Ramy

I think this is unlikely, as the format of the data in these records is quite likely the packet format on the air.
It appears to have changed a little from the specification from 2008 (what was post here at least), but not a whole lot.

I would not be surprised if these records are just packet dumps. This is consistent with the story of later on finding out what you can do with them.
Also, I wouldn't want to release their specification if I were to send them on air aswell. Encryption over the air was in 2008 not very complicated (and the processor used has little room for
complex encryption), so revealing this format (and thus the packet format on the air) again opens up the market for protocol-compatible devices. You could just brute-force the encryption using a
regular PC.

Disclaimer: this is all guessing from what I could read from the data. I haven't actually decoded these records. And I'm not sure I would want to, if it means Flarm will have to change formats
again.

Of course, what else could it be held inside that few characters?
Time of course, Flarm Id, lat-lon, altitude, speed, direction.
The whole story is about sorting out the flarm id from a long list of
collected logs, to understand when was the lost glider before it
disappeared.

The flarm protocol did not change, to my knowledge, after the latest
compulsory update.


"Roel Baardman" wrote in message
...

I think this is unlikely, as the format of the data in these records is
quite likely the packet format on the air.
It appears to have changed a little from the specification from 2008 (what
was post here at least), but not a whole lot.

I would not be surprised if these records are just packet dumps. This is
consistent with the story of later on finding out what you can do with them.
Also, I wouldn't want to release their specification if I were to send them
on air aswell. Encryption over the air was in 2008 not very complicated (and
the processor used has little room for
complex encryption), so revealing this format (and thus the packet format on
the air) again opens up the market for protocol-compatible devices. You
could just brute-force the encryption using a
regular PC.

Disclaimer: this is all guessing from what I could read from the data. I
haven't actually decoded these records. And I'm not sure I would want to, if
it means Flarm will have to change formats
again.

At 11:50 20 November 2012, pcool wrote:
Of course, what else could it be held inside that few characters?
Time of course, Flarm Id, lat-lon, altitude, speed, direction.
The whole story is about sorting out the flarm id from a long list of
collected logs, to understand when was the lost glider before it
disappeared.

The flarm protocol did not change, to my knowledge, after the latest
compulsory update.

Actually all that is needed is ID, time, position (lat/long), and altitude
everything else can be calculated from that data using consecutive fixes,
exactly what a logger does and who has not seen maggot racing?. Breaking
code where the contents of the encoded message are unknown can be a long
process however where you know exactly what the message should be cracking
the code is very very easy.
It all depends on how badly you want to do it and whether using FLARM for
SAR purposes is the best way to go when there are other better suited
devices on the market.
Having said that an instrument that takes on the functionality of FLARM and
SPOT, with the security and reliabilty that such critical devices should
have, would be a major contribution to safety but where is anyone going to
recoup the developement costs? Not from glider pilots that is for sure, the
market is just too small.
So what we have is glider specific instruments, produced with minimal
development costs and almost no certified quality control or an instrument
produced for the GA with official certification, and all the expense that
entails, and never the twain shall meet.




"Roel Baardman" wrote in message
...

I think this is unlikely, as the format of the data in these records is
quite likely the packet format on the air.
It appears to have changed a little from the specification from 2008 (what

was post here at least), but not a whole lot.

I would not be surprised if these records are just packet dumps. This is
consistent with the story of later on finding out what you can do with
them.
Also, I wouldn't want to release their specification if I were to send
them

on air aswell. Encryption over the air was in 2008 not very complicated
(and
the processor used has little room for
complex encryption), so revealing this format (and thus the packet format
on
the air) again opens up the market for protocol-compatible devices. You
could just brute-force the encryption using a
regular PC.

Disclaimer: this is all guessing from what I could read from the data. I
haven't actually decoded these records. And I'm not sure I would want to,
if
it means Flarm will have to change formats
again.

On Tuesday, November 20, 2012 3:30:04 PM UTC-5, Don Johnstone wrote:
At 11:50 20 November 2012, pcool wrote:

Of course, what else could it be held inside that few characters?

Time of course, Flarm Id, lat-lon, altitude, speed, direction.

The whole story is about sorting out the flarm id from a long list of

collected logs, to understand when was the lost glider before it

disappeared.



The flarm protocol did not change, to my knowledge, after the latest

compulsory update.



Actually all that is needed is ID, time, position (lat/long), and altitude

everything else can be calculated from that data using consecutive fixes,

exactly what a logger does and who has not seen maggot racing?. Breaking

code where the contents of the encoded message are unknown can be a long

process however where you know exactly what the message should be cracking

the code is very very easy.

It all depends on how badly you want to do it and whether using FLARM for

SAR purposes is the best way to go when there are other better suited

devices on the market.

Having said that an instrument that takes on the functionality of FLARM and

SPOT, with the security and reliabilty that such critical devices should

have, would be a major contribution to safety but where is anyone going to

recoup the developement costs? Not from glider pilots that is for sure, the

market is just too small.

So what we have is glider specific instruments, produced with minimal

development costs and almost no certified quality control or an instrument

produced for the GA with official certification, and all the expense that

entails, and never the twain shall meet.









"Roel Baardman" wrote in message

...



I think this is unlikely, as the format of the data in these records is

quite likely the packet format on the air.

It appears to have changed a little from the specification from 2008 (what



was post here at least), but not a whole lot.



I would not be surprised if these records are just packet dumps. This is

consistent with the story of later on finding out what you can do with

them.

Also, I wouldn't want to release their specification if I were to send

them



on air aswell. Encryption over the air was in 2008 not very complicated

(and

the processor used has little room for

complex encryption), so revealing this format (and thus the packet format

on

the air) again opens up the market for protocol-compatible devices. You

could just brute-force the encryption using a

regular PC.



Disclaimer: this is all guessing from what I could read from the data. I

haven't actually decoded these records. And I'm not sure I would want to,

if

it means Flarm will have to change formats

again.





I don't understand all the discussion over how/why to contort FLARM's purpose into SAR application when there are much better devices already purposed with emergency location. The FLARM folks shouldn't be badgered / forced to support every hacker wanting to try their hand at SAR software. Just use a Spot or ELT and be done with it.

-Jim