missing gps fixes after upload

[charlie foxtrot]

After uploading my latest flight to the OLC, the server told me that
the file was invalid due to a large time gap between GPS fixes. Both
my secure *.cai and *.igc files show no such gap; it only appears on
the OLC trace. I've sent an e-mail to the OLC to see what they think,
but I'm curious to see if anybody else has had this problem, and what
they did to fix it. Thanks in advance!

Chris 'CF'
OLC-USA
2006-12-04
El Paso Soaring Society
Cambridge GPS-NAV Model 20
SeeYou v3.5a (Cambridge patch installed)
Previous flights uploaded successfully

[Mal]

There is a program that breaks down the fixes and times have you run the IGC
file through that.

[[email protected]]

How have you checked the IGC file for gaps? By loading it into SeeYou?
SeeYou will automatically skip over an out of order fix when
displaying a flight. My guess is if you checked the IGC file in detail
there is an out of order record.

A regular fix will look like this:
B1929283318443N11641991WA0121001246000000000000

A bad fix will probably look like this:
B1929323318500N11642046WV0121701255000000000000
Note the 'V' after the 'W' , instead of an 'A'.





charlie foxtrot wrote:
> After uploading my latest flight to the OLC, the server told me that
> the file was invalid due to a large time gap between GPS fixes. Both
> my secure *.cai and *.igc files show no such gap; it only appears on
> the OLC trace. I've sent an e-mail to the OLC to see what they think,
> but I'm curious to see if anybody else has had this problem, and what
> they did to fix it. Thanks in advance!
>
> Chris 'CF'
> OLC-USA
> 2006-12-04
> El Paso Soaring Society
> Cambridge GPS-NAV Model 20
> SeeYou v3.5a (Cambridge patch installed)
> Previous flights uploaded successfully

[Ian Strachan]

What sort of recorder (Manufacturer /exact model)?

Did the IGC file concerned pass the appropriate VALIDATION test program
(available free from the IGC GNSS web pages)?

Has the IGC file concerned been posted where others can have a look at
it?

Ian Strachan
Lasham Gliding Centre, UK

[Ian Strachan]

In my last posting, sorry, I missed that the recorder was a Cambridge
20 because you put this under your name rather than in the text.

The problems associated with the three legacy Cambridge models 10, 20
and 25 when used for OLC flights, have been extensively discussed on
this newsroup. In terms of using the free VALI-CAM.exe program, this
only works with the binary CAI file and not with the IGC file that is
derived from it. And if you alter the IGC file, the VALI program will
register it as invalid because it has been altered.

By all means email the files (CAI and IGC) to me and I will look at
them with analysis software that enables every fix to be looked at in
detail. Some analysis software uses its own algorithms, for instance
to average things out. This may mean that some anomalies in fixing are
not obvious. As someone else said, you can always look at the
B-records in the IGC file itself, but this is better done through
analysis software designed to intepret them individually.

Ian Strachan
Chairman IGC GFA Committee

[charlie foxtrot]

Hi All,

Yep, one of the b-records in my flight was corrupt, look at the log
time, shown with first 6 digits behind the B

in line 1 time is 21:12:32
in line 2 time is 22:36:00
in line 3 time is 21:12:40, look at the excerpt of Your IGC file below!

B2112323234199N10530479WA0334303580000022015000
B2236003402499N10530538WV0336003583000022015208
B2112403234260N10530608WA0338003602000020015000

The OLC did an administrative validation of my flight - THANK YOU OLC!

I received an e-mail suggesting to open the B-record in notepad, and
deleting the bogus line. Has anybody else tried this?

Chris 'CF'

[JS]

You may have entered a time warp.

Had a similar experience a decade ago with my first (8-channel) GPS-20.
Over the Diamond Range during a flight out of Tonopah, the audio
vario changed to a theme from The Rocky Horror Show, and the GPS logged
me being back in 1946. Since I was in the middle of the Great Basin, I
didn't notice any change in the scenery during those 4 seconds.
Others thought it something to do with Area 51.
Jim

[jcarlyle]

Tim, Ian,

Is the GPS data file sequence checking / analysis software you mention
in your separate posts available to us? If all FDRs screw up their data
files occasionally, it might be very useful to have such software more
generally available to soaring pilots.

-John


Tim Newport-Peace wrote:
> 'Out-if-Sequence' B-records are not exactly unknown. Some time ago a
> wrote a simple program to sequence check .IGC file and catch these.
> Cambridge is not the only manufacturer to suffer from this either.

Ian Strachan wrote:
> By all means email the files (CAI and IGC) to me and I will look at
> them with analysis software that enables every fix to be looked at in
> detail. Some analysis software uses its own algorithms, for instance
> to average things out. This may mean that some anomalies in fixing are
> not obvious. As someone else said, you can always look at the
> B-records in the IGC file itself, but this is better done through
> analysis software designed to intepret them individually.

[David Leonard]

charlie foxtrot wrote:
> Hi All,
>
> Yep, one of the b-records in my flight was corrupt, look at the log
> time, shown with first 6 digits behind the B
>
> in line 1 time is 21:12:32
> in line 2 time is 22:36:00
> in line 3 time is 21:12:40, look at the excerpt of Your IGC file below!
>
> B2112323234199N10530479WA0334303580000022015000
> B2236003402499N10530538WV0336003583000022015208
> B2112403234260N10530608WA0338003602000020015000
>
> The OLC did an administrative validation of my flight - THANK YOU OLC!
>
> I received an e-mail suggesting to open the B-record in notepad, and
> deleting the bogus line. Has anybody else tried this?
>
> Chris 'CF'
>
If you edit the B record, the OLC security check will indicate the file
was tampered with, which it was, and give you the dreaded red V. You're
not allowed to edit your flight logs. Thats the whole point of the
security check. The recorded position fix was "bad", but it was part of
the secure flight log in your *.cai file.

Your only option is to appeal to whoever is evaluating the log, the OLC
in this case, to ignore the obviously bad fix in the log.

-Dave
ZL

[Greg Arnold]

>> I received an e-mail suggesting to open the B-record in notepad, and
>> deleting the bogus line. Has anybody else tried this?
>>
>> Chris 'CF'
>>
> If you edit the B record, the OLC security check will indicate the file
> was tampered with, which it was, and give you the dreaded red V.

My experience is that this is not true. in the last 2 or 3 weeks I
erased a bogus line from a Cambridge 20 file, and it was then accepted
by the OLC with no red mark. Last year I did the same thing 2 or 3
times with no red mark, but maybe the security test was different then.


You're
> not allowed to edit your flight logs. Thats the whole point of the
> security check. The recorded position fix was "bad", but it was part of
> the secure flight log in your *.cai file.
>
> Your only option is to appeal to whoever is evaluating the log, the OLC
> in this case, to ignore the obviously bad fix in the log.
>
> -Dave
> ZL
>

[jcarlyle]

Thank you very much, Tim. I looked at one of my IGC files (created from
a CAI 25 cai file using the FAI DOS programs and the OLC cai2igc) and
found duplicate times. If you're interested, the file is here:
http://www2.onlinecontest.org/olcphp/2006/ausw_fluginfo.php?ref3=8027&ueb=N&olc=olc-usa&spr=en&dclp=8d5db9071d6ca1bff5b84aba86a1422c

I'll look at some other files this afternoon when I get back from
flying.

-John

[Greg Arnold]

>>
>>> If you are right, it would be possible to piggyback a genuine .CAI file
>>> onto a fudged .IGC file and show valid, forged flight with no Red Marks.
>> If indeed OLC is not checking the IGC file, it would seem the solution
>> would be for OLC to check the CAI file, then at the OLC do the
>> conversion to the IGC file.
>
> Concur.
>
> I cannot see why they are not doing that anyway.

This would have the side benefit of eliminating all the problems in the
last several months with the old Cambridge loggers -- the pilot would
just upload the CAI file, with the OLC doing everything else.

>
> Tim Newport-Peace
>
> "Indecision is the Key to Flexibility."

[Greg Arnold]

>> If indeed OLC is not checking the IGC file, it would seem the solution
>> would be for OLC to check the CAI file, then at the OLC do the
>> conversion to the IGC file.
>>
>
> They appear to be creating their own IGC file, and selectively checking
> parts of it against what the pilot submitted. They're trying to verify
> security in a file that has absolutely no security in it. This season,
> they started checking more records than before, and that's when the snafu
> with SeeYou popped up, since SeeYou was using a different way of doing
> the cai to igc conversion than they were. A rather strange way of handling
> the situation, if you ask me.

If that is what they really are doing, that is crazy. They create their
own IGC file from the CAI file, then check that against the IGC file
submitted by the pilot? Why not just use the IGC file they create?
Seems like they are complicating things just for the purpose of making
things more complicated.

[David Kinsell]

Greg Arnold wrote:
>
>>> If indeed OLC is not checking the IGC file, it would seem the
>>> solution would be for OLC to check the CAI file, then at the OLC do
>>> the conversion to the IGC file.
>>>
>>
>> They appear to be creating their own IGC file, and selectively checking
>> parts of it against what the pilot submitted. They're trying to verify
>> security in a file that has absolutely no security in it. This season,
>> they started checking more records than before, and that's when the snafu
>> with SeeYou popped up, since SeeYou was using a different way of doing
>> the cai to igc conversion than they were. A rather strange way of
>> handling
>> the situation, if you ask me.
>
> If that is what they really are doing, that is crazy. They create their
> own IGC file from the CAI file, then check that against the IGC file
> submitted by the pilot? Why not just use the IGC file they create?
> Seems like they are complicating things just for the purpose of making
> things more complicated.
>

True, it's hard to understand the logic in the bigger picture. But we've
had the same confusion in the US for many years. Flight claims for badges
and records with those models have always had the requirement that both
..igc and .cai files be submitted. If an NAC evaluator gets both files, the
only sensible thing to do is throw away the pseudo-igc file, validate the
..cai file, and create a new pseudo-igc file from the .cai file, using software
they trust. So why require both files be submitted? Makes no sense.

Neither Cambridge nor IGC were ever particularly candid in explaining
that the "igc" files from these models are quite bogus. That's got to
be a contributing factor in the ongoing confusion on the issue.

-Dave

[Papa3]

charlie foxtrot wrote:
> Hi All,
>
> Yep, one of the b-records in my flight was corrupt, look at the log
> time, shown with first 6 digits behind the B
>
> in line 1 time is 21:12:32
> in line 2 time is 22:36:00
> in line 3 time is 21:12:40, look at the excerpt of Your IGC file below!
>
> B2112323234199N10530479WA0334303580000022015000
> B2236003402499N10530538WV0336003583000022015208
> B2112403234260N10530608WA0338003602000020015000
>
> The OLC did an administrative validation of my flight - THANK YOU OLC!
>
> I received an e-mail suggesting to open the B-record in notepad, and
> deleting the bogus line. Has anybody else tried this?
>
> Chris 'CF'

Interesting. I've had 2 club members run into the same problem with
the OLC recently. Exact same scenario. Here are the relevant portions
of the latest file. Again, it's just one record out of order and,
interestingly enough, flagged as a "bad fix".

B 170222 4059430N 07500769W A 715 679
B 172206 5904629N 07500719W V 708 681
B 170230 4059510N 07500708W A 700 672

Even more intriguing, in all three files I've looked at, the longitude
and altitude portion of the fix suggests that the record is actually a
good fix but that the recording is what's screwed up (if you look these
values all fit "in sequence" just fine, but the time stamp and
lattitude are courrupted). I'm not familiar with the low-level coding
in this sort of firmware, but if I didn't know better I'd say there's a
very subtle bug in the logging module rather than a receiver problem.


BTW, I just import the file into Excel which provides a simple parser
at file open. Then, I have some macros to add values such as time
between fixes, instantaneous (fix to fix) rate of climb, and rolling
average rate of climb (last 6 fixes). Most of the problem show up
immediately with this approach.

P3