A aviation & planes forum. AviationBanter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » AviationBanter forum » rec.aviation newsgroups » Soaring
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

WGC Final Report, John Good



 
 
Thread Tools Display Modes
  #21  
Old January 21st 20, 05:56 PM posted to rec.aviation.soaring
[email protected]
external usenet poster
 
Posts: 478
Default WGC Final Report, John Good

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.
  #22  
Old January 21st 20, 06:21 PM posted to rec.aviation.soaring
Chris Wedgwood[_2_]
external usenet poster
 
Posts: 100
Default WGC Final Report, John Good

On Monday, January 20, 2020 at 8:17:36 PM UTC+1, wrote:
https://ussoaringteams.org/john-good...c#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.
  #23  
Old January 21st 20, 06:25 PM posted to rec.aviation.soaring
Tom BravoMike
external usenet poster
 
Posts: 266
Default WGC Final Report, John Good

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-good...c#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.
  #24  
Old January 21st 20, 08:26 PM posted to rec.aviation.soaring
Tango Eight
external usenet poster
 
Posts: 962
Default WGC Final Report, John Good

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-good...c#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
  #25  
Old January 21st 20, 09:07 PM posted to rec.aviation.soaring
John Foster
external usenet poster
 
Posts: 354
Default WGC Final Report, John Good

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.
  #26  
Old January 21st 20, 09:12 PM posted to rec.aviation.soaring
Martin Gregorie[_6_]
external usenet poster
 
Posts: 699
Default WGC Final Report, John Good

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 a

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 a

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

  #27  
Old January 21st 20, 10:25 PM posted to rec.aviation.soaring
Chris Wedgwood[_2_]
external usenet poster
 
Posts: 100
Default WGC Final Report, John Good

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-good...c#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
  #28  
Old January 21st 20, 10:27 PM posted to rec.aviation.soaring
Dave Nadler
external usenet poster
 
Posts: 1,610
Default WGC Final Report, John Good

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 a

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 a

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

  #29  
Old January 22nd 20, 01:14 AM posted to rec.aviation.soaring
John Good
external usenet poster
 
Posts: 17
Default WGC Final Report, 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.

  #30  
Old January 22nd 20, 02:43 AM posted to rec.aviation.soaring
[email protected]
external usenet poster
 
Posts: 281
Default WGC Final Report, John Good

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.

 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
2015 Nephi OLC/XC Final Report [email protected] Soaring 21 July 8th 15 10:56 PM
Day 4 at Perry and final report Frank Paynter[_2_] Soaring 0 April 25th 11 04:39 AM
Region 10 South Report: Final Day Bob D Soaring 0 August 16th 09 05:00 AM
Final Report of SSA FRTF Now Available [email protected] Soaring 2 October 28th 07 03:23 AM
Annual Report Final. "Long" NW_PILOT Piloting 22 October 28th 04 07:20 PM


All times are GMT +1. The time now is 03:18 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 AviationBanter.
The comments are property of their posters.