Cambridge, SeeYou, and OLC

[Ray Lovinggood]

A friend uses a Cambridge model 20 (or 25?) gps and
made two flights last Sunday. The first flight didn't
last long and he took a relight. When he used SeeYou
to submit the flight to OLC, it was rejected (I don't
know if SeeYou rejected it or OLC) because, according
to him, 'too much time between recording points.'

What's the procedure for submitting a flight from a
flight log that will have more than one flight? How
would you select the flight you want to be scored by
OLC?

Thanks for any help,

Ray Lovinggood
Carrboro, North Carolina, USA

[Mike]

Had the same thing happen-there was 'over 90 seconds between recording
points'.

In my case it was rejected by OLC and was due to GPS testing that also
effected other pilots, although not as badly.

Mike


Ray Lovinggood wrote:
> A friend uses a Cambridge model 20 (or 25?) gps and
> made two flights last Sunday. The first flight didn't
> last long and he took a relight. When he used SeeYou
> to submit the flight to OLC, it was rejected (I don't
> know if SeeYou rejected it or OLC) because, according
> to him, 'too much time between recording points.'
>
> What's the procedure for submitting a flight from a
> flight log that will have more than one flight? How
> would you select the flight you want to be scored by
> OLC?
>
> Thanks for any help,
>
> Ray Lovinggood
> Carrboro, North Carolina, USA

[5Z]

In SeeYou set 1st marker near the takeoff and the 2nd marker near the
landing of one of the flights. Then optimize and submit. I've done
this in the motorglider if I have to start the engine and each half of
the flight is worthy of a claim.

-Tom

[Kilo Charlie]

I've had this same problem occur when I started the logger too early and due
to some antenna interference prior to launch it had a gap. It is easily
changed by opening the flight log with Notepad or a similar program and
deleting the points prior to takeoff. If it occured in flight it may not be
possible to correct it however.

Casey Lenox
KC
Phoenix

[Ray Lovinggood]

Tom,

My friend said your method works for him. Thanks!

Ray Lovinggood
Carrboro, North Carolina, USA

At 01:12 30 July 2005, 5z wrote:
>In SeeYou set 1st marker near the takeoff and the 2nd
>marker near the
>landing of one of the flights. Then optimize and submit.
> I've done
>this in the motorglider if I have to start the engine
>and each half of
>the flight is worthy of a claim.
>
>-Tom
>
>

[Ray Lovinggood]

Tom,

My friend said your method works for him. Thanks!

Ray Lovinggood
Carrboro, North Carolina, USA

At 01:12 30 July 2005, 5z wrote:
>In SeeYou set 1st marker near the takeoff and the 2nd
>marker near the
>landing of one of the flights. Then optimize and submit.
> I've done
>this in the motorglider if I have to start the engine
>and each half of
>the flight is worthy of a claim.
>
>-Tom
>
>

[Ian Strachan]

Any alteration of a IGC flight data file with a text editor will cause
it to fail the (free) IGC Validation program that checks the file for a
number of things. An altered file will not be valid for any activity
that requires IGC-standards of flight data. This includes badge and
record flights, and competitions that use the IGC Validation check.

The alteration even of only one character in the flight data will cause
the Validation check to fail.

In terms of fix intervals, the Sporting Code makes the point that it is
the SETTING that the pilot that uses that matters. What happens in
flight may differ, particularly in conditions of poor GPS reception.
Short losses of GPS fixing should not invalidate a flight as long as it
is obvious that there was not time to carry out an intermediate landing
and re-launch. However, loss of fixes in an Observation Zone cannot be
remedied as there will be no evidence of reaching the point concerned.

Continuity of the flight record should be shown by a continuous
pressure altitude trace and, for motor gliders, a continuous engine
noise trace (even though no GPS fixes are being recorded, or, as often
happens, GPS altitude recording is lost for a time)

There is a significant difference between the pilot setting of fix
interval, and small variations that occur in the air due to adverse GPS
reception for short periods. Of course pilots should do everything
possible to ensure best antenna position, no kinks or breaks in the
antenna cable, adequate battery power to the GPS, and so forth. But
they should not be penalised by things out of there control when it is
perfectly obvious that no intermediate landing has occurred. IMHO, of
course!

[David Kinsell]

Ian Strachan wrote:
> Any alteration of a IGC flight data file with a text editor will cause
> it to fail the (free) IGC Validation program that checks the file for a
> number of things. An altered file will not be valid for any activity
> that requires IGC-standards of flight data. This includes badge and
> record flights, and competitions that use the IGC Validation check.
>
> The alteration even of only one character in the flight data will cause
> the Validation check to fail.

Tried to respond to this before, apparently didn't make it out.

The Cambridge models 10, 20, and 25 have no capability of producing
a valid IGC file, and no validation programs exist for them. You
can alter one of those (pseudo-)IGC files all you want, it won't
be detected. Even if you don't own one of these things, you could
fabricate a flight trace, label it as coming from one of them, and
make it look authentic. Kinda kills the idea of IGC being a universal,
secure format, doesn't it?

-Dave




>
> In terms of fix intervals, the Sporting Code makes the point that it is
> the SETTING that the pilot that uses that matters. What happens in
> flight may differ, particularly in conditions of poor GPS reception.
> Short losses of GPS fixing should not invalidate a flight as long as it
> is obvious that there was not time to carry out an intermediate landing
> and re-launch. However, loss of fixes in an Observation Zone cannot be
> remedied as there will be no evidence of reaching the point concerned.
>
> Continuity of the flight record should be shown by a continuous
> pressure altitude trace and, for motor gliders, a continuous engine
> noise trace (even though no GPS fixes are being recorded, or, as often
> happens, GPS altitude recording is lost for a time)
>
> There is a significant difference between the pilot setting of fix
> interval, and small variations that occur in the air due to adverse GPS
> reception for short periods. Of course pilots should do everything
> possible to ensure best antenna position, no kinks or breaks in the
> antenna cable, adequate battery power to the GPS, and so forth. But
> they should not be penalised by things out of there control when it is
> perfectly obvious that no intermediate landing has occurred. IMHO, of
> course!
>

[Jack]

David Kinsell wrote:

> The Cambridge models 10, 20, and 25 have no capability of producing
> a valid IGC file....

> Kinda kills the idea of IGC being a universal,
> secure format, doesn't it?

You lost me there, DK.

If these Cambridge files are not valid IGC files, how is their lack of
security and universality of any relevance to the discussion of (valid) IGC
files' security and universality?


Jack

[Eric Greenwell]

David Kinsell wrote:
> Ian Strachan wrote:

>> The alteration even of only one character in the flight data will cause
>> the Validation check to fail.
>
>
> Tried to respond to this before, apparently didn't make it out.
>
> The Cambridge models 10, 20, and 25 have no capability of producing
> a valid IGC file, and no validation programs exist for them. You
> can alter one of those (pseudo-)IGC files all you want, it won't
> be detected. Even if you don't own one of these things, you could
> fabricate a flight trace, label it as coming from one of them, and
> make it look authentic.

Since we know those recorders don't produce IGC files, won't we
immediately realize they aren't authentic IGC files, but only "IGC
format files"? For example, the OLC uses "IGC format files" from
Cambridge recorders for their purposes, but only after verifying the
security of the recorder's file in proprietary Cambridge format.

Kinda kills the idea of IGC being a universal,
> secure format, doesn't it?

I don't think so. The fake files are easily determined to be fake simply
by looking at the file (no fancy verification program needed), so what's
the problem?


--
Change "netto" to "net" to email me directly

Eric Greenwell
Washington State
USA