PowerFlarm and ADS-B solution, can we find one?

I think it is time to end this back and forth ping pong about restricting the use of PF. We have to agree to disagree and try to come up with a solution that could work for both groups.
Let's try to define some criteria that might be acceptable to all:
1) Should targets be visible on PowerFlarm display?
2) If (1) is "Yes" then what is the desired distance at which targets should be visible on PowerFlarm display?
3) Do we allow for displaying altitude of another glider on PowerFlarm display?
4) Do we allow for displaying information pertaining to climb rate or simply indicate if a glider is ascending or descending?
5) Do we need to be able to identify a conflicting glider?
6) What are the minimum requirements for identification of conflicting traffic?
7) Should we aim not to degrade PF functions for non-contest participating PF users in the area of a contest?
8) How do we deal with ADS-B in a glider? I have ADS-B out plus I have ADS-B in on both 1090 and 978.
9) Anything else?

(1) I suggest "Yes" otherwise there is no situational awareness at all:
a. In my opinion some situational awareness in the vicinity is required
b. one evasive action can cause another dangerous situation
c. it is very stressful to be reacting to sudden alarms without prior awareness of where the traffic might be coming from and this can lead to development of other dangerous situations
(2) Let's do some math. Two gliders on traveling in opposite directions at 17k feet can easily be closing distance at the rate of 260 kts. Let's remember about TAS at high altitude. That is almost 500 km/hour. Let's use the 60 seconds as an adequate awareness time. This leads to a distance of 8km. If we desire to use 5km as a minimum than we have 37 seconds of advanced warning. Is that enough? Each of us will have different criteria. I think 37 seconds might be enough for me if I am rested and there is good visibility. Let's remember it is not only reaction time but also achieving meaningful separation, and knowing which way to turn and then maybe have some room for a mistake (like turning the same way for by gliders)
(3) I think I would like to know altitude difference and if traffic is climbing or descending or just altitude. I really don't care much about what the rate of change is.
(4) Answered above
(5) Initially I thought this was not required but I think being able to communicate might be important in some situations.
(6) I do not think we need contest ids we could create another way of identifying gliders, however with time people would figure out what the opponent codes are if they really wanted to.
(7) Absolutely "YES" This is where "Stealth" mode fails.
(8) I have seen power traffic cruising happily under cloud bases. That is why I have ADS-B out and I also have ADS-B In on both 1090 and 978. I get traffic from ground stations. I put the ADS-B out so I can see the power traffic around me and not to freak out every time I see a ring on PCAS not knowing where the traffic is. The only way I see we could control ADS-B in is if PowerFlarm updated its ADSB-in to include ground station transitions, which I thought they did, but maybe not. Then we could limit ADS-B traffic to 5 km, which could be a huge mistake because at 17k feet power traffic can go really fast. This is a real problem. Additional ADS-B in equipment I have in my glider to receive ground station traffic cannot be limited to 5km. I would be willing to get the other equipment out of my glider as long as I get traffic transmitting by ground stations on PF, but what to do about fast power traffic? Anyone has a good idea? Filter based on speed?
As you can see, complexity of working out a solution is huge as there are many variables. We would need to deal not only with flarm traffic but also with ADS-B traffic and consider you might deal with high speed ADS-B traffic..

Let's see if we could agree on technical specifications for future competition mode that would be acceptable to everyone, but it needs to include ADS-B in. I am not sure there is a solution, but let's try.

Let's give each other some room and that includes RC. It would also be nice to get a briefing from RC where things are with Flarm and what is being considered by Flarm. Lastly as you can see there are many variables. It would be nice if we could agree to not attempt to make any changes for 2016 and instead spend time trying to figure out what a solution should be and test it properly. Again, a solution should meaningfully deal with ADS-B.

I hope we could keep this thread focused on a solution and not question our positions. We have done enough of that.

On Monday, January 4, 2016 at 6:08:40 PM UTC-5, Andrzej Kobus wrote:

(8) I have seen power traffic cruising happily under cloud bases. That is why I have ADS-B out and I also have ADS-B In on both 1090 and 978. I get traffic from ground stations. I put the ADS-B out so I can see the power traffic around me and not to freak out every time I see a ring on PCAS not knowing where the traffic is. The only way I see we could control ADS-B in is if PowerFlarm updated its ADSB-in to include ground station transitions, which I thought they did, but maybe not. Then we could limit ADS-B traffic to 5 km, which could be a huge mistake because at 17k feet power traffic can go really fast. This is a real problem. Additional ADS-B in equipment I have in my glider to receive ground station traffic cannot be limited to 5km. I would be willing to get the other equipment out of my glider as long as I get traffic transmitting by ground stations on PF, but what to do about fast power traffic? Anyone has a good idea? Filter based on speed?
As you can see, complexity of working out a solution is huge as there are many variables. We would need to deal not only with flarm traffic but also with ADS-B traffic and consider you might deal with high speed ADS-B traffic.


What ADS-B "in/out" transceiver do you use?

What hardware do you use to display the ADS-B "in" traffic and weather information?

On Monday, January 4, 2016 at 6:48:41 PM UTC-5, wrote:
On Monday, January 4, 2016 at 6:08:40 PM UTC-5, Andrzej Kobus wrote:

(8) I have seen power traffic cruising happily under cloud bases. That is why I have ADS-B out and I also have ADS-B In on both 1090 and 978. I get traffic from ground stations. I put the ADS-B out so I can see the power traffic around me and not to freak out every time I see a ring on PCAS not knowing where the traffic is. The only way I see we could control ADS-B in is if PowerFlarm updated its ADSB-in to include ground station transitions, which I thought they did, but maybe not. Then we could limit ADS-B traffic to 5 km, which could be a huge mistake because at 17k feet power traffic can go really fast. This is a real problem. Additional ADS-B in equipment I have in my glider to receive ground station traffic cannot be limited to 5km. I would be willing to get the other equipment out of my glider as long as I get traffic transmitting by ground stations on PF, but what to do about fast power traffic? Anyone has a good idea? Filter based on speed?
As you can see, complexity of working out a solution is huge as there are many variables. We would need to deal not only with flarm traffic but also with ADS-B traffic and consider you might deal with high speed ADS-B traffic.


What ADS-B "in/out" transceiver do you use?

What hardware do you use to display the ADS-B "in" traffic and weather information?

FreeFlight 1201 over Trig 22 and Stratus 2s with ForeFlight on iPhone 6s Plus. For contest only 1090 receiver and ForeFlight on iPhone 6s Plus so I do not get accused of using in flight weather.

Good thought process Andrzej!

Agree climb rates are useless and cause a great deal of the insecurity about Flarm. It also provides little situational awareness value (safety). Only realtive altitude matters (+100, -500, +1000, etc).

But in general location of all objects in the air that could potentially kill me, or I them, I want to be able to detect, with a huge margin of safety error, as coverage is not 100% (never will be for Flarm) and they are not mandatory (never will be after this debate).

Sean

What if FLARM were to integrate with ADS-B out. This box would use the existing FLARM technology to determine conflicts and to display proximate targets with other FLARM equipped gliders and not use that glider's ADS-B signal.. FLARM is better for glider to glider collision avoidance. If the glider got out of FLARM range the box would automatically start using the ABS-B technology. The display of this glider might change to a different color on the display as is goes to ADS-B. All aircraft with ADS-B and no FLARM would be displayed all the time at any selected range.

Okay, I know that there are technical difficulties and enforcement issues. Here's the question:

Would a competition mode that allows unlimited range and just doesn't display FLARM equipped gliders that are more +/-1000 difference in altitude be acceptable? If you need +/- 1500 ft okay.

Again, outside of FLARM range (6-10 sm) ADS-B picks up and displays everything for this glider. Non-participants with ADS-B, especially powered traffic is always shown.

Technical issues aside for now, doesn't this give plenty of collision avoidance and also work as a competition mode.

XC

On Monday, January 4, 2016 at 6:08:40 PM UTC-5, Andrzej Kobus wrote:
I think it is time to end this back and forth ping pong about restricting the use of PF. We have to agree to disagree and try to come up with a solution that could work for both groups.
Let's try to define some criteria that might be acceptable to all:
1) Should targets be visible on PowerFlarm display?
2) If (1) is "Yes" then what is the desired distance at which targets should be visible on PowerFlarm display?
3) Do we allow for displaying altitude of another glider on PowerFlarm display?
4) Do we allow for displaying information pertaining to climb rate or simply indicate if a glider is ascending or descending?
5) Do we need to be able to identify a conflicting glider?
6) What are the minimum requirements for identification of conflicting traffic?
7) Should we aim not to degrade PF functions for non-contest participating PF users in the area of a contest?
8) How do we deal with ADS-B in a glider? I have ADS-B out plus I have ADS-B in on both 1090 and 978.
9) Anything else?


In the interest of having a constructive discussion on the topic- THANK YOU ANDRZEJ!, I will provide my personal opinions.
1- Yes
2- I have suggested 5km previously
3- Relative altitude only, with limit of 200meters(admittedly somewhat arbitrary)
4 No
5- Yes if it is an identified conflict.
6- Provide whatever ID the other glider is using. With ID's suppressed for tactical purposes, I think more pilots would be likely to make them available for conflict resolution.
7- Yes. To me this is the greatest shortcoming of existing Stealth. This is a double sided problem to solve. Plus- it provides little if any degradation of safety for other stake holders. This factor was the principle reason why the BGA stopped the Stealth mandate over there. Negative- it is much harder to ensure that the new mode performs equally for all without hackers turning it wide open again. This would require use of flight displays running programs shown to be compliant. Nothing is without complication. The other negative is that it could enable ground tracking . Possibly the privacy settings could prevent this.
8- I don't have enough visibility into how effective ADSB information will be tactically compared to Flarm to have an opinion. From a tactical point of view, I'd love it to be not there at all. From a safety point of view, I'd like it to be effective.
Again- Thanks for fostering a constructive exchange.
UH

On Tuesday, January 5, 2016 at 6:02:51 AM UTC-8, wrote:
SNIP Negative- it is much harder to ensure that the new mode performs equally for all without hackers turning it wide open again. This would require use of flight displays running programs shown to be compliant.

I don't believe that is correct. All the information on stealth mode (actually named PRIV in the documents) suggests that the implementation is on the receive end. When the PRIV flag is set, the broadcasts contain the same information, but are marked with the PRIV flag, telling the receiver not to forward the information to the serial port for display (regardless of display). Since the receivers are also running Flarm firmware, they respect this flag. The information is there for the hacking today by someone determined enough. All that needs to be done for non-contestants is to allow the receiver to make the decision based on its PRIV flag. If I was not flying in the contest and did not have the PRIV flag set, my receiver would forward the information to the serial port and the display. The vulnerability to cheating and hacking is the same as now. The change to the firmware to do this should be trivial.

From the dataport spec: "The stealth flag indicates whether the own broadcasted data shall be solely used for collision avoidance15, i.e. where not all the received information is forwarded to the serial data-port and therefore is not available to external, graphical displays or PDA's to prevent abuse in competitions."

Since the paranoia seems to surround the theoretical possibility of Flarm leeching, here is a suggestion: I believe you may be able to determine leeching (provided someone can define it) by using the Flarm IGC file. In it are comment lines which enumerate each Flarm contact. I'm not sure if I am decoding these correctly but it seems as though the received Flarm is identified uniquely. To leech in the way that is the source of the paranoia, one would need to keep in Flarm contact throughout the day. This should be quite apparent from an analysis of the contact comments, perhaps in combination with the position reports to see who is leading and who trailing. Some definition of leeching would need to be proposed based on leading/following, % time in contact, etc. There is no information there that is not already contained in the relevant IGC position data, but it is easier to process, and adds proof that the target of the leech was in Flarm contact (which must be part of any Flarm leeching by definition).

Note that the same thing can be done for ADS-B, at least with Mode S transponders and a PowerFlarm log. It would flag visual leeching as well, since visual leeching is a subset of Flarm leeching.

All this appears to be technically feasible, except perhaps for the definition of leeching which has so far been elusive. The log checking can be an automated part of the scoring process, or applied in the event of a protest.

On Tuesday, January 5, 2016 at 12:14:30 PM UTC-5, jfitch wrote:
On Tuesday, January 5, 2016 at 6:02:51 AM UTC-8, wrote:
SNIP Negative- it is much harder to ensure that the new mode performs equally for all without hackers turning it wide open again. This would require use of flight displays running programs shown to be compliant.

I don't believe that is correct. All the information on stealth mode (actually named PRIV in the documents) suggests that the implementation is on the receive end. When the PRIV flag is set, the broadcasts contain the same information, but are marked with the PRIV flag, telling the receiver not to forward the information to the serial port for display (regardless of display). Since the receivers are also running Flarm firmware, they respect this flag. The information is there for the hacking today by someone determined enough. All that needs to be done for non-contestants is to allow the receiver to make the decision based on its PRIV flag. If I was not flying in the contest and did not have the PRIV flag set, my receiver would forward the information to the serial port and the display. The vulnerability to cheating and hacking is the same as now. The change to the firmware to do this should be trivial.

From the dataport spec: "The stealth flag indicates whether the own broadcasted data shall be solely used for collision avoidance15, i.e. where not all the received information is forwarded to the serial data-port and therefore is not available to external, graphical displays or PDA's to prevent abuse in competitions."


From Flarm card:
Stealth Mode
The data FLARM(R)
receives from other is available at the serial
port to external devices like PDA's or graphical displays which
can thus display the nearby environment in detail. While this
information is useful for you, you might not want your
competitors to make use of this information, and others might
have the similar asymmetrical preferences. With the stealth
mode (named 'Privacy' before) in FLARM(R)
, you can choose
the trade-off acceptable for you between two modes:
* 'Stealth Mode' unchecked: you have full access to the data
you receive from others with Stealth Mode disabled and,
and others have full access to the data you send about
yourself if they have Stealth Mode disabled, or
* 'Stealth Mode' checked: you have limited access to the
data you receive from others and, and others have limited
access to the data you send about yourself independent of
their Stealth Mode setting.

I interpret this as saying info out to others is limited in Stealth mode which is the basis for my comment. I originally thought filtering was only on the receiving side which as you said, but this information contradicts that. I think I stand by my comment.
UH

On Tuesday, January 5, 2016 at 12:36:54 PM UTC-5, jfitch wrote:
Since the paranoia[...]

Can we please have just one flarm-in-competition thread that is constructive? Enough of the loaded comments, goading and scare mongering!

UH: all filtering occurs on receiving end. It has to be this way, else anti-collision warning performance would be compromised.

T8