Help us with this petition for security on anti-collision systems

What Flarm calls "prediction" I think that most likely is a simple
projection. It is quite likely calculated worst than how we calculate the
best point to turn in thermal.
I am referring to the "Beep" in Zanders, or in some flight computers .
If you want to see how a "prediction" is working, look at the thermal
Orbiter I have programmed
https://github.com/LK8000/LK8000/blo...lc/Orbiter.cpp
which is quite similar to what Zander and SeeYou Mobile (and possibly other
software, I don't really know) do.
This is a prediction based on turning angle, estimated banking etc. and I
mention it here for a reason:
there is floating point math involved in such kind of predictions.
We use 400mhz or best ARM cpu on PNA-PDAs.
Flarm is tuned to "predict" on a 8mhz CPU by Atmel, a reduced instruction
set microcontroller that has no math coprocessor and cannot do floating
point calculations natively.

A prediction seems like something magic, and I doubt this is the case.
Each device (flarm, dsx) transmits its own position "predicted" with a
simple projection for the next second .
If your own device matches its own "predicted" position with the one
received from another one, it beeps.
That's how it works.
A projection cannot predict when you level and go straight, nevertheless as
you say it works .
It can not work "very well", as you say. But it is better than nothing.

The assumption is that the glider in thermal with you, or arriving in front
of you, has a device with the same protocol.
In the alps this is no more granted. This is what this thread is about.

greets
paolo




"Tango Eight" wrote in message
...

On Tuesday, May 26, 2015 at 7:44:07 PM UTC-4, Lucas wrote:

Tango Eight, your statement is lacking of a scientific base: WHAT
demonstrates that the "prediction algorithm works very well" ?

*Extensive* end user experience.

This might be helpful: http://en.wikipedia.org/wiki/Straw_man

best regards,
Evan Ludeman / T8

On Wednesday, May 27, 2015 at 7:46:25 PM UTC-7, pcool wrote:

The assumption is that the glider in thermal with you, or arriving in front
of you, has a device with the same protocol.
In the alps this is no more granted. This is what this thread is about.

Wow, why would people buy an incompatible device when there are multiple manufacturers of compatible devices in the market?

On Thursday, 28 May 2015 07:05:42 UTC+2, Andy Blackburn wrote:
Wow, why would people buy an incompatible device when there are multiple manufacturers of compatible devices in the market?

What would happen if the relationship soured between FLARM and the manufacturer of your chosen FLARM device?
Flarm could easily issue another upgrade to the protocol and you are left with a $1000+ system which is now totally worthless and useless.

Who is incompatible with who? You have the freedom to choose a device
manufacturer.
The TAdvisor, and probably the OGN devices soon, are not worst than flarm to
do this job.
Anyway, as a wise guy ("Buddy Bob") here stated, shortly we may have OGN
devices acting as collision avoidance systems.
At that point Flarm will change its protocol and adopt the open one.

I fully agree with Bob, it is pointless to ask Flarm to open the protocol.
What we need is several other manufacturers selling their own devices, based
on the OGN open software for example. I have not signed the petition for
this reason.


"Andy Blackburn" wrote in message
...

On Wednesday, May 27, 2015 at 7:46:25 PM UTC-7, pcool wrote:

The assumption is that the glider in thermal with you, or arriving in
front
of you, has a device with the same protocol.
In the alps this is no more granted. This is what this thread is about.

Wow, why would people buy an incompatible device when there are multiple
manufacturers of compatible devices in the market?

On Thu, 28 May 2015 14:22:41 +0200, pcool wrote:

I fully agree with Bob, it is pointless to ask Flarm to open the
protocol. What we need is several other manufacturers selling their own
devices, based on the OGN open software for example. I have not signed
the petition for this reason.

IIRC the reason that FLARM encrypted the protocol was that the OGN crew
were refusing to honour the 'do not track' bit thus exposing the
whereabouts of people who didn't want to be tracked.

In view of that record, why should we trust OGN to do the right thing?

I won't sign the petition either. If DSX want to sell anti-collision kit,
let them drop their NIH attitude and join LX etc in using the de-facto
standard protocol. As long as FLARM sell licences to allow third parties
to use it they are no better or worse than, e.g. Oracle with their
proprietary attitude to Java or the companies who hold patents that
widely used wireless comms standards depend on: think WiFi.

BTW, has the DSX protocol been published? On a Creative Commons or GPL
license?


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

At 12:47 28 May 2015, Martin Gregorie wrote:
On Thu, 28 May 2015 14:22:41 +0200, pcool wrote:

I fully agree with Bob, it is pointless to ask Flarm to open the
protocol. What we need is several other manufacturers selling their own
devices, based on the OGN open software for example. I have not signed
the petition for this reason.

IIRC the reason that FLARM encrypted the protocol was that the OGN crew
were refusing to honour the 'do not track' bit thus exposing the
whereabouts of people who didn't want to be tracked.

In view of that record, why should we trust OGN to do the right thing?

Firstly, the Easter Egg was built into the previous version of FLARM
firmware long before OGN can into being. OGN was not the cause. As I
understand it the Easter Egg was to ensure that users were on reasonably
up-to-date Firmware.

Secondly, any transmissions received by an OGN Receiver that have the
Do-Not-Track bit set are discarded at the receiver. There are never sent to
the Server.

I won't sign the petition either. If DSX want to sell anti-collision kit,

let them drop their NIH attitude and join LX etc in using the de-facto
standard protocol. As long as FLARM sell licences to allow third parties
to use it they are no better or worse than, e.g. Oracle with their
proprietary attitude to Java or the companies who hold patents that
widely used wireless comms standards depend on: think WiFi.

BTW, has the DSX protocol been published? On a Creative Commons or GPL
license?

On Thu, 28 May 2015 13:58:39 +0000, Tim Newport-Peace wrote:

Firstly, the Easter Egg was built into the previous version of FLARM
firmware long before OGN can into being. OGN was not the cause. As I
understand it the Easter Egg was to ensure that users were on reasonably
up-to-date Firmware.

By Easter Egg, do you mean the protocol expiry date? If so its not what I
was talking about and I don't have a problem with it: given that FLARM
was designed for small, low-powered hardware, syncing protocol version
that way makes a helluva lot more sense that having to maintain backward
compatibility over the last 'n' protocol versions just because some lazy
git can't be bothered to keep his software up to date.

Secondly, any transmissions received by an OGN Receiver that have the
Do-Not-Track bit set are discarded at the receiver. There are never sent
to the Server.

Not necessarily: you can't guarantee anything like that if the receiver
is the result of a third party reverse engineering project, which is what
I've always heard about the RPi-hosted FLARM receiver units. If the
software author decides he wants to see everybody and ignores that bit
then pop goes your invisibility cloak.


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

At 22:44 28 May 2015, Martin Gregorie wrote:
On Thu, 28 May 2015 13:58:39 +0000, Tim Newport-Peace wrote:

Firstly, the Easter Egg was built into the previous version of FLARM
firmware long before OGN can into being. OGN was not the cause. As I
understand it the Easter Egg was to ensure that users were on
reasonably
up-to-date Firmware.

By Easter Egg, do you mean the protocol expiry date? If so its not what I

was talking about and I don't have a problem with it: given that FLARM
was designed for small, low-powered hardware, syncing protocol version
that way makes a helluva lot more sense that having to maintain backward
compatibility over the last 'n' protocol versions just because some lazy
git can't be bothered to keep his software up to date.

Secondly, any transmissions received by an OGN Receiver that have the
Do-Not-Track bit set are discarded at the receiver. There are never
sent
to the Server.

Not necessarily: you can't guarantee anything like that if the receiver
is the result of a third party reverse engineering project, which is what

I've always heard about the RPi-hosted FLARM receiver units. If the
software author decides he wants to see everybody and ignores that bit
then pop goes your invisibility cloak.

In which case it is not an OGN receiver any longer.

"Don’t believe anything you read on the net. Except this.
Well, including this, I suppose."

DOUGLAS ADAMS (1952-2001)

At 12:22 28 May 2015, pcool wrote:
Who is incompatible with who? You have the freedom to choose a device
manufacturer.
The TAdvisor, and probably the OGN devices soon, are not worst than flarm
to
do this job.
Anyway, as a wise guy ("Buddy Bob") here stated, shortly we may have OGN
devices acting as collision avoidance systems.

OGN Trackers work on a different frequency, so will not interface to Flarm
or DSX.

At that point Flarm will change its protocol and adopt the open one.

Oh?

Even if Flarm did open their encoding, DSX is still not Flarm-compatible.
The do not have the predictive algorithm that Flarm does.

The differances are too great.

I fully agree with Bob, it is pointless to ask Flarm to open the protocol.

What we need is several other manufacturers selling their own devices,
based
on the OGN open software for example. I have not signed the petition for

this reason.

Are there any DSX devices in US? One might supose so judging by the number
of responses from US pilots, but I doubt it.

On Thursday, May 28, 2015 at 9:00:06 AM UTC-4, Tim Newport-Peace wrote:


Even if Flarm did open their encoding, DSX is still not Flarm-compatible.
The do not have the predictive algorithm that Flarm does.


That's not true (logically). One need only have open transmission of 3D location, velocity, turn rate. The predictive element of things is done on the receiving end and need not be symmetric. Better predictive capability yields fewer nuisance alarms.

Most US guys, I think, never heard of DSX until this thread. Did DSX and Flarm have an agreement or did they just hack the protocol?


regards,
Evan Ludeman / T8