On Oct 26, 11:05*pm, JS wrote:
Tim's scenario still seems best to me. Look at your PDA's system date
and time.
* See if you can beat this: One of my 1993 flight logs out of Tonopah
had one data point in 1946. At least we could blame that on the space
aliens in nearby Area 51.
* (If the weather's anything like at the Club and Sports Nationals
last November, you're in for a good competition. I won't make it to
Lake Keepit in November, but rented the Duo in mid- January.)
Jim

On Oct 26, 6:21*pm, Bernie wrote:

Hey Jim,
not sure that I agree yet, wishing I had the file here at work to take
a look at now!
Coming to Keepit this year? We're there for the NSW State titles in a
month or so.
BB.



Nope Jim sorry. The issues really are separate from the PDA clock. e.g
the file name encoding just could not be driven by the PDA system
clock, it is driven by data inside the C302. You just cannot design a
system that creates different file names depending on what it is
downloaded to . What flight of the day each IGC file is is determined
from information inside the C302 - it has to be. And a file system
timestamps means nothing to an IGC file.

Bernie - The IGC file as emailed to me failed validation with the
official IGC valicam2.exe utility, but quite possibly that just
handling or email attachment problems. Can you run the valicam2.exe
utility on the files on your PC. If they fail try downloading the IGC
files again. You could also try downloading with ConnectMe and see
what happens then.

---

But I have a suspicion the file is might actually not be corrupted.
And if so, all that is going on is the IGC file simply has a large
jump in time in the B-record. This happens as the GPS acquires a 3D
fix and I am guessing the time up to that point has been driven by the
(confused) battery backed real time clock. Although how exact this is
implemented I am not sure. How long it takes to get the GPS time
depends on how many satellites are in view and is not really the same
as getting a geometry fix, but its likely in the hand full of minutes
for an old receiver like in the C302.

The file shows

Date header
HFDTE211010 == 21st October 2010 (date of first B record entry)

First B record

B1233283402657S15041334EV0005500000000000000128

ie. that is for 12:33:28 UTC (on 21st October 2010 from header
above) . You only have a 2D GPS fix (V letter code in B record).

Then you get a bit further down you get a time jump

B1235393402657S15041334EV0060200000000004000128 (i.e. 12:35:39 UTC)
B0204073404298S15039998EA0061800625000000030000 (i.e. 02:04:07 UTC in
what should be 3 seconds (the log rate) later)

Note the roll from 2D to 3D fix (V to A letter codes) coincident with
the time jump. The B-record jump cannot tell us how many days the date
has jumped, software will assume its jumped to the next 24 hour day.

I can imagine reasons to want the recorder to start even if it does
not have a valid 3D fix. And I could imagine that the assumption is
made that the real time clock is valid, but later if it gets bumped by
the GPS clock it does not matter as this happening in the file will be
obvious. Any IGC folks want to comment?

--

BTW SeeYou seems to ignore these before the time jump fixes and it
scores a sensible flight duration of 02:00:44. I've not messed around
trying to work out how it knows to do this (could be the 3D fix, could
be it detects the time jump and drops all earlier B-records). But it
shows the flight date as 21st October 2010 because that's the date in
the HFDTE header.

--

When was the C302 internal battery last replaced? I believe this
should be done each time you calibrate the device. If the battery is
OK (the C302 shows "Seal OK" and you don't get security fail errors on
download) then the real time clock should have been updated from the
last GPS data. The next time you power on the GPS see if it acquires a
fix faster, if its still very slow something may be wrong (check the
antenna). But if its what I suspect there is a good chance the problem
will just have gone away next time you fly. (Thanks to Tim Newport-
Peace who pointed out the existence of the real time clock in the C302
on r.a.s before.).


Darryl