missing gps fixes after upload

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 he
http://www2.onlinecontest.org/olcphp...b84aba86a1422c

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

-John

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."

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.

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

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