Log in

View Full Version : US Rules Committee Policy on Permitting S/W for Tablets, PNAs,Smartphones etc.


John Godfrey (QT)[_2_]
February 24th 12, 05:15 PM
http://www.ssa.org/files/member/Restricted%20Device%20Policy.pdf

It goes like this.

1. The FAI and US rules banning the use in competition of technology
that provide AH or T&B functionality are not going away this season.
Opine to the max on the good/bad aspects of this all you like, but the
rule will not be changed this season.

2. Recognizing the difficulty of complete enforcement against a
dedicated cheater, but not wanting to disenfranchise either the users
of software or the developers we wrote a policy governing acceptable
use of these devices.

3. Developers who wish to not disenfranchise their users will make
the necessary changes to their products and release rules-compliant
versions in a timely fashion. This basically means compiling out any
code that implements prohibited functionality and making it clear to a
non-technical contest official (e.g. via the splash screen) what the
version is. Not rocket science.

In other news:

4. Use of cellular/satellite whatever voice or data services in
flight remains prohibited but for two different reasons.

4a. Voice services are prohibited because team flying is prohibited.
Nothing new there.

4b. Data services (e.g. in-flight weather) have been prohibited up to
now because of the high cost of the necessary devices and not wanting
to send the message that you need more high cost equipment to
compete. As this situation is rapidly changing and in-flight weather
is becoming ubiquitous and cheap this ban will probably go away soon
(next season?).

Deep breaths and civility everyone. It's not our fault that vendors
and developers starting introducing prohibited functionality without
due awareness of the FAI and US competition rules.

John Godfrey (QT)
US Rules Committee

Steve Koerner
February 24th 12, 06:18 PM
I commend the rules committee on this. The policy statement is
sensible and well worded. It is clear to me that there are vocal
folks here on RAS who simply are not appreciating the whole of the
problem.

February 24th 12, 06:55 PM
3. Anyone wanting to cheat downloads source code and compiles in AH, keeping the compliance splash screen. Also not rocket science.

4b. Inflight data, subject to cell phone reception, is extremely cheap now. You pay more for a short voice phone call than the data would cost for inflight forecast/nowcast updates. We live in an information age, why not allow gliding to move with the times?

Tobias Bieniek
February 24th 12, 07:09 PM
Hi John,

I am still in the dark about the actual implementation. As I asked before via mail what is your position on the following features of XCSoar:

* AH based on GPS/Vario/Airspeed
* AH based on internal/external gyro (forbidden, but not implemented in any version of XCSoar yet)
* METAR download (forbidden, right? how is it different from requesting it via VHF?)
* Live Tracking via 3G/4G (only upload, no download)
* Flarm radar functionality

Does the application need to make sure that data/voice services are not used? Is it enough to enable the plane mode in the smartphone? I wouldn't know how our software should be able to block incoming voice calls which are not part of our software...

John Godfrey (QT)[_2_]
February 24th 12, 07:21 PM
On Feb 24, 2:09*pm, Tobias Bieniek >
wrote:
> Hi John,
>
> I am still in the dark about the actual implementation. As I asked before via mail what is your position on the following features of XCSoar:
>
> * AH based on GPS/Vario/Airspeed
> * AH based on internal/external gyro (forbidden, but not implemented in any version of XCSoar yet)
> * METAR download (forbidden, right? how is it different from requesting it via VHF?)
> * Live Tracking via 3G/4G (only upload, no download)
> * Flarm radar functionality
>
> Does the application need to make sure that data/voice services are not used? Is it enough to enable the plane mode in the smartphone? I wouldn't know how our software should be able to block incoming voice calls which are not part of our software...

Hi Tobias,
WRT US Rules only:
1. AH based on GPS/Vario/Airspeed - although unlikely this can be
effectively used for cloud flying still not allowed.
2. AH based on gyro - not allowed
4. All incoming data stream based weather data is forbidden,
regardless of the technology (cell,satellite, VHF, VLF). Listening to
non-specific voice broadcast (e.g. ATIS) is ok,
5. There is no current restriction on Flarm radar functionality but be
aware this may change next year.
QT

S. Murry
February 24th 12, 07:32 PM
On Fri, 24 Feb 2012 12:55:00 -0600, > wrote:
John,

The use of cellphones and other intentional transmitters in flight is
illegal in the US. I don't think the rules committe should permit
something that is illegal.

--Stefan


> 4b. Inflight data, subject to cell phone reception, is extremely cheap
> now. You pay more for a short voice phone call than the data would cost
> for inflight forecast/nowcast updates. We live in an information age,
> why not allow gliding to move with the times?


--
Stefan Murry

John Godfrey (QT)[_2_]
February 24th 12, 07:36 PM
On Feb 24, 1:55*pm, wrote:
> 3. Anyone wanting to cheat downloads source code and compiles in AH, keeping the compliance splash screen. Also not rocket science.
>
> 4b. Inflight data, subject to cell phone reception, is extremely cheap now. *You pay more for a short voice phone call than the data would cost for inflight forecast/nowcast updates. We live in an information age, why not allow gliding to move with the times?

I’m personally not too worried about the dedicated cheater. I am
reminded of a story about the WGC years ago when data-back cameras
were used to imprint the time on the film. One enterprising competitor
figured out how to diddle his data-back in flight to change the time.
His meteoric rise from fair-to-middlin’ to top-of-the-pack did not go
unnoticed. Suspecting cheating, the contest officials selected a
turnpoint that was a traffic circle and dispatched two cars with
instruction to make like a clock by changing where they parked. Don’t
know if the pilot was publicly confronted but he withdrew.

As a scorer, it is no big deal (and I often do) to look at all the
baro traces together and notice that someone has been consistently
outclimbing everyone else by 20% in the same locations. Would make for
an interesting daily pilot meeting to invite the pilot to come forward
and explain the secrets of the exceptional thermaling technique...

QT

February 24th 12, 07:48 PM
Stefan,

Likewise if it's already covered by FAA/FCC rules, there's no need to have duplicate rules in you contest rules.

I was merely pointing out the argument of keeping costs down has been rendered irrelevant due to contemporary consumer communications devices as well as access to useful met feeds.

S. Murry
February 24th 12, 07:56 PM
On Fri, 24 Feb 2012 13:48:29 -0600, > wrote:
John,

OK. I'll buy that. Although I will counter that the cost of "legal"
weather information is still not exactly cheap (I guess, depending on your
cheapness threshold). To be legal, it would have to be based (currently)
on satellite or (in some limited areas) ADS-B. Cell phone data reception
is illegal.

Satellite data services (used by Garmin, for example), cost ~$500 a year
(it's been a while since I looked at what I paid for a subscription, so
please don't jump all over this, but it's some hundreds of dollars) and
the hardware to receive these will cost around $1000 (again, I'm not that
current, but it's a lot more than a typical cellphone).

ADS-B is only available in limited areas, mostly metropolitan, and the
receivers cost thousands (plus are power hungry and generally unsuited for
glider use).

However, I think the spirit of this discussion is that this technology is
rapidly evolving and certainly all of this is becoming much more
available and may even already be cheap (at least to people who have more
financial means than I :) ).


--Stefan


> Stefan,
>
> Likewise if it's already covered by FAA/FCC rules, there's no need to
> have duplicate rules in you contest rules.
>
> I was merely pointing out the argument of keeping costs down has been
> rendered irrelevant due to contemporary consumer communications devices
> as well as access to useful met feeds.


--
Stefan Murry

February 24th 12, 08:10 PM
John G:

There are emerging technologies aimed at consumer applications (cars) to detect fog.

I don't think these are available/affordable/practical yet for use in gliders, but I think it might be worth ssa/igc to look into when planning a solution to the issue at hand.

Derek Mackie
February 24th 12, 08:15 PM
QT - Here's an article in Canadian Free Flight from last year that
describes the entire WGC cheating fiasco in detail:
http://www.sac.ca/index.php?option=com_docman&task=cat_view&gid=105&Itemid=88
Select 11-01 Winter.

My two cents: Leave the rule at "Thou Shalt Not Cloud Fly" and
publicly string up anyone who is caught. Let's find out where all
this marvellous technology can take us. I really don't want to trade
my turnpoint camera in for an Etch-A-Sketch.

Please let's not loose sight that we do this for FUN.

Derek

Andrzej Kobus
February 24th 12, 11:44 PM
On Feb 24, 2:21*pm, "John Godfrey (QT)" >
wrote:
> On Feb 24, 2:09*pm, Tobias Bieniek >
> wrote:
>
> > Hi John,
>
> > I am still in the dark about the actual implementation. As I asked before via mail what is your position on the following features of XCSoar:
>
> > * AH based on GPS/Vario/Airspeed
> > * AH based on internal/external gyro (forbidden, but not implemented in any version of XCSoar yet)
> > * METAR download (forbidden, right? how is it different from requesting it via VHF?)
> > * Live Tracking via 3G/4G (only upload, no download)
> > * Flarm radar functionality
>
> > Does the application need to make sure that data/voice services are not used? Is it enough to enable the plane mode in the smartphone? I wouldn't know how our software should be able to block incoming voice calls which are not part of our software...
>
> Hi Tobias,
> WRT US Rules only:
> 1. AH based on GPS/Vario/Airspeed - although unlikely this can be
> effectively used for cloud flying still not allowed.
> 2. AH based on gyro - not allowed
> 4. All incoming data stream based weather data is forbidden,
> regardless of the technology (cell,satellite, VHF, VLF). Listening to
> non-specific voice broadcast (e.g. ATIS) is ok,
> 5. There is no current restriction on Flarm radar functionality but be
> aware this may change next year.
> QT

I think there is an issue here. Many of us have PDAs or PNAs without
any sensors usable to provide an AH function. XCSoar has some dead
code that could be qualified as supporting AH display but it is
useless without sensors. LK8000 has a page that shows estimated bank
angle based on GPS position changes. If these two open source products
are qualified as illegal there will be substantial impact on contest
attendance. I know of many that use XCSoar and LK8000. I am using
LK8000 as back up software on a PNA that does not have any sensors so
it is useless as an AH function.

So please explain what the text from the explanation document means
"It will be the responsibility of the pilot to ensure that programs
and applications that could make these devices functional as AH
equipment are not installed." I am in particular interested in
"functional as AH". Does this mean functional because there is a
display and sensors or functional because there is some display like
estimated bank angle based on GPS data alone? This is very important
and before you answer please think about the impact of your answer. I
understand a ban on true AH capabilities but I don't understand a ban
related to GPS signal processing alone without sensors. I can achieve
the same by zooming into my moving map. I will see there my turns
precisely. What is the difference?

Andrzej Kobus

Brad[_2_]
February 25th 12, 12:17 AM
On Feb 24, 3:44*pm, Andrzej Kobus > wrote:
> On Feb 24, 2:21*pm, "John Godfrey (QT)" >
> wrote:
>
>
>
>
>
>
>
>
>
> > On Feb 24, 2:09*pm, Tobias Bieniek >
> > wrote:
>
> > > Hi John,
>
> > > I am still in the dark about the actual implementation. As I asked before via mail what is your position on the following features of XCSoar:
>
> > > * AH based on GPS/Vario/Airspeed
> > > * AH based on internal/external gyro (forbidden, but not implemented in any version of XCSoar yet)
> > > * METAR download (forbidden, right? how is it different from requesting it via VHF?)
> > > * Live Tracking via 3G/4G (only upload, no download)
> > > * Flarm radar functionality
>
> > > Does the application need to make sure that data/voice services are not used? Is it enough to enable the plane mode in the smartphone? I wouldn't know how our software should be able to block incoming voice calls which are not part of our software...
>
> > Hi Tobias,
> > WRT US Rules only:
> > 1. AH based on GPS/Vario/Airspeed - although unlikely this can be
> > effectively used for cloud flying still not allowed.
> > 2. AH based on gyro - not allowed
> > 4. All incoming data stream based weather data is forbidden,
> > regardless of the technology (cell,satellite, VHF, VLF). Listening to
> > non-specific voice broadcast (e.g. ATIS) is ok,
> > 5. There is no current restriction on Flarm radar functionality but be
> > aware this may change next year.
> > QT
>
> I think there is an issue here. Many of us have PDAs or PNAs without
> any sensors usable to provide an AH function. XCSoar has some dead
> code that could be qualified as supporting AH display but it is
> useless without sensors. LK8000 has a page that shows estimated bank
> angle based on GPS position changes. If these two open source products
> are qualified as illegal there will be substantial impact on contest
> attendance. I know of many that use XCSoar and LK8000. I am using
> LK8000 as back up software on a PNA that does not have any sensors so
> it is useless as an AH function.
>
> So please explain what the text from the explanation document means
> "It will be the responsibility of the pilot to ensure that programs
> and applications that could make these devices functional as AH
> equipment are not installed." I am in particular interested in
> "functional as AH". Does this mean functional because there is a
> display and sensors or functional because there is some display like
> estimated bank angle based on GPS data alone? This is very important
> and before you answer please think about the impact of your answer. I
> understand a ban on true AH capabilities but I don't understand a ban
> related to GPS signal processing alone without sensors. I can achieve
> the same by zooming into my moving map. I will see there my turns
> precisely. What is the difference?
>
> Andrzej Kobus

I fly with a Tru-Trak and LK8000 V3.0 loaded on a iPAQ310 with a
external GPS engine. I flew close to 3 hours yesterday with the Tru-
Trak on and toggled into the LK8000 "AH" page fairly regularly to see
how the 2 bits of information compared.

IMO there is no comparison, the AH on the LK8000 would do nothing but
distract me while the sailplane eventually came
apart.................if I was reckless enough to think it would help
in an IMC event. The Tru-Trak: at least it will help me if caught on
top and I have no choice but to descend thru a layer.

In my 30 years or so of soaring I've needed a gyro 2 times, that alone
makes it part of my panel for keeps.

Brad

PCool
February 25th 12, 01:10 AM
The fake AH in LK8000 is there as an emergency tool to help a pilot get out
of a cloud, when there is nothing else better left.
Getting into a cloud can happen for a number of reasons, expecially when the
weather is changing a lot for an incoming cold front, and all of a sudden a
cloud cover is under you.
I think this tool is better "than a kick in the axx" in such situations,
when all you want is to keep flying straight to get out.

This said, it would be very easy for us to remove the page (which can be
disabled even now, by the user), and print a clear statement that
this tool is not part of the software.

This would not make any difference to those that think they can cheat with
such a AH.
Because anybody can get the code, change a line, and make that statement
appear in any case.

So our position is very simple. We shall do what Xcsoar people will decide
to do for their project.
If they dont accept this kind of a treat, we shall not accept it either.
If they deliver a special US version, we shall also do the same.

Paolo
LK8000 project
www.lk8000.it






"Brad" > ha scritto nel messaggio
...
On Feb 24, 3:44 pm, Andrzej Kobus > wrote:
> On Feb 24, 2:21 pm, "John Godfrey (QT)" >
> wrote:
>
>
>
>
>
>
>
>
>
> > On Feb 24, 2:09 pm, Tobias Bieniek >
> > wrote:
>
> > > Hi John,
>
> > > I am still in the dark about the actual implementation. As I asked
> > > before via mail what is your position on the following features of
> > > XCSoar:
>
> > > * AH based on GPS/Vario/Airspeed
> > > * AH based on internal/external gyro (forbidden, but not implemented
> > > in any version of XCSoar yet)
> > > * METAR download (forbidden, right? how is it different from
> > > requesting it via VHF?)
> > > * Live Tracking via 3G/4G (only upload, no download)
> > > * Flarm radar functionality
>
> > > Does the application need to make sure that data/voice services are
> > > not used? Is it enough to enable the plane mode in the smartphone? I
> > > wouldn't know how our software should be able to block incoming voice
> > > calls which are not part of our software...
>
> > Hi Tobias,
> > WRT US Rules only:
> > 1. AH based on GPS/Vario/Airspeed - although unlikely this can be
> > effectively used for cloud flying still not allowed.
> > 2. AH based on gyro - not allowed
> > 4. All incoming data stream based weather data is forbidden,
> > regardless of the technology (cell,satellite, VHF, VLF). Listening to
> > non-specific voice broadcast (e.g. ATIS) is ok,
> > 5. There is no current restriction on Flarm radar functionality but be
> > aware this may change next year.
> > QT
>
> I think there is an issue here. Many of us have PDAs or PNAs without
> any sensors usable to provide an AH function. XCSoar has some dead
> code that could be qualified as supporting AH display but it is
> useless without sensors. LK8000 has a page that shows estimated bank
> angle based on GPS position changes. If these two open source products
> are qualified as illegal there will be substantial impact on contest
> attendance. I know of many that use XCSoar and LK8000. I am using
> LK8000 as back up software on a PNA that does not have any sensors so
> it is useless as an AH function.
>
> So please explain what the text from the explanation document means
> "It will be the responsibility of the pilot to ensure that programs
> and applications that could make these devices functional as AH
> equipment are not installed." I am in particular interested in
> "functional as AH". Does this mean functional because there is a
> display and sensors or functional because there is some display like
> estimated bank angle based on GPS data alone? This is very important
> and before you answer please think about the impact of your answer. I
> understand a ban on true AH capabilities but I don't understand a ban
> related to GPS signal processing alone without sensors. I can achieve
> the same by zooming into my moving map. I will see there my turns
> precisely. What is the difference?
>
> Andrzej Kobus

I fly with a Tru-Trak and LK8000 V3.0 loaded on a iPAQ310 with a
external GPS engine. I flew close to 3 hours yesterday with the Tru-
Trak on and toggled into the LK8000 "AH" page fairly regularly to see
how the 2 bits of information compared.

IMO there is no comparison, the AH on the LK8000 would do nothing but
distract me while the sailplane eventually came
apart.................if I was reckless enough to think it would help
in an IMC event. The Tru-Trak: at least it will help me if caught on
top and I have no choice but to descend thru a layer.

In my 30 years or so of soaring I've needed a gyro 2 times, that alone
makes it part of my panel for keeps.

Brad

Google