Christian's GPS screws up someone else.(Ager, Spain)

Gordon Rigg, who always enjoys a controversy, <<gordon.rigg245km>> writes:

Attila took third ahead of final task winner Mario Alonzi by just five interesting points.

Christian Chiech physically passed the goal line second on the last day, behind Mario but still half of a kilometer ahead of the pack, which was Attila, Alex, Martin and me. For unknown reasons his GPS and scoring system put Christian behind us all in 8th place almost a minute behind his true finish position. Initially Christian and the Italian team questioned this.

The tracks are available on the ager2010 scorers blog. You can see his GPS is dropping out regularly on the flight and badly on the last part of the final glide. I'm don't think the time data is in the kml track log file which is all the scorer published, but this is the likely reason for the the strange time error.

The French took up the protest because correcting the finish order would most probably take enough points away from Attila to put Mario 3rd (in the official results one second between Attila into goal second and Alex into goal 3rd on the last day is worth eight points, and Attila took the bronze officially by just 5 points).

Also it seems that on earlier tasks there had been a manual correction of finish order (unlike on this last day). There are also some problems with earlier 6030 firmware that is known to lose four seconds compared to the latest, but larger errors like Christian's on the last day were not encountered previously.

It seems that in the end CIVL officials refused to allow a manual correction of Christian's finish time for the last task (I'm not sure if previous smaller manual corrections actually occurred or not), even though many pilots agreed that the published result was wrong. Mario was not impressed and refused to collect the 4th place FAI diploma and was not present at the prize giving.

I think the only way to regard it is as a strange non catastrophic GPS failure for Christian that worked out in Attila's favor. In the end the final scores are altered by everyone else's score, even if that score is due to a dodgy GPS (or a good one is a dodgy carbon pod).

GPS's are so much better than anything we had to score with previously (pilots were getting away with half a kilometer on every turnpoint a few short years ago), but it is not yet 100% reliable and accurate. In any case, take a look at your track logs and if there are regular dropouts send it back to the manufacturer. The dropouts are easily recognised from vast altitude errors (sea level points). Those dropouts might cost you your score, but may also affect someone else's significantly!

The Oz Report:

don't think the time data is in the kml track log file

It is, as "Seconds From Time Of First Point", where the "time of first point" is "2010-07-23T13:17:42Z". You might have to adjust for the local time zone (from GMT), and there's no indication if the time was set to GPS time or manually set.

Looks like the GPS wasn't getting enough satellites for a 3-D fix at times, where it would record "0" for the altitude. The position would stop getting updates too, when there weren't enough for even a 2-D fix. Best to ignore the recorded positions when there's no altitude.

It kept recording pressure-altitudes so those could be used to fill in the missing GPS altitudes. The relationship between the two wasn't constant but probably good enough for interpolation. Strange, the pressure GPS altitudes seem to lag after the GPS barometric altitudes by 10 to 20 seconds.



Here's a Google Earth version of his track log, using the recorded pressure altitudes, without the unreliable non-3D-fix positions, with the recorded times as the names of the points:

The Oz Report:

I think the only way to regard it is as a strange non catastrophic GPS failure for Christian that worked out in Attila's favor…
Those dropouts might cost you your score, but may also affect someone else's significantly!

I think it is not a problem of faulty GPS. Dropouts means lost of altitude information only but not position and time.
Ciech's tracklog is enough good to make a fair judgement.
First of all I've analyzed tracklogs from this archive http://www.filefactory.com/file/b2b04dd/n/TASK9_KML_TRACKS.zip
Positions are sorted by "Official time"

Code:

                  My time   Official time   Diff
Mario Alonzi      17:19:05    17:19:15     0:00:10
Atilla Bertok     17:20:51    17:21:01     0:00:10
Alessandro Ploner 17:20:51    17:21:02     0:00:11
Martin Harri      17:20:55    17:21:06     0:00:11
Gordon Rigg       17:21:15    17:21:27     0:00:12
Christian Ciech   17:20:59    17:21:53     0:00:54

It's strange "Diff" in last position, isn't it?

Then i ask myself: "maybe problem lays inside FS?"
It takes to me about 20 minutes to setup FS (v.1.2.13) according CE's task9.
All necessary information I've got from this page http://ager2010.com/results2010/TASK9.html
Tracklogs was used from link above without any modifications.

Take a look on "Time" column: http://www2.stealthcomp.com/mopo3/results/ce2010/task_result_ce2010.html
Any questions?

It is not a faulty GPS. It's strange judgment. That is point.

P.S. Another strange thing: routes' lengths differs by 400 m (official and my versions). Waypoints are the same. Can't understand.

Frost:

Dropouts means lost of altitude information only but not position and time.

The dropouts would also lose position. GPS altitude would go to 0 first, then the position would stop getting updated. Time & pressure-altitude would continue to be recorded, but what good are those without position?

SecondsFromTimeOfFirstPoint	PressureAltitude	lon	lat	alt	calculated-time
157	1575	0.741067	42.038750	1568	13:20:19
159	1581	0.741117	42.038667	0	13:20:21
161	1587	0.741117	42.038667	0	13:20:23
163	1592	0.741117	42.038667	0	13:20:25
165	1596	0.741583	42.037967	1568	13:20:27
167	1598	0.741583	42.037967	0	13:20:29
169	1597	0.741583	42.037967	0	13:20:31
171	1610	0.741933	42.037717	1568	13:20:33
173	1622	0.741833	42.037967	1568	13:20:35
175	1621	0.741717	42.038050	1569	13:20:37
177	1625	0.741683	42.038000	1569	13:20:39
179	1635	0.741683	42.038000	0	13:20:41
181	1642	0.741783	42.037700	1569	13:20:43

The worst dropouts were 2 that were 12 samples long, resulting in spans of 28 and 26 seconds between recorded positions. They shouldn't have made a difference unless they were right at a turnpoint or start or finish cylinder. I don't know where those were.

Scare!:

The dropouts would also lose position. GPS altitude would go to 0 first, then the position would stop getting updated. Time & pressure-altitude would continue to be recorded, but what good are those without position?

Nice arguments. Thanks. I'll be more attentive next time.
But in our case it is not playing any role.
Yes, Ciech's tracklog is full of "holes" except for the moment of crossing finish line (circle with 400 m radius?).
And: FS recognized Ciech's tracklog in right way - in full accordance with Gordon Rigg's words.
Question: what was happened among CE judges… or may be… among theirs computers?
Simple task: get tracklog by GPSdump from GPS and feed it to FSComp - it'll process tracklogs automatically.
I have got "ready to use" tracklogs, have recreated task9, clicked "check tracklogs", clicked "score task". That is all! There is not any magic! Last step: create html-report and publish it. I did it. It's easy like… but why CE judges did not managed to do such way.

If you want i'll give my FSDB-file and/or any usefull information for "how to recreate task9".

It's very unpleasant when fair sport fight loses sense due bad judgement.

It was a line apparently (see original article from Gordon). Also Gordon reports that Christian was second across the line. Now there is some question of which line we are talking about, but apparently the physical line is not the actual line.

(quoting entire message by Davis, right above)

You're right. I red Gordon's article and i saw video by Matjaz Klemencic. No doubts - that was a line.
Ok. Lets take a look for an intersection of tracklogs and finish line (part of circle). They cross the finish line inside 100 m segment of goal circle. It's quite straight line. So i think it is not a subject of discussion.

What i want to say.
From one side: some men/women in Ager (Spain) did thier work (judged a CE) and got results. Disputable results (according to Rigg's article).
From another side: one man (me) in Kiev (Ukraine) have checked that results. Just for interest. Results are differs from official but tells to us: Rigg is right.

We (me and CE officials) had the same source of data: same software, same bunch of tracklogs, same coordinates of turnpoints, same date-time - all the same. But results are not the same. It's strange.

The finish was a virtual goal line - if you used a cylinder you are looking at the track log about 400m from the critical point.
The goal line is defined as 400m either side of the GPS point.
Your task length error is probably from the cylinder radius compared to the line.
The positionof the line was supposed to be very accurately on the GPS point, and it was in about the same place as it was on a previous task when they had plenty of time to get it right - though due to the tail wind on this task the line was placed in a hurry as the gliders were already getting close. I don't think the line placement is significant, unless you can see Christian turning and setting up landing before the virtual line - which would explain everything.
So the kml does have time stamp data - that interesting.

The euros was a very well run competiton and Juaki did a tremendous job. Its really nice to see a meet director who knows his stuff and can make an objective decision about the conditions without being influenced by moody pilots, and the inevitable influeces from those who have something to gain from the existing results. Thie issue of christians placing on the last task is purely technical and is not a refelction on the spanish organisers. I saw christian and the scorer reviewing his track in the scoring room and the equipment there seemed to be confirming the published finish time to the suprise of both of them.
what to do when track logs fail to refelect reality is a subject for a cIVL technical commitee, so there is a pset precedure for the organiser to follow. In ager all the pilots were waiting for the result, as well as all the local spanish dignitaries, it was abut 1.00 am - so everyone was under a lot of pressure to get on with the closing ceremony.

We must set the goal cylinder radius to minimum on the 6030, or we lose the pointer info when we are 400m out from the true goal (unless we have the latest software, which also, it seems, gives us 4 seconds faster. who will check thart we don't get finish time "inflation" from instument manufacturers? Tactically we do not curt the start fine so I know which way I prefer the time error to go! Christian crossed the physical goal line very low and had to turn almost 180 to land into a fairly strong wind. However his feet were definitely on the ground before I crossed the line so I can't see how that could have made the error.

I see the instuments on longer and longer mounts projecting more and more forward, in a bid to grab the leading bonus. I'm working on a spring loaded balistic GPS mount that will fire my GPS over the goal from half way down the final glide before reeling it back in to the glider. The same reel will also dangle the GPS on a long line below me in the event of enforced altitude limits. who cares about reality eh? Its the GPS track that counts!

You are not stuck with four hundred meters, but can set your "goal cylinder" to twenty meters and above on the 6030.

I have the latest software and will therefore be very fast.

As I said:

We must set the goal cylinder radius to minimum on the 6030, or we lose the pointer info when we are 400m out from the true goal

So if its a gaol line we set that as a 20 m radius which is the minimum cylinder size.

The latest software, as opposed to mine, leaves the goal active after you cross the cylinder, while on mine all the nav fields go blank when I cross the cylinder.

Looks like we all need to test our main and backup instruments to see which records the most optimistic finish time anyway!


Going a bit off topic
The 6030 has quite a lot of unfortunate over simplifications in its navigation, which I might write something about. These become very important when we have a short final leg after a turnpoint before goal that is increasingly often put there to steer the final glide away from danger.
When you start the final glide before the last turnpoint, there can be a big discrepancy between the direction your arrow is pointing (as it always points to the centre of the cylinder), compared to the shortest route to goal which passes through a point on the edge of the cylinder. The arrow should point you down the shortest course route, constantly updated. Also the glide angle is worked out via the cylinder centre, not via the shortest route. So as you are going toward the final turnpoint it is using up to an extra 800m of distance - which is suddenly subtracted when you get the turnpoint - so a dodgy 12:1 can suddenly switch to below 10:1 with a short final leg. We saw this often in Ager.
…then we get the situation where they make the cylinder bigger for safety reasons if the turnpoint is badly placed for landings - making all these errors bigger.

I believe the digify (and the aircotec?), and perhaps other instruments, try to get these calculations more accurate (but most of these others are usuing the windmill ASI which is not at all good for so many reasons). Perhaps rather than a dumb garmin backup we are going to end up with a couple of different flight computers in our pods in future!