WGC Final Report, John Good

[[email protected]]

https://ussoaringteams.org/john-goods-final-report-for-wwgc-2019/?unapproved=5830&moderation-hash=fb6ed211b9eede3b5eb9f6ae2823c5dc#comment-5830

[Tijl]

Good report from the view of a team captain in this unfortunate incident. I am very interested to hear from the side of the jury and of the Australian team, in how they experienced and see this.

Lessons should be learned, and the IGC will need to make some very clear decisions and rules.

I do disagree however with John on his conclusion: instead of allowing everything, we should go to even less groundbased support, and stricter enforcement.

Most pilots I know, hate gaggles and (startline) tactics. Most pilots want to simply fly and race head to head. FLARM and ground-based involvement including tracking-data, increase those gaggles and tactical games. And that makes gliding competitions more boring. It also makes competitions unsafer due to increased collision risk. I know a vice-world champion who has stopped competing for those reasons.

The IGC also agrees with that point of view. They reinforced this position in the 2019 general meeting.

But I also hear a lot of people saying, that "the cat is out of the bag" with tracking/internet-technology, "it's impossible to check if people are cheating, and you can't regulate and penalize what you can't check", and thus we should thus "we should allow everything, so it remains a level playing field".

All three arguments are wrong in my opinion.

First of all, regarding tracking, it's extremely easy and possible right at this moment to stop even a private "hacked" FLARM receiver network to track your FLARM-equipped glider. You don't even need "stealth mode" or "no-track mode" (although they help).

- In your Flarm, set your ICAO 24-bit code to "0". Each time you power up your Flarm, your Flarm-Radio ID will be newly randomly generated.

- With an LX9000 connected Flarm, whenever you feel you are tracked or followed, change your FLARM Radio ID manually in the Flarm-setup screen.

In this way, if someone has "locked on" to you (matched your FLARM-Radio ID to your Competition Number), you will magically "disappear" when the ID changes.

This makes all that effort of private OGN networks almost useless in practice.

On the second note ("you can't regulate, what you can't measure"), that's also not true. For instance, there are many products on the doping list that can't be screened for yet. Should we thus just allow those products? Surely not.

Similarly, turn-and-banks are prohibited in gliders to stop cloud flying. But now turn-and-banks are available in many cell-phones. Should we now thus just re-allow turn-and-banks? Of course not.


And the same is true with private "hacked" OGN networks, internet in the cockpit, ...

It's hard to enforce, certainly. But make it extremely clear that whoever caught breaking the rules, gets punished severely. That will stop the vast majority of cheating. Very few of the top pilots will risk it at all. And those extremely few who do, will be heavily punished if caught.

For instance, ban ground-based FLARM receivers from competitions. A team that gets caught is disqualified, except for the pilot who gives up their own cheating team partners. Very very few teams would still risk it, even if the chance of getting caught is low.

So, that leads me to conclude that we shouldn't go to "level the playing field" towards a situation which none of the pilots enjoy, and which increases collision risk.

We should go the opposite direction: broadcast the vision of the IGC more loudly (gliding competitions are meant to be pilots competitions, and not technology-arms-race or support crew competitions), make clear rules and penalties of what is allowed and what isn't, and then enforce them.

[Tango Eight]

On Monday, January 20, 2020 at 3:49:03 PM UTC-5, Tijl wrote:

> - In your Flarm, set your ICAO 24-bit code to "0". Each time you power up your Flarm, your Flarm-Radio ID will be newly randomly generated.
>

If so, this is quite the undocumented Easter egg. Can anyone confirm?

T8

[Tijl]

On Tuesday, 21 January 2020 00:01:29 UTC+1, Tango Eight wrote:
> On Monday, January 20, 2020 at 3:49:03 PM UTC-5, Tijl wrote:
>
> > - In your Flarm, set your ICAO 24-bit code to "0". Each time you power up your Flarm, your Flarm-Radio ID will be newly randomly generated.
> >
>
> If so, this is quite the undocumented Easter egg. Can anyone confirm?
>
> T8

It's not undocumented.

https://flarm.com/flarm-firmware-v6-40-released/

It works if you use the online Flarm configuration tool:

https://flarm.com/support/tools-software/flarm-configuration-tool/

Quote:

"ICAO 24-bit aircraft address, hexadecimal
Official 24-bit ICAO aircraft address in hexadecimal notation, as issued by local CAA. It consists of six hexadecimal characters (0-9, a-f) and can be obtained from the aircraft papers. Must match the address configured in the Mode-S transponder. If the aircraft does not have a Mode-S transponder, it's possible to leave the field empty to use the device specific radio id. Enter "0" (zero) for random id (not recommended, will make Search and Rescue (SAR) very difficult)."

[Tango Eight]

On Monday, January 20, 2020 at 6:09:28 PM UTC-5, Tijl wrote:
> On Tuesday, 21 January 2020 00:01:29 UTC+1, Tango Eight wrote:
> > On Monday, January 20, 2020 at 3:49:03 PM UTC-5, Tijl wrote:
> >
> > > - In your Flarm, set your ICAO 24-bit code to "0". Each time you power up your Flarm, your Flarm-Radio ID will be newly randomly generated.
> > >
> >
> > If so, this is quite the undocumented Easter egg. Can anyone confirm?
> >
> > T8
>
> It's not undocumented.
>
> https://flarm.com/flarm-firmware-v6-40-released/
>
> It works if you use the online Flarm configuration tool:
>
> https://flarm.com/support/tools-software/flarm-configuration-tool/
>
> Quote:
>
> "ICAO 24-bit aircraft address, hexadecimal
> Official 24-bit ICAO aircraft address in hexadecimal notation, as issued by local CAA. It consists of six hexadecimal characters (0-9, a-f) and can be obtained from the aircraft papers. Must match the address configured in the Mode-S transponder. If the aircraft does not have a Mode-S transponder, it's possible to leave the field empty to use the device specific radio id.. Enter "0" (zero) for random id (not recommended, will make Search and Rescue (SAR) very difficult)."

Thank you...

T8

[mart]

I completely agree that it should be pilot skills and not technology that determines the winners.


Your idea is unfortunately very easy to circumvent, put someone in a car near the end of the runway at launch time with a reciever and write down code and rego.

I would more go for random turnpoints in a circle so that every pilot flies the same distance but you wont know if the pilot you see has done more or less of the task than you did.

[John Foster]

On Monday, January 20, 2020 at 5:23:28 PM UTC-7, mart wrote:
> I completely agree that it should be pilot skills and not technology that determines the winners.
>
>
> Your idea is unfortunately very easy to circumvent, put someone in a car near the end of the runway at launch time with a reciever and write down code and rego.
>
> I would more go for random turnpoints in a circle so that every pilot flies the same distance but you wont know if the pilot you see has done more or less of the task than you did.

I think it could simplify a lot of things if they changed the rules to be more like sailboat racing. The start line opens at a specific time, and whoever crosses the line first is the winner. None of this delayed start stuff. Everyone is racing against each other in real time. The guys behind can see where the leaders are climbing, and maybe make up some time, but in order to win, you have to be in front. Much like they do in SGP racing. That format just makes more sense to me. I realize it is quite a bit different from how things have been done for many years, but it could eliminate a lot of the advantages folks would get from this whole live-tracking thing.

[Tijl]

That wouldn't circumvent manual Flarm-ID changes at any given moment within the flight (with an LX9000 connection for instance).

You can also quickly power your Flarm off an on after take-off, thereby creating a new random ID.

I am sure if the IGC asks for it, FLARM can quickly bring out a feature that triggers a ID-randomizer every 15 minutes during the flight. But that would not even be necessary in my opinion.


Also, if the punishment of having a private ground-based Flarm receiver in a team is disqualification for the whole team, and if the rules on this are 100% clear and widely known, who in their right mind would do this?

[Dan Daly[_2_]]

On Monday, January 20, 2020 at 7:46:03 PM UTC-5, Tijl wrote:
> That wouldn't circumvent manual Flarm-ID changes at any given moment within the flight (with an LX9000 connection for instance).
>
> You can also quickly power your Flarm off an on after take-off, thereby creating a new random ID.
>
> I am sure if the IGC asks for it, FLARM can quickly bring out a feature that triggers a ID-randomizer every 15 minutes during the flight. But that would not even be necessary in my opinion.
>
>
> Also, if the punishment of having a private ground-based Flarm receiver in a team is disqualification for the whole team, and if the rules on this are 100% clear and widely known, who in their right mind would do this?

I would be surprised if changing the ICAO ID didn't violate the IGC file security and validation.

[[email protected]]

On Monday, January 20, 2020 at 7:36:09 PM UTC-5, John Foster wrote:
> On Monday, January 20, 2020 at 5:23:28 PM UTC-7, mart wrote:
> > I completely agree that it should be pilot skills and not technology that determines the winners.
> >
> >
> > Your idea is unfortunately very easy to circumvent, put someone in a car near the end of the runway at launch time with a reciever and write down code and rego.
> >
> > I would more go for random turnpoints in a circle so that every pilot flies the same distance but you wont know if the pilot you see has done more or less of the task than you did.
>
> I think it could simplify a lot of things if they changed the rules to be more like sailboat racing. The start line opens at a specific time, and whoever crosses the line first is the winner. None of this delayed start stuff. Everyone is racing against each other in real time. The guys behind can see where the leaders are climbing, and maybe make up some time, but in order to win, you have to be in front. Much like they do in SGP racing. That format just makes more sense to me. I realize it is quite a bit different from how things have been done for many years, but it could eliminate a lot of the advantages folks would get from this whole live-tracking thing..

The size of the field matters. SGP has relatively small field intentionally..
I flew in one of the first "bomb burst" starts about 25 years ago. There were about 50 ships, all at cloud base when the go signal was sent. We almost all came back saying that we never wanted to do that again.
This concept also puts everyone in one big gaggle which can be highly dangerous.
Been there - done that.
In my view the solution is to work to make FLARM the collision avoidance tool it is meant to be, and do whatever can be done to stop tracking and minimize the benefits of FLARM radar. Start with option for no ID. Kill climb rate information. Make range only what it needs to be for collision avoidance. Stealth does some of this.
UH

[Dave Springford]

How to fix future WGCs

1. Take away the team flying

[Dave Springford]

How to fix future WGCs so they measure pilot ability, not the ability of countries to cheat within the rules. Level the playing field for small countries that can not field large complex teams. After all, is the WGC not meant to determine the best pilot?

1. Take away the team flying
a. one pilot per country per class
b. no pilot-to pilot communication except safety calls
c. no pilot to ground communication

2. Take away the ground "team"
a. no tactical information to pilots from any source outside their eyeballs and on-board flarm


3. Institute harsh penalties such as Tijl suggest that would disqualify the team for the duration of the competition and ban the offending pilot for life.

4. Apply pilot event marker controlled starts to minimize start gate games.


This trajectory the WGC is on is destructive as shown by the blatant cheating that occurs within loopholes while trying to get "your" country on top instead of trying to determine the best pilot at the competition.

[Tom BravoMike]

On Monday, January 20, 2020 at 1:17:36 PM UTC-6, wrote:
> https://ussoaringteams.org/john-goods-final-report-for-wwgc-2019/?unapproved=5830&moderation-hash=fb6ed211b9eede3b5eb9f6ae2823c5dc#comment-5830

Eureka! The solution is in 'cockpit voice and video recording' for all flights, easily achieved with commonly available matchbox size cameras with prices beginning at $35. At 720p resolution, a medium capacity microSD card would save the whole flight; a small external source for power supply will be needed. Everything still way more compact than the photo cameras we used in the past to take pictures of the turning points. Any illicit help from the ground (radio or image) would be recorded. The recordings provided along with the IGC logs, checked at random and/or on demand. A substantial penalty for a missing recording. Garmin Virb and latest GoPro cameras (higher price mark) provide geo-referencing, too. How many cars drive these days with 'dash cameras'?

[Martin Gregorie[_6_]]

On Mon, 20 Jan 2020 17:01:24 -0800, Dan Daly wrote:

> On Monday, January 20, 2020 at 7:46:03 PM UTC-5, Tijl wrote:
>> That wouldn't circumvent manual Flarm-ID changes at any given moment
>> within the flight (with an LX9000 connection for instance).
>>
>> You can also quickly power your Flarm off an on after take-off, thereby
>> creating a new random ID.
>>
>> I am sure if the IGC asks for it, FLARM can quickly bring out a feature
>> that triggers a ID-randomizer every 15 minutes during the flight. But
>> that would not even be necessary in my opinion.
>>
>>
>> Also, if the punishment of having a private ground-based Flarm receiver
>> in a team is disqualification for the whole team, and if the rules on
>> this are 100% clear and widely known, who in their right mind would do
>> this?
>
> I would be surprised if changing the ICAO ID didn't violate the IGC file
> security and validation.

Its not recorded anywhere in an ICG flight log, so no problem there.

I've written and tested a Java class for decoding IGC logs, so needed to
understand precisely what's in every record type (except the G record,
whose exact format is logger-specific. Thats because the checksum format
is not defined by the standard: its specified and known only by the
manufacturer.


--
Martin | martin at
Gregorie | gregorie dot org

[krasw]

tiistai 21. tammikuuta 2020 6.04.24 UTC+2 Tom BravoMike kirjoitti:
> On Monday, January 20, 2020 at 1:17:36 PM UTC-6, wrote:
> > https://ussoaringteams.org/john-goods-final-report-for-wwgc-2019/?unapproved=5830&moderation-hash=fb6ed211b9eede3b5eb9f6ae2823c5dc#comment-5830
>
> Eureka! The solution is in 'cockpit voice and video recording' for all flights, easily achieved with commonly available matchbox size cameras with prices beginning at $35. At 720p resolution, a medium capacity microSD card would save the whole flight; a small external source for power supply will be needed. Everything still way more compact than the photo cameras we used in the past to take pictures of the turning points. Any illicit help from the ground (radio or image) would be recorded. The recordings provided along with the IGC logs, checked at random and/or on demand. A substantial penalty for a missing recording. Garmin Virb and latest GoPro cameras (higher price mark) provide geo-referencing, too. How many cars drive these days with 'dash cameras'?

130 competitors flying 6 hrs+, you would be staring at 800 hrs of videos per day in WGC. Should be doable by 100 volunteers over night, though. But what if pilot have a small in-ear headphone for listening to radio?

[Mike N.]

On Monday, January 20, 2020 at 2:17:36 PM UTC-5, wrote:
> https://ussoaringteams.org/john-goods-final-report-for-wwgc-2019/?unapproved=5830&moderation-hash=fb6ed211b9eede3b5eb9f6ae2823c5dc#comment-5830

It seems clear that the intent and spirit of the 15 minute delayed tracking rule were well understood by all.
Using an unsecured tracking site to eliminate the 15 minute delay is a violation of the intent and spirit of the rule.
While it could be argued that there was no specific rule against using the unsecured GFA tracking data, the intent and spirit of the 15 minute delayed tracking rule were still being violated.
The honorable action for whomever on the Australian team, discovered the unsecured GFA site would have been to report it to the competition organizers so that the issue of un-delayed / unsecured GFA tracking could have been mitigated in some fashion.
Competitive soaring to me is a wonderful thing, testing pilot skill against pilot skill at a high level. Using loopholes to violate the intention and spirit of rules clearly created to create a level playing field, degrades and dishonors our sport to just another "best cheater wins" sport.

[[email protected]]

John did a great job on the summary, but I'd like to think there is another path forward in the rules.


1) Like Golf, the rules could be focused on testing pilot skill assuming the pilots police themselves. The idea that some rule would not be practical because it is hard to enforce seems contrary to the sort of folks that soaring draws. This might include the idea that self enforcement draws a smaller penalty than getting caught.

2) The current rules are written in the negative which creates loopholes for what you have forgotten. If, instead they listed what was permitted, then the opportunity for the holes might be less. For example, the pilot is only permitted information from the following electronic means...

I think depending on the race, there is room for wildly different permitted lists. Grand Prix might expect a ground controller and full tracking with the controller on the podium along with the pilot. A pilot testing race might go the opposite with a very short list.

[Jim White[_3_]]

At 00:36 21 January 2020, John Foster wrote:
>On Monday, January 20, 2020 at 5:23:28 PM UTC-7, mart wrote:
>> I completely agree that it should be pilot skills and not technology
>that=
> determines the winners.
>> =20
>>=20
>> Your idea is unfortunately very easy to circumvent, put someone in a
car
>=
>near the end of the runway at launch time with a reciever and write down
>co=
>de and rego.=20
>> =20
>> I would more go for random turnpoints in a circle so that every pilot
>fli=
>es the same distance but you wont know if the pilot you see has done more
>o=
>r less of the task than you did.
>
>I think it could simplify a lot of things if they changed the rules to be
>m=
>ore like sailboat racing. The start line opens at a specific time, and
>who=
>ever crosses the line first is the winner. None of this delayed start
>stuf=
>f. Everyone is racing against each other in real time. The guys behind
>ca=
>n see where the leaders are climbing, and maybe make up some time, but in
>o=
>rder to win, you have to be in front. Much like they do in SGP racing.
>Th=
>at format just makes more sense to me. I realize it is quite a bit
>differe=
>nt from how things have been done for many years, but it could eliminate
a
>=
>lot of the advantages folks would get from this whole live-tracking
thing.
>
Distance Handicap Tasks do this great for handicap competition even with
pilot selected start time. see www.handicaptask.uk

[Jim White[_3_]]

At 09:13 21 January 2020, Martin Gregorie wrote:
>On Mon, 20 Jan 2020 17:01:24 -0800, Dan Daly wrote:
>
>> On Monday, January 20, 2020 at 7:46:03 PM UTC-5, Tijl wrote:
>>> That wouldn't circumvent manual Flarm-ID changes at any given moment
>>> within the flight (with an LX9000 connection for instance).
>>>
>>> You can also quickly power your Flarm off an on after take-off,
thereby
>>> creating a new random ID.
>>>
>>> I am sure if the IGC asks for it, FLARM can quickly bring out a
feature
>>> that triggers a ID-randomizer every 15 minutes during the flight. But
>>> that would not even be necessary in my opinion.
>>>
>>>
>>> Also, if the punishment of having a private ground-based Flarm
receiver
>>> in a team is disqualification for the whole team, and if the rules on
>>> this are 100% clear and widely known, who in their right mind would do
>>> this?
>>
>> I would be surprised if changing the ICAO ID didn't violate the IGC
file
>> security and validation.
>
>Its not recorded anywhere in an ICG flight log, so no problem there.
>
>I've written and tested a Java class for decoding IGC logs, so needed to
>understand precisely what's in every record type (except the G record,
>whose exact format is logger-specific. Thats because the checksum format
>is not defined by the standard: its specified and known only by the
>manufacturer.
>
>
>--
>Martin | martin at
>Gregorie | gregorie dot org
>
>
Below is detail from my Flarm generated IGC trace:

LFLA111322011
LFLA111323 STEALTH OFF
LFLA111323ID 2 DDE24

As you can see it does show my ICAO number. You are however correct that
Log records (prefixed by L) are not used when generating the G record for
integrity checking.

Jim

[Dave Nadler]

On Monday, January 20, 2020 at 8:11:09 PM UTC-5, wrote:
> I flew in one of the first "bomb burst" starts about 25 years ago.
> There were about 50 ships, all at cloud base when the go signal was sent.
> We almost all came back saying that we never wanted to do that again.

I remember that one - terrifying.
IIRC that was also the USA intro of the DG-600, for sale by mid-contest...

Both concentrating everyone at the start was bad AND the first few gaggles
was quite dangerous. Even in SGP format (limited number of contestants) the
starts have been much too exciting...

[[email protected]]

Anyone looking into who made the obscure nondelayed tracking website? Was the website built to enhance one team's race coaching. Left open for plausible denial, confident no one is going to find it by accident. Less sportsmanlike but more likely than happenstance finding a website giving nondelayed tracking data for the World Championships you just happen to be coaching.

[Chris Wedgwood[_2_]]

On Monday, January 20, 2020 at 8:17:36 PM UTC+1, wrote:
> https://ussoaringteams.org/john-goods-final-report-for-wwgc-2019/?unapproved=5830&moderation-hash=fb6ed211b9eede3b5eb9f6ae2823c5dc#comment-5830

I've suggested this before but nobody agreed.

The solution is to have predetermined start times, randomised each day. Scoring calculated from this start time. Penalties for starting before the time, no penalties for late starting, because the extra delay is it's own penalty.

[Tom BravoMike]

On Tuesday, January 21, 2020 at 5:55:25 AM UTC-6, krasw wrote:
> tiistai 21. tammikuuta 2020 6.04.24 UTC+2 Tom BravoMike kirjoitti:
> > On Monday, January 20, 2020 at 1:17:36 PM UTC-6, wrote:
> > > https://ussoaringteams.org/john-goods-final-report-for-wwgc-2019/?unapproved=5830&moderation-hash=fb6ed211b9eede3b5eb9f6ae2823c5dc#comment-5830
> >
> > Eureka! The solution is in 'cockpit voice and video recording' for all flights, easily achieved with commonly available matchbox size cameras with prices beginning at $35. At 720p resolution, a medium capacity microSD card would save the whole flight; a small external source for power supply will be needed. Everything still way more compact than the photo cameras we used in the past to take pictures of the turning points. Any illicit help from the ground (radio or image) would be recorded. The recordings provided along with the IGC logs, checked at random and/or on demand. A substantial penalty for a missing recording. Garmin Virb and latest GoPro cameras (higher price mark) provide geo-referencing, too. How many cars drive these days with 'dash cameras'?
>
> 130 competitors flying 6 hrs+, you would be staring at 800 hrs of videos per day in WGC. Should be doable by 100 volunteers over night, though. But what if pilot have a small in-ear headphone for listening to radio?

You have not noticed this in my message: The recordings (...) checked at random and/or on demand.

But you are right about the hidden earphone, and possibly a heads-up display (HUD) mounted in sunglasses. The situation is helpless... So I'll stay out of competitions and continue my lonely exploration/fun/diamonds cross-country flights with all the navigation and safety devices fully ON.

[Tango Eight]

On Tuesday, January 21, 2020 at 12:21:28 PM UTC-5, Chris Wedgwood wrote:
> On Monday, January 20, 2020 at 8:17:36 PM UTC+1, wrote:
> > https://ussoaringteams.org/john-goods-final-report-for-wwgc-2019/?unapproved=5830&moderation-hash=fb6ed211b9eede3b5eb9f6ae2823c5dc#comment-5830
>
> I've suggested this before but nobody agreed.
>
> The solution is to have predetermined start times, randomised each day. Scoring calculated from this start time. Penalties for starting before the time, no penalties for late starting, because the extra delay is it's own penalty.

That would work great in Condor :-).

T8

[John Foster]

On Monday, January 20, 2020 at 6:11:09 PM UTC-7, wrote:
> On Monday, January 20, 2020 at 7:36:09 PM UTC-5, John Foster wrote:
> > On Monday, January 20, 2020 at 5:23:28 PM UTC-7, mart wrote:
> > > I completely agree that it should be pilot skills and not technology that determines the winners.
> > >
> > >
> > > Your idea is unfortunately very easy to circumvent, put someone in a car near the end of the runway at launch time with a reciever and write down code and rego.
> > >
> > > I would more go for random turnpoints in a circle so that every pilot flies the same distance but you wont know if the pilot you see has done more or less of the task than you did.
> >
> > I think it could simplify a lot of things if they changed the rules to be more like sailboat racing. The start line opens at a specific time, and whoever crosses the line first is the winner. None of this delayed start stuff. Everyone is racing against each other in real time. The guys behind can see where the leaders are climbing, and maybe make up some time, but in order to win, you have to be in front. Much like they do in SGP racing. That format just makes more sense to me. I realize it is quite a bit different from how things have been done for many years, but it could eliminate a lot of the advantages folks would get from this whole live-tracking thing.
>
> The size of the field matters. SGP has relatively small field intentionally.
> I flew in one of the first "bomb burst" starts about 25 years ago. There were about 50 ships, all at cloud base when the go signal was sent. We almost all came back saying that we never wanted to do that again.
> This concept also puts everyone in one big gaggle which can be highly dangerous.
> Been there - done that.
> In my view the solution is to work to make FLARM the collision avoidance tool it is meant to be, and do whatever can be done to stop tracking and minimize the benefits of FLARM radar. Start with option for no ID. Kill climb rate information. Make range only what it needs to be for collision avoidance. Stealth does some of this.
> UH

I would agree that the size of the field matters. What would the maximum size field be that you would consider safe? How much smaller is that than current class sizes in current US contests? For a world championship contest, it could be run much like a swim meet, or other such contest where you have qualifying races with elimination rounds followed by a final race. That would be quite different than how we do things today, but I think we could take a lot from how the sport of sailing does things. They also have to deal with safety issues with mass starts and traffic and changing weather conditions across the course and throughout the day. I think that this kind of format could fix many of the issues (not all though) we are wrestling with.

[Martin Gregorie[_6_]]

On Tue, 21 Jan 2020 14:54:13 +0000, Jim White wrote:

> At 09:13 21 January 2020, Martin Gregorie wrote:
>>On Mon, 20 Jan 2020 17:01:24 -0800, Dan Daly wrote:
>>
>>> On Monday, January 20, 2020 at 7:46:03 PM UTC-5, Tijl wrote:
>>>> That wouldn't circumvent manual Flarm-ID changes at any given moment
>>>> within the flight (with an LX9000 connection for instance).
>>>>
>>>> You can also quickly power your Flarm off an on after take-off,
> thereby
>>>> creating a new random ID.
>>>>
>>>> I am sure if the IGC asks for it, FLARM can quickly bring out a
> feature
>>>> that triggers a ID-randomizer every 15 minutes during the flight. But
>>>> that would not even be necessary in my opinion.
>>>>
>>>>
>>>> Also, if the punishment of having a private ground-based Flarm
> receiver
>>>> in a team is disqualification for the whole team, and if the rules on
>>>> this are 100% clear and widely known, who in their right mind would
>>>> do this?
>>>
>>> I would be surprised if changing the ICAO ID didn't violate the IGC
> file
>>> security and validation.
>>
>>Its not recorded anywhere in an ICG flight log, so no problem there.
>>
>>I've written and tested a Java class for decoding IGC logs, so needed to
>>understand precisely what's in every record type (except the G record,
>>whose exact format is logger-specific. Thats because the checksum format
>>is not defined by the standard: its specified and known only by the
>>manufacturer.
>>
>>
>>--
>>Martin | martin at Gregorie | gregorie dot org
>>
>>
> Below is detail from my Flarm generated IGC trace:
>
> LFLA111322011 LFLA111323 STEALTH OFF LFLA111323ID 2 DDE24
>
> As you can see it does show my ICAO number. You are however correct that
> Log records (prefixed by L) are not used when generating the G record
> for integrity checking.
>
Hi Jim,

According to the second edition, 3rd amendment of the "TECHNICAL
SPECIFICATION FOR GNSS FLIGHT RECORDERS" dated 30 June 2014, the L record
is defined as a 'logbook' or 'comment' where the hardware source defines
the format of everything in the L record from the 5th character onward.

In your example L records, the first letter will always be
'L' (obviously!). The next three letters are a manufacturer code (in this
case FLA, so the rest of its content is in a FLARM-defined format. The
only GNSS-defined source codes are:

PLT (pilot input),
OOI (Official Observer input),
PFC (after-flight pilot input).

So it follows that any other code identifies the hardware manufacturer
whose kit wrote the IGC log. The definition includes a list of approved
codes.

I understand your point, but the GNSS standard is a little more complex
when talking about validation; it says that L records with a
manufacturers ID in characters 2-4 *must* be included in the validation
check but those with PLT, OOI or PFC codes *must not* be included,
presumably because they're expected to be unformatted free text.

My take on this is that, since LFLA records are defined by FLARM, then
there's no guarantee that L records output by any other manufacturers kit
will contain an ICAO number or, indeed, that an non-FLARM log will
contain any L records.

I've just searched my personal IGC log connection, which are all
recorded by LK8000, XCSOAR, LK8000, my EW Microrecorder or an EW model D
I used to own. None of these contain any L records. However, logs from my
RedBox FLARM contain huge numbers of them - roughly one L record for
every 3.5 B records. The nearest set of L records in it that I can see to
your three records are:

LFLA111458011
LFLA111459 STEALTH OFF
LFLA111459 NOTRACK OFF
LFLA111459ID 2 DDD4EF

which are preceded by 18 unintelligible (to me, anyway) L records and
followed 14 L records that look very much like the contents of my
flarmcfg.txt file combined by some of the stuff in the FLARMDEV.CSV file,
which was generated by my RedBox, and which contains the warning:

Auto-generated file, don't edit!

I haven't configured my FLARM box with an ICAO ID since AFAIK I don't
have one. The ID it seems to have assumed, DDD4EF, is defined in the
autogenerated file, FLARMDEV.CSV

My reason for writing this stuff is that I'm curious how similar the
output from my old RedBox is to what FLARM systems from other instrument
makers put in IGC logs that they generate.


--
Martin | martin at
Gregorie | gregorie dot org

[Chris Wedgwood[_2_]]

On Tuesday, January 21, 2020 at 8:26:58 PM UTC+1, Tango Eight wrote:
> On Tuesday, January 21, 2020 at 12:21:28 PM UTC-5, Chris Wedgwood wrote:
> > On Monday, January 20, 2020 at 8:17:36 PM UTC+1, wrote:
> > > https://ussoaringteams.org/john-goods-final-report-for-wwgc-2019/?unapproved=5830&moderation-hash=fb6ed211b9eede3b5eb9f6ae2823c5dc#comment-5830
> >
> > I've suggested this before but nobody agreed.
> >
> > The solution is to have predetermined start times, randomised each day. Scoring calculated from this start time. Penalties for starting before the time, no penalties for late starting, because the extra delay is it's own penalty.
>
> That would work great in Condor :-).
>
> T8

Condor tracks real life, not the other way round :)

[Dave Nadler]

On Tuesday, January 21, 2020 at 3:12:18 PM UTC-5, Martin Gregorie wrote:
> According to the second edition, 3rd amendment of the "TECHNICAL
> SPECIFICATION FOR GNSS FLIGHT RECORDERS" dated 30 June 2014, the L record
> is defined as a 'logbook' or 'comment' where the hardware source defines
> the format of everything in the L record from the 5th character onward.

In the many message specifications with which I've ever worked, comments
have always been used as a dumping ground for anything and everything that
was needed by someone but not included in the specification.
For example SWIFT messages ;-)

The users (in this case logger manufacturers) always get ahead of the
standardization, especially if the standards process is not hugely
responsive or takes too long. SWIFT for example had a one year comment
period, then a one year test cycle (anyway decades ago when I worked
on that stuff). You'd really prefer SWIFT not to break, hence the caution ;-)

Sometimes the comment overload becomes standardized, leading to further
confusion. See for example PLT below.

The PLT/OOI/PFC stuff was standardized to allow persistent additional info
in the log (ie your comments, entered in your favorite flight review sw),
without deranging the security system.

> In your example L records, the first letter will always be
> 'L' (obviously!). The next three letters are a manufacturer code (in this
> case FLA, so the rest of its content is in a FLARM-defined format. The
> only GNSS-defined source codes are:
>
> PLT (pilot input),
> OOI (Official Observer input),
> PFC (after-flight pilot input).
>
> So it follows that any other code identifies the hardware manufacturer
> whose kit wrote the IGC log. The definition includes a list of approved
> codes.
>
> I understand your point, but the GNSS standard is a little more complex
> when talking about validation; it says that L records with a
> manufacturers ID in characters 2-4 *must* be included in the validation
> check but those with PLT, OOI or PFC codes *must not* be included,
> presumably because they're expected to be unformatted free text.
>
> My take on this is that, since LFLA records are defined by FLARM, then
> there's no guarantee that L records output by any other manufacturers kit
> will contain an ICAO number or, indeed, that an non-FLARM log will
> contain any L records.
>
> I've just searched my personal IGC log connection, which are all
> recorded by LK8000, XCSOAR, LK8000, my EW Microrecorder or an EW model D
> I used to own. None of these contain any L records. However, logs from my
> RedBox FLARM contain huge numbers of them - roughly one L record for
> every 3.5 B records. The nearest set of L records in it that I can see to
> your three records are:
>
> LFLA111458011
> LFLA111459 STEALTH OFF
> LFLA111459 NOTRACK OFF
> LFLA111459ID 2 DDD4EF
>
> which are preceded by 18 unintelligible (to me, anyway) L records and
> followed 14 L records that look very much like the contents of my
> flarmcfg.txt file combined by some of the stuff in the FLARMDEV.CSV file,
> which was generated by my RedBox, and which contains the warning:
>
> Auto-generated file, don't edit!
>
> I haven't configured my FLARM box with an ICAO ID since AFAIK I don't
> have one. The ID it seems to have assumed, DDD4EF, is defined in the
> autogenerated file, FLARMDEV.CSV
>
> My reason for writing this stuff is that I'm curious how similar the
> output from my old RedBox is to what FLARM systems from other instrument
> makers put in IGC logs that they generate.

RedBox, as a dozen other devices, contain a FLARM OEM module with FLARM software. Hence the results had better be similar ;-)

Hope that helps!
Best Regards, Dave

[John Good]

Tijl wrote:

> I do disagree however with John on his conclusion: instead of allowing
> everything, we should go to even less groundbased support, and stricter
> enforcement.

That wasn't really my conclusion. Indeed, I believe limiting (eliminating?) ground-based support has real merit. The important problem - noted by many - is that rules to this effect are essentially impossible to enforce.

A case can be made that the current situation may be the worst choice: some teams have real-time tracking data; many don't. With all its problems, allowing equal access to useful data seems preferable.

[[email protected]]

>>The important problem - noted by many - is that rules to this effect are essentially impossible to enforce.

I really think this view sells the pilots in this sport short. Sure the CD can't see what happens in the cockpit, but each pilot knows and given the right set of rules and incentives, self enforcement seems a viable way past the 'impossible to enforce' hurdle.

[Tijl]

I don't think low enforceability is a big issue. For example, some doping products have a very low chance of detection. That doesn't mean they should be reallowed.

As another example, in the Sailplane Grand Prix, any communication outside of the main radio frequency is not allowed. This can also be "essentially impossible to enforce", since you can't monitor 2280 radio channels. Nevertheless, in last years SGP World Final, 2 pilots who were suspected of collaborating were caught on the last flying day of the competition, and thus penalized.



The problem in my opinion, is that it isn't 100% clearly communicated right now what is allowed and what isn't.

If it was very clear that "hacked" FLARM receivers were illegal, and the penalties are very harsh when caught (team disqualification), almost no team would still risk it, even if the chance of getting caught was small.


By the way, there is a good argument to be made, that "hacked" flarm receivers are already not legal within the current rules.

In SC3a, Para 5.4.2 says: "5.4.2 Penalties may be imposed by the Organisers for unauthorized interference with the GNSS equipment, data or internal program, or Tracking equipment."

(*Penalties are not specified, and up to the organisation.)

Then SC3a, Para 7.5.2 says: "COLLISION AVOIDANCE AND TRACKING: Pilots are allowed to configure low power modes, limited information modes, and requests for “no tracking.” "


Combining those two paragraphs, "hacked" (groundbased or cockpit) Flarm receivers that circumvent FLARM-stealth and no-track mode (which have only been legal since last year), can be seen as "unauthorized interference with the GNSS equipment, data or internal program, or Tracking equipment", and thus could be penalized already under current rules.

Additionally, for a groundteam who is monitoring an undelayed OGN-clone and transmitting that to their pilots, you could call upon the spirit of the rule "Attempt to obtain external help for finding lift from non competing glider or airplane", for which the penalty is day disqualification.

In the Sailplane Grand Prix, it is better worded, and much more clear:

From SGPRules V9.0, Para 5.3.1: "External aid to competitors: Radio Transmitters and Transceiver: Radios are for voice transmissions between team members and between them and the Organisers only. Any other data transmission between competitors, or between them and the ground, is prohibited except as required: (i) by the organisers; or (ii) for safety purpose or; (iii) for anticollision warning, The Organisers shall designate a common radio frequency on which all transmissions will be made during the contest. All pilots shall remain on this frequency. Non-compliance may be
penalized."

So, in SGP even data transmission (including weather-data in the cockpit) is currently banned. I don't see why the same clear rules could not apply to all other competitions.