PowerFLARM Range Issues - Part Two with info from todays flights

[Mark]

I had a chance to load a new config file and was able to fly today.

There was no "flarm range" in my original config file. With the file I used today the "flarm range" config was set to maximum with the statement below. I had several flarm detections that occured around 4 miles. This is between 2x and 3x what I experienced before so this is a noticable improvement. Still not 6 or 8 miles, but a nice improvement.

I re-set the PCAS ranges and the ADSB ranges and the PCAS function improved only a very small amount. I am still flying with my Zaon pcas and it reported many aircraft that the PowerFlarm did not show at all. A 172 that passed nearby was under 1 mile horizontal and if I remember the Flarm showed it around 1 mile. However it lost the contact only a few moments after it first reported the contact. I did see the towplane on PowerFlarm PCAS but a no more than 1 mile range.

After I put the glider back in the hanger I received one ADSB signal from an aircraft that was 8,000 feet higher and over 10 miles away. Since ADSB comes in on the same antenna that the PCAS receives on I think it's likely that the radio circuit and antenna are working fine and that there is real potential to improve the PCAS via the software.

I didn't see the message about the additional lines in the config file until tonight, but if I fly again this weekend I'll try to test those too.

The one pilot in our group who did not update his config file did not see the 4 mile Flarm performance so it appears that the "as shipped" settings in the brick may be limiting the performance.

The key elements in the config file that I used today are as follows:

# PCAS (transponder) range (meters)
$PFLAC,S,PCASRANGE,10000

# PCAS (transponder) vertical range (meters)
$PFLAC,S,PCASVRANGE,1000

# ADSB range (meters)
$PFLAC,S,ADSBRANGE,65535

# ADSB vertical range (meters)
$PFLAC,S,ADSBVRANGE,65535

# FLARM range (meters)
$PFLAC,S,RANGE,65535


I don't know what settings Flarm intended to have in the units as "as shipped" but I will encourage them to ship units with maximums. Far better to start off with more info and warnings and then pull back than fly around 1/2 blind.

More testing and reports as weather and opportunity present.

One side note, the data dump file that appeared on my USB stick after flying appears to be corrupted. When I got early dump files when I had just received the unit the files appeared neatly arranged with no extra characters. Currently there is tons of gibberish in the file. Not knowing how that file is created or appended, is there a way to reset or clear the file within the brick and hope for less gibberish? Might also just be my USB stick too.

Mark

[noel.wade]

Mark and others -

Its been said many times in a few forums and websites (and I'm annoyed
they do not include it on a big red or yellow piece of paper in the
box):
YOU MUST NOT USE THE PowerFLARM UNITS (Brick or Portable) RIGHT "OUT
OF THE BOX". You *MUST* apply a configuration file, with your
aircraft's ID value in the config file. This is CRITICAL!!!

The reason is this: ADS-B (and thus FLARM) tracks your glider based on
your airplane's unique ICAO value. There are instructions on how to
find this and apply it to your config file. If you do not do this,
your FLARM will use a "default" (dummy) identifier. FLARM ignores
every signal with the same identifier as your own, to keep from
alerting you about your own position (for example, if you have a
transponder or install ADS-B out).

That means every other FLARM that is still set to the "default"
identifier will be ignored (because they all match) and you will never
see them on your FLARM display!! And the "other guy" will never see
you on his/her display!! Very, very bad.

[And yes, this is one area where I think the PowerFLARM folks could do
a better job with documentation and warning the purchaser. On the one
hand, its a complicated device that's doing a lot and its not a simple
install - so people should read instructions carefully. But on the
other hand you have to expect in this day and age that people are
going to assume something is "Plug and Play" unless you warn them off
- strongly.]

--Noel

[noel.wade]

P.S. Should clarify that I was typing in all-caps to try to catch
people's eye; not to yell at you, Mark.

[Ramy]

Noel, are you sure about that? If I recall correct, this parameter is optional for mode S users, and Flarm defaults to Flarm ID if you don't supply one, which is different for each unit. This is the first time I hear this explanation.
But I agree that one must configure the unit first. A friend flew without configuring his unit and we could only detect each other when circling together, I am not completely sure why. Also his display showed constant transponder alert from his own transponder.

Ramy

[noel.wade]

On Oct 5, 10:14*pm, Ramy > wrote:
> Noel, are you sure about that? If I recall correct, this parameter is optional for mode S users, and Flarm defaults to Flarm ID if you don't supply one, which is different for each unit. This is the first time I hear this explanation.
> But I agree that one must configure the unit first. A friend flew without configuring his unit and we could only detect each other when circling together, I am not completely sure why. Also his display showed constant transponder alert from his own transponder.
>
> Ramy

Ramy - Maybe they fixed this in newer deliveries... I was warned
about this (along with many others) by a west-coast FLARM dealer; and
was able to confirm that two PFs in close proximity with default
settings didn't see each other; but that was back in June. I haven't
had to touch the config on my PF since Nationals so perhaps my info on
the defaults is out of date (would be a good thing if it is, I
suppose)!

--Noel

[pcool]

If your PowerFlarm can use the Flarmnet database, then you are granted that
it is based on unique ID, embedded in each single delivered unit.
This is how it works in Europe, at least.


"noel.wade" wrote in message
...

On Oct 5, 10:14 pm, Ramy > wrote:
> Noel, are you sure about that? If I recall correct, this parameter is
> optional for mode S users, and Flarm defaults to Flarm ID if you don't
> supply one, which is different for each unit. This is the first time I
> hear this explanation.
> But I agree that one must configure the unit first. A friend flew without
> configuring his unit and we could only detect each other when circling
> together, I am not completely sure why. Also his display showed constant
> transponder alert from his own transponder.
>
> Ramy

Ramy - Maybe they fixed this in newer deliveries... I was warned
about this (along with many others) by a west-coast FLARM dealer; and
was able to confirm that two PFs in close proximity with default
settings didn't see each other; but that was back in June. I haven't
had to touch the config on my PF since Nationals so perhaps my info on
the defaults is out of date (would be a good thing if it is, I
suppose)!

--Noel

[[email protected]]

Noel,

We did read and follow the instructions and DID load the config file. The point is that in the config file they include with the instructions they do NOT include all the available parameters which can be set. So if you don't know that the "secret" parameters can be set then my point is the manufacturer should set those to a maximum number and not to some smaller number.

This very issue led to us following their "instuctions" and getting 25% of the range we could have gotten. Might have saved a lot of hassle.

Mark

[FLARM]

You do NOT need to set the ICAO ID, unless you carry a Mode S transponder (where it helps to suppress your own transponder signal).
So yes, PowerFLARM WILL work 'straight out of the box'.
Do not set the *wrong* ICAO ID.... for obvious reasons.
Setting aircraft type ('Glider' for you guys and gals) correctly will ensure that the alarm algorithms treat you properly. If you configure as 'helicopter' and circle in a gaggle of gliders you and all others will get many annoying warnings.
It's a feature, not a bug... ;-)
PowerFLARM.us has sample configuration files which are easy to adapt for your taste.

As for setting the range to maximum as factory default:
We have many users who fly in very dense airspace. The default ranges ensure that they are only warned about aircraft that may become dangerous and there is no unnecessary distraction.

[bumper[_4_]]

For those of us who don't relish the "opportunity" to dive in and experiment with config files and such . . . Butterfly has a free config file builder that does it for you using a multiple choice format that even I can figure out.

http://www.butterfly-avionics.com/index.php/en/products/powerflarm-en/powerflarm-core-config-en

bumper

[[email protected]]

Mark and everybody,

The range defaults in PowerFLARM 2.40 are as follows:

FLARM: unlimited horizontal/1000ft vertical (*)
PCAS: 4NM horizontal/2000ft vertical
ADS-B: unlimited

(*) The vertical FLARM range cannot be changed.

Additional sensitivity restrictions for both FLARM and PCAS/ADS-B apply.

All values can be reset to the defaults using

$pflac,defaults

> There was no "flarm range" in my original config file. With the file I used today the "flarm range" config was set to maximum with the statement below. I had several flarm detections that occured around 4 miles. This is between 2x and 3x what I experienced before so this is a noticable improvement. Still not 6 or 8 miles, but a nice improvement.

That's a strong hint that there was something wrong with your configuration.. Glad that
it works better now.

> After I put the glider back in the hanger I received one ADSB signal from an aircraft that was 8,000 feet higher and over 10 miles away. Since ADSB comes in on the same antenna that the PCAS receives on I think it's likely that the radio circuit and antenna are working fine and that there is real potential to improve the PCAS via the software.

Yes, that indicates that your installation is otherwise OK.

> The one pilot in our group who did not update his config file did not see the 4 mile Flarm performance so it appears that the "as shipped" settings in the brick may be limiting the performance.

See above for defaults.

> $PFLAC,S,PCASRANGE,10000

This is above 5NM and will be ignored (note to myself: it should be set to the maximum
instead, will fix that).

> $PFLAC,S,PCASVRANGE,1000

OK
> $PFLAC,S,ADSBRANGE,65535

OK

> $PFLAC,S,ADSBVRANGE,65535

OK, but I'd recommend to reduce it to values useful for traffic awareness
in order to reduce clutter.

> $PFLAC,S,RANGE,65535

OK

> More testing and reports as weather and opportunity present.

Thanks in advance!

> One side note, the data dump file that appeared on my USB stick after flying appears to be corrupted. When I got early dump files when I had just received the unit the files appeared neatly arranged with no extra characters. Currently there is tons of gibberish in the file. Not knowing how that file is created or appended, is there a way to reset or clear the file within the brick and hope for less gibberish? Might also just be my USB stick too.

Can you send my your original flarmcfg.txt and the dump file by personal mail?

Best
--Gerhard
--
Dr. Gerhard Wesp
Development Manager, Avionics
FLARM Technology GmbH
Switzerland
CH-020.4.033.059-8

[noel.wade]

On Oct 6, 5:51*am, FLARM > wrote:
> You do NOT need to set the ICAO ID, unless you carry a Mode S transponder (where it helps to suppress your own transponder signal).
> So yes, PowerFLARM WILL work 'straight out of the box'.

OK, I stand corrected (and happily so).

Bonus points to Butterfly for the "configurator" tool!

--Noel

[[email protected]]

Dump file figured out. It appears that I inherited a bad command for creating the dignostic file, possibly it's a different command for the European Flarm. Anyway, with the correct command, the output is back to gibberish free...

[[email protected]]

On Saturday, October 6, 2012 11:11:32 AM UTC-5, bumper wrote:
> For those of us who don't relish the "opportunity" to dive in and experiment with config files and such . . . Butterfly has a free config file builder that does it for you using a multiple choice format that even I can figure out.
>
>
>
> http://www.butterfly-avionics.com/index.php/en/products/powerflarm-en/powerflarm-core-config-en
>
>
>
> bumper

As a side note, and perhaps Gerhard can comment on the correctness of my statement. The link above creates a file, but if you select the dump file option it puts in a command that I suspect resulted in my receiving gibberish in the output file. When I replaced the "dump" command with the statement below I got clear info again.

$debug_out,fat,scheduler|config|baro|rf|gps|pffsm, all

Mark

[Ramy]

I am sure I have seen Flarm traffic much more than +/- 1000 feet or even 1000m. So not sure if it is a typo or a new restriction. Hopefully the former as it is very helpful to be able to detect gliders at much more than 1000 feet difference when buddy flying.

Ramy

[[email protected]]

>
> $debug_out,fat,scheduler|config|baro|rf|gps|pffsm, all

PowerFLARM can log to the internal file system (4 megabytes)
or directly to SD card (Portable) or USB stick (Brick); which typically
is above one gigabyte.

$debug_out,.... activates the second option.
$file,dump dumps the content of the internal file system to the
SD/USB, in binary ('gibberish') form.

If you send me the gibberish, I can analyse it. :)

Best
--Gerhard

--
Dr. Gerhard Wesp
Development Manager, Avionics
FLARM Technology GmbH
Switzerland
CH-020.4.033.059-8

[kirk.stant]

On Sunday, October 7, 2012 1:08:39 AM UTC-5, wrote:
> >
>
> > $debug_out,fat,scheduler|config|baro|rf|gps|pffsm, all
>
>
>
> PowerFLARM can log to the internal file system (4 megabytes)
>
> or directly to SD card (Portable) or USB stick (Brick); which typically
>
> is above one gigabyte.
>
>
>
> $debug_out,.... activates the second option.
>
> $file,dump dumps the content of the internal file system to the
>
> SD/USB, in binary ('gibberish') form.
>
>
>
> If you send me the gibberish, I can analyse it. :)

Gerhart, the PowerFLARM CORE Configurator has an option to "Write a diagnostic dump-file to the USB-stick." When that is selected, you get the "$file,dump" command in your config file. Perhaps a note that this dumps data in binary would be helpful?

And add an option in the Configurator to add the

"$debug_out,fat,scheduler|config|baro|rf|gps|pffsm, all"

command to the config file, instead?

Kirk
66

[Andy[_1_]]

On Oct 5, 9:19*pm, "noel.wade" > wrote:

YOU MUST NOT USE THE PowerFLARM UNITS (Brick or Portable) RIGHT "OUT
OF THE BOX". You *MUST* apply a configuration file, with your
aircraft's ID value in the config file. This is CRITICAL!!!


Nonsense!

The default configuration assumes you gave no transponder and your
unit is identified it's own unique FLARM ID.

In big letters so you read it - EVERY FLARM HAS A UNIQUE ID

Only if you have a mode S transponder do you need to change your ID
from the default FLARM ID to the mode S ICAO aircraft address.

GY

[[email protected]]

Ramy,

> I am sure I have seen Flarm traffic much more than +/- 1000 feet or even 1000m. So not sure if it is a typo or a new restriction. Hopefully the former as it is very helpful to be able to detect gliders at much more than 1000 feet difference when buddy flying.

It's actually 500m, I stand corrected. (The 300m are for 'info' alerts).

Correct me if I'm wrong, but if you saw traffic at more than +-500m then
it would only be intermittently. This was a bug rather than a feature
and I found it actually quite annoying in flight tests. We decided
to enforce the limit at +-500m

Traffic at more than +-500m typically doesn't present a collision danger (we don't equip skydivers.... yet). Displaying it increases
distraction and head-down time, both of which are contrary to FLARMs primary goal of avoiding mid-airs.

In the future, we may add support for traffic with very fast vertical movement.

Best
--Gerhard
--
Gerhard Wesp
Development Manager, Avionics
FLARM Technology GmbH
Baar, Switzerland
CH-020.4.033.059-8

[kirk.stant]

On Tuesday, October 9, 2012 2:20:10 AM UTC-5, wrote:

> In the future, we may add support for traffic with very fast vertical movement.

It might be interesting if one could select specific gliders to always display, via flarmnet, regardless of range or altitude. Useful for team flying, or just following your friends around.

Thank you for keeping us informed on the status of PowerFLARM development.

Cheers,

Kirk
66

[Ramy]

On Tuesday, October 9, 2012 12:20:10 AM UTC-7, wrote:
> Ramy,
>
>
>
> > I am sure I have seen Flarm traffic much more than +/- 1000 feet or even 1000m. So not sure if it is a typo or a new restriction. Hopefully the former as it is very helpful to be able to detect gliders at much more than 1000 feet difference when buddy flying.
>
>
>
> It's actually 500m, I stand corrected. (The 300m are for 'info' alerts).
>
>
>
> Correct me if I'm wrong, but if you saw traffic at more than +-500m then
>
> it would only be intermittently. This was a bug rather than a feature
>
> and I found it actually quite annoying in flight tests. We decided
>
> to enforce the limit at +-500m
>
>
>
> Traffic at more than +-500m typically doesn't present a collision danger (we don't equip skydivers.... yet). Displaying it increases
>
> distraction and head-down time, both of which are contrary to FLARMs primary goal of avoiding mid-airs.
>
>
>
> In the future, we may add support for traffic with very fast vertical movement.
>
>
>
> Best
>
> --Gerhard
>
> --
>
> Gerhard Wesp
>
> Development Manager, Avionics
>
> FLARM Technology GmbH
>
> Baar, Switzerland
>
> CH-020.4.033.059-8

This surprises me, as I always see flarm traffic much more than 500m above or below (especially when flying high above the airport, I can still see targets on the ground). While obviously not needed for collision, it is very useful for buddy flying or when trying to locate thermals, and I know that many pilots are using flarm for buddy flying. This is disappointing if the vertical range will be reduced to only 500m, and I am not sure I see the point in it. As long as there is no audio alert there is no need to look at the display, correct? so why limiting the range? Or at least make it configurable like ADS-B and PCAS ranges, so it will be pilot choice. I don't get it.

[[email protected]]

Ramy,

> As long as there is no audio alert there is no need to look at the display, correct?

This is correct, yes. On the other hand, if a pilot uses the display to detect
buddies, this does require a focus and attention change and increases
head-down time.

We're considering making the vertical range configurable for future
versions. There are other factors involved, though, amongst them
processing limitations and compatibility with Classic FLARM.

Best
--Gerhard
--
Gerhard Wesp
Development Manager, Avionics
FLARM Technology GmbH
Baar, Switzerland
CH-020.4.033.059-8

[Eric Greenwell[_4_]]

On 10/10/2012 5:57 AM, wrote:
>> As long as there is no audio alert there is no need to look at the display, correct?
> This is correct, yes. On the other hand, if a pilot uses the display to detect
> buddies, this does require a focus and attention change and increases
> head-down time.

Detecting your buddies by using the radio is even more distracting, in
my experience. It's not just my distraction when I call or listen to my
buddies, also the distraction of hearing other groups of buddies trying
find each other.

--
Eric Greenwell - Washington State, USA (change ".netto" to ".us" to
email me)

[Bob Whelan[_3_]]

On 10/10/2012 11:24 AM, Eric Greenwell wrote:
> On 10/10/2012 5:57 AM, wrote:
>>> As long as there is no audio alert there is no need to look at the display,
>>> correct?
>> This is correct, yes. On the other hand, if a pilot uses the display to detect
>> buddies, this does require a focus and attention change and increases
>> head-down time.
>
> Detecting your buddies by using the radio is even more distracting, in my
> experience. It's not just my distraction when I call or listen to my buddies,
> also the distraction of hearing other groups of buddies trying find each other.
>

"Indeed," (he says, having zero experience w. P-Flarm). But I think Dr. Vesp's
point was the Flarm folks have little desire to go "off target"
(developmentally speaking), "target" being anti-collision detection/alerts.

Hey! Come to think of it that might not be a bad idea when it comes to radio
use, either!!! (Let there be no glider-initiated calls containing anything
more than "Here I am [and by implication, don't hit me]." Arguably, everything
else is "frequency clutter".

Bob - it's starting to feel like winter! - W.

[[email protected]]

On Wednesday, October 10, 2012 10:24:25 AM UTC-7, Eric Greenwell wrote:
> On 10/10/2012 5:57 AM, wrote:
>
> >> As long as there is no audio alert there is no need to look at the display, correct?
>
> > This is correct, yes. On the other hand, if a pilot uses the display to detect
>
> > buddies, this does require a focus and attention change and increases
>
> > head-down time.
>
>
>
> Detecting your buddies by using the radio is even more distracting, in
>
> my experience. It's not just my distraction when I call or listen to my
>
> buddies, also the distraction of hearing other groups of buddies trying
>
> find each other.
>
>
>
> --
>
> Eric Greenwell - Washington State, USA (change ".netto" to ".us" to
>
> email me)

I am with both Ramy and Eric on this. I am also surprised.

It is troubling to me that Flarm is making this filtering decisions for us. It should not. The Flarm unit must send out any and all traffic it sees, unless explicitly filtered by the user.

For example, I can foresee a range of products where the filtering is done in an external unit where the pilot can further select what he wants to see.. And the output is actual voice/auditory so there is no heads down at all! Your current scheme would hinder these kind of applications. I think this would be possible today in applications such as XCSoar running on a Dell Streak.

In addition, as Eric just mentioned, Flarm can actually help cut down the ever increasing amount of distracting radio chatter by tema flying pilots which affects everyone's concentration while flying.

Yes, I understand Flarm intended this to be a collision avoidance product. But the fact is that Flarm is really a position beacon and hopefully getting into most gliders. Very powerful concept. We cannot just ignore what the market is asking for.

Apple initially did not intend for the iPhone to run any third party apps :)

Please think about that.

With Best Regards,

David

[[email protected]]

On Wednesday, 10 October 2012 18:40:47 UTC+1, wrote:
> On Wednesday, October 10, 2012 10:24:25 AM UTC-7, Eric Greenwell wrote:
>
> > On 10/10/2012 5:57 AM, wrote:
>
> >
>
> > >> As long as there is no audio alert there is no need to look at the display, correct?
>
> >
>
> > > This is correct, yes. On the other hand, if a pilot uses the display to detect
>
> >
>
> > > buddies, this does require a focus and attention change and increases
>
> >
>
> > > head-down time.
>
> >
>
> >
>
> >
>
> > Detecting your buddies by using the radio is even more distracting, in
>
> >
>
> > my experience. It's not just my distraction when I call or listen to my
>
> >
>
> > buddies, also the distraction of hearing other groups of buddies trying
>
> >
>
> > find each other.
>
> >
>
> >
>
> >
>
> > --
>
> >
>
> > Eric Greenwell - Washington State, USA (change ".netto" to ".us" to
>
> >
>
> > email me)
>
>
>
> I am with both Ramy and Eric on this. I am also surprised.
>
>
>
> It is troubling to me that Flarm is making this filtering decisions for us. It should not. The Flarm unit must send out any and all traffic it sees, unless explicitly filtered by the user.
>
>
>
> For example, I can foresee a range of products where the filtering is done in an external unit where the pilot can further select what he wants to see. And the output is actual voice/auditory so there is no heads down at all! Your current scheme would hinder these kind of applications. I think this would be possible today in applications such as XCSoar running on a Dell Streak.
>
>
>
> In addition, as Eric just mentioned, Flarm can actually help cut down the ever increasing amount of distracting radio chatter by tema flying pilots which affects everyone's concentration while flying.
>
>
>
> Yes, I understand Flarm intended this to be a collision avoidance product.. But the fact is that Flarm is really a position beacon and hopefully getting into most gliders. Very powerful concept. We cannot just ignore what the market is asking for.
>
>
>
> Apple initially did not intend for the iPhone to run any third party apps :)
>
>
>
> Please think about that.
>
>
>
> With Best Regards,
>
>
>
> David

To perceive that "the fact is that Flarm is really a position beacon" and to "foresee a range of products where the filtering is done in an external unit" is to fundamentally misunderstand it. (I am talking here about the Flarm collision awareness aspect of PowerFlarm and not the ADSB components.)

Flarm works by broadcasting highly tailored predictions of a glider's future flight path and comparing that with the broadcast predictions from other Flarm equipped gliders. The fact that it is not simply a position beacon is central to how it operates. In order that both/all involved receive compatible warnings it is necessary for all units to be using compatible algorithms - otherwise one glider could receive a conflict warning while the other does not. This aspect has been discussed endlessly in Europe with regard to the proprietary nature of the Flarm algorithm. If a company wanted to piggy-back a glider collision warning product on the Flarm frequencies then I suspect that it would have to contend with legal challenges from Flarm and, more importantly, convince potential purchasers that it has written prediction algorithms as sophisticated as those that Flarm has spent many years developing and proving.

Irrespective of the teething issues have emerged with the "Power" aspects of Butterfly PowerFlarm product, Flarm itself in Europe has proved itself to be highly successful in attracting attention to an approaching glider that may not have been seen. IMHO it is very unlikely that an alternative will emerge in the foreseeable future. What there is a strong market for is various alternative displays of Flarm collision data (i.e. computed by Flarm and output to the display) on third party specialised displays or included in Nav programs - e.g. I use the SeeYou Mobile Flarm display for buddy or soaring situation awareness and the simple European LED Flarm display + SYM voice for conflict awareness.

John Galloway

[[email protected]]

On Wednesday, October 10, 2012 11:48:20 AM UTC-7, (unknown) wrote:
> On Wednesday, 10 October 2012 18:40:47 UTC+1, wrote:
>
> > On Wednesday, October 10, 2012 10:24:25 AM UTC-7, Eric Greenwell wrote:
>
> >
>
> > > On 10/10/2012 5:57 AM, wrote:
>
> >
>
> > >
>
> >
>
> > > >> As long as there is no audio alert there is no need to look at the display, correct?
>
> >
>
> > >
>
> >
>
> > > > This is correct, yes. On the other hand, if a pilot uses the display to detect
>
> >
>
> > >
>
> >
>
> > > > buddies, this does require a focus and attention change and increases
>
> >
>
> > >
>
> >
>
> > > > head-down time.
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > Detecting your buddies by using the radio is even more distracting, in
>
> >
>
> > >
>
> >
>
> > > my experience. It's not just my distraction when I call or listen to my
>
> >
>
> > >
>
> >
>
> > > buddies, also the distraction of hearing other groups of buddies trying
>
> >
>
> > >
>
> >
>
> > > find each other.
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > --
>
> >
>
> > >
>
> >
>
> > > Eric Greenwell - Washington State, USA (change ".netto" to ".us" to
>
> >
>
> > >
>
> >
>
> > > email me)
>
> >
>
> >
>
> >
>
> > I am with both Ramy and Eric on this. I am also surprised.
>
> >
>
> >
>
> >
>
> > It is troubling to me that Flarm is making this filtering decisions for us. It should not. The Flarm unit must send out any and all traffic it sees, unless explicitly filtered by the user.
>
> >
>
> >
>
> >
>
> > For example, I can foresee a range of products where the filtering is done in an external unit where the pilot can further select what he wants to see. And the output is actual voice/auditory so there is no heads down at all! Your current scheme would hinder these kind of applications. I think this would be possible today in applications such as XCSoar running on a Dell Streak.
>
> >
>
> >
>
> >
>
> > In addition, as Eric just mentioned, Flarm can actually help cut down the ever increasing amount of distracting radio chatter by tema flying pilots which affects everyone's concentration while flying.
>
> >
>
> >
>
> >
>
> > Yes, I understand Flarm intended this to be a collision avoidance product. But the fact is that Flarm is really a position beacon and hopefully getting into most gliders. Very powerful concept. We cannot just ignore what the market is asking for.
>
> >
>
> >
>
> >
>
> > Apple initially did not intend for the iPhone to run any third party apps :)
>
> >
>
> >
>
> >
>
> > Please think about that.
>
> >
>
> >
>
> >
>
> > With Best Regards,
>
> >
>
> >
>
> >
>
> > David
>
>
>
> To perceive that "the fact is that Flarm is really a position beacon" and to "foresee a range of products where the filtering is done in an external unit" is to fundamentally misunderstand it. (I am talking here about the Flarm collision awareness aspect of PowerFlarm and not the ADSB components.)
>
>
>
> Flarm works by broadcasting highly tailored predictions of a glider's future flight path and comparing that with the broadcast predictions from other Flarm equipped gliders. The fact that it is not simply a position beacon is central to how it operates. In order that both/all involved receive compatible warnings it is necessary for all units to be using compatible algorithms - otherwise one glider could receive a conflict warning while the other does not. This aspect has been discussed endlessly in Europe with regard to the proprietary nature of the Flarm algorithm. If a company wanted to piggy-back a glider collision warning product on the Flarm frequencies then I suspect that it would have to contend with legal challenges from Flarm and, more importantly, convince potential purchasers that it has written prediction algorithms as sophisticated as those that Flarm has spent many years developing and proving.
>
>
>
> Irrespective of the teething issues have emerged with the "Power" aspects of Butterfly PowerFlarm product, Flarm itself in Europe has proved itself to be highly successful in attracting attention to an approaching glider that may not have been seen. IMHO it is very unlikely that an alternative will emerge in the foreseeable future. What there is a strong market for is various alternative displays of Flarm collision data (i.e. computed by Flarm and output to the display) on third party specialised displays or included in Nav programs - e.g. I use the SeeYou Mobile Flarm display for buddy or soaring situation awareness and the simple European LED Flarm display + SYM voice for conflict awareness.
>
>
>
> John Galloway

You misunderstood what I wrote. I was *not* referring to the filtering Flarm does for the purpose of collision resolution. I was referring to the filtering it does for traffic that is currently not a threat and that pilots could use for purposes stated elsewhere in this thread. And for which, I repeat, I do think there is a potenital market for third party products.

I thought I was very clear about that by acknowledging I understood the original purpose of Flarm. I am not advocating that third party devices implement the complex collision detection algorithms Flarm has developed. Although in theory there is no reason they couldn't, or even improve on them.


David

[[email protected]]

On Wednesday, October 10, 2012 12:03:47 PM UTC-7, wrote:
> On Wednesday, October 10, 2012 11:48:20 AM UTC-7, (unknown) wrote:
>
> > On Wednesday, 10 October 2012 18:40:47 UTC+1, wrote:
>
> >
>
> > > On Wednesday, October 10, 2012 10:24:25 AM UTC-7, Eric Greenwell wrote:
>
> >
>
> > >
>
> >
>
> > > > On 10/10/2012 5:57 AM, wrote:
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > >> As long as there is no audio alert there is no need to look at the display, correct?
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > > This is correct, yes. On the other hand, if a pilot uses the display to detect
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > > buddies, this does require a focus and attention change and increases
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > > head-down time.
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > Detecting your buddies by using the radio is even more distracting, in
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > my experience. It's not just my distraction when I call or listen to my
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > buddies, also the distraction of hearing other groups of buddies trying
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > find each other.
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > --
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > Eric Greenwell - Washington State, USA (change ".netto" to ".us" to
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > email me)
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > I am with both Ramy and Eric on this. I am also surprised.
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > It is troubling to me that Flarm is making this filtering decisions for us. It should not. The Flarm unit must send out any and all traffic it sees, unless explicitly filtered by the user.
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > For example, I can foresee a range of products where the filtering is done in an external unit where the pilot can further select what he wants to see. And the output is actual voice/auditory so there is no heads down at all! Your current scheme would hinder these kind of applications. I think this would be possible today in applications such as XCSoar running on a Dell Streak.
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > In addition, as Eric just mentioned, Flarm can actually help cut down the ever increasing amount of distracting radio chatter by tema flying pilots which affects everyone's concentration while flying.
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > Yes, I understand Flarm intended this to be a collision avoidance product. But the fact is that Flarm is really a position beacon and hopefully getting into most gliders. Very powerful concept. We cannot just ignore what the market is asking for.
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > Apple initially did not intend for the iPhone to run any third party apps :)
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > Please think about that.
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > With Best Regards,
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > David
>
> >
>
> >
>
> >
>
> > To perceive that "the fact is that Flarm is really a position beacon" and to "foresee a range of products where the filtering is done in an external unit" is to fundamentally misunderstand it. (I am talking here about the Flarm collision awareness aspect of PowerFlarm and not the ADSB components.)
>
> >
>
> >
>
> >
>
> > Flarm works by broadcasting highly tailored predictions of a glider's future flight path and comparing that with the broadcast predictions from other Flarm equipped gliders. The fact that it is not simply a position beacon is central to how it operates. In order that both/all involved receive compatible warnings it is necessary for all units to be using compatible algorithms - otherwise one glider could receive a conflict warning while the other does not. This aspect has been discussed endlessly in Europe with regard to the proprietary nature of the Flarm algorithm. If a company wanted to piggy-back a glider collision warning product on the Flarm frequencies then I suspect that it would have to contend with legal challenges from Flarm and, more importantly, convince potential purchasers that it has written prediction algorithms as sophisticated as those that Flarm has spent many years developing and proving.
>
> >
>
> >
>
> >
>
> > Irrespective of the teething issues have emerged with the "Power" aspects of Butterfly PowerFlarm product, Flarm itself in Europe has proved itself to be highly successful in attracting attention to an approaching glider that may not have been seen. IMHO it is very unlikely that an alternative will emerge in the foreseeable future. What there is a strong market for is various alternative displays of Flarm collision data (i.e. computed by Flarm and output to the display) on third party specialised displays or included in Nav programs - e.g. I use the SeeYou Mobile Flarm display for buddy or soaring situation awareness and the simple European LED Flarm display + SYM voice for conflict awareness.
>
> >
>
> >
>
> >
>
> > John Galloway
>
>
>
> You misunderstood what I wrote. I was *not* referring to the filtering Flarm does for the purpose of collision resolution. I was referring to the filtering it does for traffic that is currently not a threat and that pilots could use for purposes stated elsewhere in this thread. And for which, I repeat, I do think there is a potenital market for third party products.
>
>
>
> I thought I was very clear about that by acknowledging I understood the original purpose of Flarm. I am not advocating that third party devices implement the complex collision detection algorithms Flarm has developed. Although in theory there is no reason they couldn't, or even improve on them.
>
>
>
>
>
> David

Perhaps an example might help illustrate what I mean.

An external device connected to the Flarm data port into which I can enter the code of a glider I am flying with. Every 10 minutes (for example), as long as he is within Flarm range, I hear a natural voice report where my buddy is: "XY is 20 degrees to your left at 5 miles, 5000 feet".

Similarly, you get low, need a thermal. A buddy, "ZW" is thermaling 3 miles from you, within Flarm range. You enter his code into the third party device or app and you get a voice vector to his thermal.

No conflict with the core Flarm collision alert system. Ne heads down. Pure value added.

David

[Ramy]

On Wednesday, October 10, 2012 12:03:47 PM UTC-7, wrote:
> On Wednesday, October 10, 2012 11:48:20 AM UTC-7, (unknown) wrote:
>
> > On Wednesday, 10 October 2012 18:40:47 UTC+1, wrote:
>
> >
>
> > > On Wednesday, October 10, 2012 10:24:25 AM UTC-7, Eric Greenwell wrote:
>
> >
>
> > >
>
> >
>
> > > > On 10/10/2012 5:57 AM, wrote:
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > >> As long as there is no audio alert there is no need to look at the display, correct?
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > > This is correct, yes. On the other hand, if a pilot uses the display to detect
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > > buddies, this does require a focus and attention change and increases
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > > head-down time.
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > Detecting your buddies by using the radio is even more distracting, in
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > my experience. It's not just my distraction when I call or listen to my
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > buddies, also the distraction of hearing other groups of buddies trying
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > find each other.
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > --
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > Eric Greenwell - Washington State, USA (change ".netto" to ".us" to
>
> >
>
> > >
>
> >
>
> > > >
>
> >
>
> > >
>
> >
>
> > > > email me)
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > I am with both Ramy and Eric on this. I am also surprised.
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > It is troubling to me that Flarm is making this filtering decisions for us. It should not. The Flarm unit must send out any and all traffic it sees, unless explicitly filtered by the user.
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > For example, I can foresee a range of products where the filtering is done in an external unit where the pilot can further select what he wants to see. And the output is actual voice/auditory so there is no heads down at all! Your current scheme would hinder these kind of applications. I think this would be possible today in applications such as XCSoar running on a Dell Streak.
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > In addition, as Eric just mentioned, Flarm can actually help cut down the ever increasing amount of distracting radio chatter by tema flying pilots which affects everyone's concentration while flying.
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > Yes, I understand Flarm intended this to be a collision avoidance product. But the fact is that Flarm is really a position beacon and hopefully getting into most gliders. Very powerful concept. We cannot just ignore what the market is asking for.
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > Apple initially did not intend for the iPhone to run any third party apps :)
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > Please think about that.
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > With Best Regards,
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > David
>
> >
>
> >
>
> >
>
> > To perceive that "the fact is that Flarm is really a position beacon" and to "foresee a range of products where the filtering is done in an external unit" is to fundamentally misunderstand it. (I am talking here about the Flarm collision awareness aspect of PowerFlarm and not the ADSB components.)
>
> >
>
> >
>
> >
>
> > Flarm works by broadcasting highly tailored predictions of a glider's future flight path and comparing that with the broadcast predictions from other Flarm equipped gliders. The fact that it is not simply a position beacon is central to how it operates. In order that both/all involved receive compatible warnings it is necessary for all units to be using compatible algorithms - otherwise one glider could receive a conflict warning while the other does not. This aspect has been discussed endlessly in Europe with regard to the proprietary nature of the Flarm algorithm. If a company wanted to piggy-back a glider collision warning product on the Flarm frequencies then I suspect that it would have to contend with legal challenges from Flarm and, more importantly, convince potential purchasers that it has written prediction algorithms as sophisticated as those that Flarm has spent many years developing and proving.
>
> >
>
> >
>
> >
>
> > Irrespective of the teething issues have emerged with the "Power" aspects of Butterfly PowerFlarm product, Flarm itself in Europe has proved itself to be highly successful in attracting attention to an approaching glider that may not have been seen. IMHO it is very unlikely that an alternative will emerge in the foreseeable future. What there is a strong market for is various alternative displays of Flarm collision data (i.e. computed by Flarm and output to the display) on third party specialised displays or included in Nav programs - e.g. I use the SeeYou Mobile Flarm display for buddy or soaring situation awareness and the simple European LED Flarm display + SYM voice for conflict awareness.
>
> >
>
> >
>
> >
>
> > John Galloway
>
>
>
> You misunderstood what I wrote. I was *not* referring to the filtering Flarm does for the purpose of collision resolution. I was referring to the filtering it does for traffic that is currently not a threat and that pilots could use for purposes stated elsewhere in this thread. And for which, I repeat, I do think there is a potenital market for third party products.
>
>
>
> I thought I was very clear about that by acknowledging I understood the original purpose of Flarm. I am not advocating that third party devices implement the complex collision detection algorithms Flarm has developed. Although in theory there is no reason they couldn't, or even improve on them.
>
>
>
>
>
> David

David, your post was very clear. You are the voice of reason. Wish I could be as clear (and polite) as you. Now lets hope folks are listening.

Ramy

[[email protected]]

> Similarly, you get low, need a thermal. A buddy, "ZW" is thermaling 3 miles from you, within Flarm range. You enter his code into the third party device or app and you get a voice vector to his thermal.
>
>
>
> No conflict with the core Flarm collision alert system. Ne heads down. Pure value added.

There *is* head-down time in this example. First, you have to identify ZW
on the display and figure out that he's actually climbing. Focus and attention
change, 2-3 seconds? Second, 'you enter his code into the third party device'---that's user interaction, potentially distracting you for 10+ seconds.

As I said, we *are* considering making the vertical range considerable, also in
view of other applications. However, simply outputting all traffic that we see
is not an option and has never been implemented either, neither in Classic nor in PowerFLARM.

Best
--Gerhard

[David A]

On Oct 12, 12:10*am, wrote:
> > Similarly, you get low, need a thermal. A buddy, "ZW" is thermaling 3 miles from you, within Flarm range. You enter his code into the third party device or app and you get a voice vector to his thermal.
>
> > No conflict with the core Flarm collision alert system. Ne heads down. Pure value added.
>
> There *is* head-down time in this example. *First, you have to identify ZW
> on the display and figure out that he's actually climbing. *Focus and attention
> change, 2-3 seconds? *Second, 'you enter his code into the third party device'---that's user interaction, potentially distracting you for 10+ seconds.
>
> As I said, we *are* considering making the vertical range considerable, also in
> view of other applications. *However, simply outputting all traffic that we see
> is not an option and has never been implemented either, neither in Classic nor in PowerFLARM.
>
> Best
> --Gerhard

Today when a team of pilots is flying together and one of them gets
low there is often a frantic exchange on the radio with the struggling
pilot asking the thermalling pilot for an accurate position fix.

Not only is this exchange distracting for everyone listening in, but
even more so for the termalling pilot, who wants to help his friend.
He is now forced into significant heads-down time to find his own
accurate position so he tell his friend exactly where he is. And as
you surely know, it is often not easy to verbally communicate this.
Doing so he also now risks losing his own concentration and getting
thrown out of his own thermal. So now we have two pilots with
significant heads-down time. Happens all the time.

So if we really care about minimizing heads-down time and minimizing
overall distractions, I'd say the scenario I presented is a pretty
good improvement.

Now I understand the counter argument you presented and I thought more
about it.

My solution to that is simple. The third party app or device can as
easily keep track of all thermalling/climbing gliders withing Flarm
range at all times and present them to the pilot in some order of
preference such as some smart combination of distance and climb rate.
Then all the struggling pilot needs to do is, for example, tap on the
first one on the list (~1 second) and voila, he gets the voice vector.

All am saying is that it would be highly beneficial to keep a forward
looking approach because it has been shown again and again we don't
really know what the killer app is going to be that will stimulate the
widest adoption. And the widest adoption is what the Flarm concept
(and we all) needs for it to really succeed.

Best,

David
(proud early adopter of many many devices, including a Brick
PowerFlarm).

[[email protected]]

David,

that's a good idea and we'll keep it in mind when it comes
to further development decisions!

Best
--Gerhard
> My solution to that is simple. The third party app or device can as
>
> easily keep track of all thermalling/climbing gliders withing Flarm
>
> range at all times and present them to the pilot in some order of
>
> preference such as some smart combination of distance and climb rate.
>
> Then all the struggling pilot needs to do is, for example, tap on the
>
> first one on the list (~1 second) and voila, he gets the voice vector.
>
>
>
> All am saying is that it would be highly beneficial to keep a forward
>
> looking approach because it has been shown again and again we don't
>
> really know what the killer app is going to be that will stimulate the
>
> widest adoption. And the widest adoption is what the Flarm concept
>
> (and we all) needs for it to really succeed.
>
>
>
> Best,
>
>
>
> David
>
> (proud early adopter of many many devices, including a Brick
>
> PowerFlarm).

[pcool]

That's how LK8000 is actually doing since two years, and maybe LX8000/9000
(the Big brother).
You enter a list of traffic ids, you can keep this list sorted by distance,
direction, lift.
You choose the traffic you want to monitor (we call it target)
Target is now available as a normal "goto", already selected as destination.
You can flight to the target always looking at it in a sight, telling you if
(at your current glide ratio) you will get there higher or lower.
Or you look at the target on the map, just like a waypoint, with an arrival
altitude relative to it.

But apart from user interface aspects, there is an important issue here to
be kept in mind, if you are thinking about improving traffic monitor for
non-safety purposes.
Flarm traffic will not be always broadcasted, even if in range.
And even if in range, your antenna might not be in view with the other
antenna, resulting in a perfect "invisible" traffic maybe a few miles away.
This is normal, as we have experienced so far in europe.
So the concept of "traffic" on display is misleading, a lot! In fact, I came
to conclusion that it is better to have 3 kind of traffic objects:
1- Live traffic (data received in the last 10-20 seconds for example)
2- Ghost traffic (data missing since up to a minute, or two.. dont remember)
3- Zombies. Traces of old traffic that disappeared.

Experience shows that zombies or ghost can reappear as live anytime, maybe 1
second after they were elected non-live.
It depends on the above factors.

Now if you log the nearby trafic data, for showing a trace of objectes, like
we do, in different colors to show where they actually climbed or sinked,
this trace will be held valid even if it belongs to an object that it is no
more visibile, for any reason, but still a ghost or a zombie.

I know this might sound funny, at least, with all these ghosts and zombies
going around, but this is like it is really happening in the air when you
transmit with small antennas at 10mw, and the antenna is not placed
externally to the canopy, with lots of carbon fiber around..

It is actually very fun to think about the infinite approaches a
manufacturer can choose from, for its technology.

Personally, I think the little butterfly is such a nice device to have, and
so simple to use...!
But people want more gadgets and beep machines aboard..

paolo



wrote in message
...

David,

that's a good idea and we'll keep it in mind when it comes
to further development decisions!

Best
--Gerhard
> My solution to that is simple. The third party app or device can as
>
> easily keep track of all thermalling/climbing gliders withing Flarm
>
> range at all times and present them to the pilot in some order of
>
> preference such as some smart combination of distance and climb rate.
>
> Then all the struggling pilot needs to do is, for example, tap on the
>
> first one on the list (~1 second) and voila, he gets the voice vector.
>
>
>
> All am saying is that it would be highly beneficial to keep a forward
>
> looking approach because it has been shown again and again we don't
>
> really know what the killer app is going to be that will stimulate the
>
> widest adoption. And the widest adoption is what the Flarm concept
>
> (and we all) needs for it to really succeed.
>
>
>
> Best,
>
>
>
> David
>
> (proud early adopter of many many devices, including a Brick
>
> PowerFlarm).

[Kimmo Hytoenen]

Paolo,

very good writing, thank you.

This traffic display you described also improves situation
awareness about the traffic near you. You can see if there is
someone near you, gliding the same direction, and you can see
his call-sign. If he keeps in the blind spot behind you, you can
ask on radio if the other pilot is aware of situation (without this
application he might not) and what are his/her intentions.

-kimmo


At 00:08 20 October 2012, pcool wrote:
>That's how LK8000 is actually doing since two years, and
maybe LX8000/9000
>(the Big brother).
>You enter a list of traffic ids, you can keep this list sorted by
distance,
>
>direction, lift.
>You choose the traffic you want to monitor (we call it target)
>Target is now available as a normal "goto", already selected as
>destination.
>You can flight to the target always looking at it in a sight,
telling you
>if
>(at your current glide ratio) you will get there higher or lower.
>Or you look at the target on the map, just like a waypoint, with
an arrival
>
>altitude relative to it.
>
>But apart from user interface aspects, there is an important
issue here to
>be kept in mind, if you are thinking about improving traffic
monitor for
>non-safety purposes.
>Flarm traffic will not be always broadcasted, even if in range.
>And even if in range, your antenna might not be in view with
the other
>antenna, resulting in a perfect "invisible" traffic maybe a few
miles away.
>This is normal, as we have experienced so far in europe.
>So the concept of "traffic" on display is misleading, a lot! In
fact, I
>came
>to conclusion that it is better to have 3 kind of traffic objects:
>1- Live traffic (data received in the last 10-20 seconds for
example)
>2- Ghost traffic (data missing since up to a minute, or two..
dont
>remember)
>3- Zombies. Traces of old traffic that disappeared.
>
>Experience shows that zombies or ghost can reappear as live
anytime, maybe
>1
>second after they were elected non-live.
>It depends on the above factors.
>
>Now if you log the nearby trafic data, for showing a trace of
objectes,
>like
>we do, in different colors to show where they actually climbed
or sinked,
>this trace will be held valid even if it belongs to an object that it
is no
>
>more visibile, for any reason, but still a ghost or a zombie.
>
>I know this might sound funny, at least, with all these ghosts
and zombies
>going around, but this is like it is really happening in the air
when you
>transmit with small antennas at 10mw, and the antenna is not
placed
>externally to the canopy, with lots of carbon fiber around..
>
>It is actually very fun to think about the infinite approaches a
>manufacturer can choose from, for its technology.
>
>Personally, I think the little butterfly is such a nice device to
have, and
>
>so simple to use...!
>But people want more gadgets and beep machines aboard..
>
>paolo

[[email protected]]

On Saturday, October 6, 2012 12:11:32 PM UTC-4, bumper wrote:
> For those of us who don't relish the "opportunity" to dive in and experiment with config files and such . . . Butterfly has a free config file builder that does it for you using a multiple choice format that even I can figure out.
>
>
>
> http://www.butterfly-avionics.com/index.php/en/products/powerflarm-en/powerflarm-core-config-en
>
>
>
> bumper

Bumper,

thanks for the pointer. I used this site just now to generate a config file, and it works GREAT!

TA

[[email protected]]

On Friday, October 19, 2012 5:08:09 PM UTC-7, pcool wrote:
> That's how LK8000 is actually doing since two years, and maybe LX8000/9000
>
> (the Big brother).
>
> You enter a list of traffic ids, you can keep this list sorted by distance,
>
> direction, lift.
>
> You choose the traffic you want to monitor (we call it target)
>
> Target is now available as a normal "goto", already selected as destination.
>
> You can flight to the target always looking at it in a sight, telling you if
>
> (at your current glide ratio) you will get there higher or lower.
>
> Or you look at the target on the map, just like a waypoint, with an arrival
>
> altitude relative to it.
>
>
>
> But apart from user interface aspects, there is an important issue here to
>
> be kept in mind, if you are thinking about improving traffic monitor for
>
> non-safety purposes.
>
> Flarm traffic will not be always broadcasted, even if in range.
>
> And even if in range, your antenna might not be in view with the other
>
> antenna, resulting in a perfect "invisible" traffic maybe a few miles away.
>
> This is normal, as we have experienced so far in europe.
>
> So the concept of "traffic" on display is misleading, a lot! In fact, I came
>
> to conclusion that it is better to have 3 kind of traffic objects:
>
> 1- Live traffic (data received in the last 10-20 seconds for example)
>
> 2- Ghost traffic (data missing since up to a minute, or two.. dont remember)
>
> 3- Zombies. Traces of old traffic that disappeared.
>
>
>
> Experience shows that zombies or ghost can reappear as live anytime, maybe 1
>
> second after they were elected non-live.
>
> It depends on the above factors.
>
>
>
> Now if you log the nearby trafic data, for showing a trace of objectes, like
>
> we do, in different colors to show where they actually climbed or sinked,
>
> this trace will be held valid even if it belongs to an object that it is no
>
> more visibile, for any reason, but still a ghost or a zombie.
>
>
>
> I know this might sound funny, at least, with all these ghosts and zombies
>
> going around, but this is like it is really happening in the air when you
>
> transmit with small antennas at 10mw, and the antenna is not placed
>
> externally to the canopy, with lots of carbon fiber around..
>
>
>
> It is actually very fun to think about the infinite approaches a
>
> manufacturer can choose from, for its technology.
>
>
>
> Personally, I think the little butterfly is such a nice device to have, and
>
> so simple to use...!
>
> But people want more gadgets and beep machines aboard..
>
>
>
> paolo
>
>
>
>
>
>
>
> wrote in message
>
> ...
>
>
>
> David,
>
>
>
> that's a good idea and we'll keep it in mind when it comes
>
> to further development decisions!
>
>
>
> Best
>
> --Gerhard
>
> > My solution to that is simple. The third party app or device can as
>
> >
>
> > easily keep track of all thermalling/climbing gliders withing Flarm
>
> >
>
> > range at all times and present them to the pilot in some order of
>
> >
>
> > preference such as some smart combination of distance and climb rate.
>
> >
>
> > Then all the struggling pilot needs to do is, for example, tap on the
>
> >
>
> > first one on the list (~1 second) and voila, he gets the voice vector.
>
> >
>
> >
>
> >
>
> > All am saying is that it would be highly beneficial to keep a forward
>
> >
>
> > looking approach because it has been shown again and again we don't
>
> >
>
> > really know what the killer app is going to be that will stimulate the
>
> >
>
> > widest adoption. And the widest adoption is what the Flarm concept
>
> >
>
> > (and we all) needs for it to really succeed.
>
> >
>
> >
>
> >
>
> > Best,
>
> >
>
> >
>
> >
>
> > David
>
> >
>
> > (proud early adopter of many many devices, including a Brick
>
> >
>
> > PowerFlarm).

This is a very impressive capability of LK8000! And pretty much what I had in mind, although I indicated speech output to reduce head-down time.

The classification of targets (Live, Ghost, Zombies) is sensible given the constraints of the system (10mW power output) which limit the continuous visibility of targets (which is rather unfortunate). Recording the location of another glider in the recent past and it's climb rate at the time can be very useful information for those that like team flying.

Combined with some good audio alerting capability is there really a need for a dedicated Flarm display (ie, Butterfly)? Assuming of course the Collision Alert capability on the app is as fast as it is with the Butterfly display. Wouldn't want any further delays on that.

Although I keep recommending pilots to "fly your own flight and not someone else's flight, make your own decisions, good and bad", team-flying is fun once in a while and actually the preferred modality for some pilots. And besides, a friend's thermal can be quite handy at times. Plus, if it cuts down on radio chatter, then everyone wins.

There is another thread on leeching. The fundamental question is: should one rely just one's own capabilities to find all lift or is it a collaborative effort? Should one use technology to find lift (ie, thermal detectors, in the not too distant future). Each pilot should answer this question for themselves depending on what their goals are. Also this question has different meaning depending on the context (ie, competition vs recreational)

What is pretty clear is that the widest adoption of Flarm is beneficial to all soaring pilots as a group, regardless of the individual's main motivation to use it. So casting the widest net of adoption is what we should be aiming for.


David