On Thursday, May 28, 2015 at 2:16:55 PM UTC-7, Tango Eight wrote:
On Thursday, May 28, 2015 at 4:00:06 PM UTC-4, Buddy Bob wrote:
At 18:35 28 May 2015, pcool wrote:
There is no "predictive" algorithm.

This does appear to be true.. The previous flarm protocol is
documented here

http://tinyurl.com/opgtogo

I haven't personally verified (all) of it, but it certainly has all the
marking that it is correct, and there really doesn't appear to be any
'prediction' there at all. A similar document for the new protocol exists
too, it shouldn't be too hard for you to find it.

I would like comments from those who said there was prediction. What
made you think there was, how does this change your thinking and
have you heard the tale of the Emperor's New Clothes?

Two flarm equipped gliders fly parallel to one another at 80 kts with 300' separation and -- as long as the flight paths are not convergent -- flarm gives no alarm. If the paths become convergent, alarms result very quickly. As soon as the paths become parallel or divergent, the alarms cease. The same two gliders now fly a head on approach, again at 80 kts. Flarm gives a warning at significant range... over a mile... and the warning ceases almost immediately when one glider changes his track. From this I believe it should be clear to anyone that the way flarm works is most likely just how they've said it works: by estimating what airspace any given glider is capable of occupying in the next +/-30 seconds and looking for potential conflicts.

-Evan Ludeman / T8

Yes. I'm surprised this is even coming up, except as a deliberate effort to obfuscate important differences between the various technologies and why they may not be compatible.

Anyone with a rudimentary knowledge of aircraft dynamics and even a single day's flying with FLARM has to conclude that it is making path-dependent collision prediction estimates. You have to fly in a few thermals to pick up that the path prediction is curved when you are turning.

Flarm engineers have told me explicitly that the prediction is done on the transmit side and I can see why this would work better for the reasons previously raised. The specification may or may not need to specify this as a communications protocol generally needn't include a specification of the data payload or the algorithm to create or interpret it.

9B