CAI 302 date problem

I flew yesterday (26 October) and had two hours, later I used the
Cambridge utility on my PDA to download the flight log from the
Cambridge 302.

First thing I noticed was that the utility said the flight was 111
hours long, and that the date of the flight was 21 October.

I later checked the log file in See You and it thinks it was 21 Oct.
also.

I then noticed that I had not reset the date in my PDA after replacing
the battery a few weeks back, it thought it was 2002.

However I can't see how the date in the secure .igc file could or
should be affected by that.

The only other thing I can think is that when I last flew (17th Oct ),
I flipped the master switch off rather than doing an orderly shutdown
on the 302.

Any ideas?

On Oct 26, 4:08*pm, Bernie wrote:
I flew yesterday (26 October) and had two hours, later I used the
Cambridge utility on my *PDA to download the flight log from the
Cambridge 302.

First thing I noticed was that the utility said the flight was 111
hours long, and that the date of the flight was 21 October.

I later checked the log file in See You and it thinks it was 21 Oct.
also.

I then noticed that I had not reset the date in my PDA after replacing
the battery a few weeks back, it thought it was 2002.

However I can't see how the date in the secure .igc file could or
should be affected by that.

The only other thing I can think is that when I last flew (17th Oct ),
I flipped the master switch off rather than doing an orderly shutdown
on the 302.

Any ideas?

Is the C302 internal battery OK? Does the data in the file look OK
when you look at the flight in SeeYou? Did the Cambridge utility
complain about any security failures? I'm curious and will look at
the file - if you want to attach the file to an email and send to me
(or try posting it on OLC).


Darryl

Thanks Darryl,
I will post the file on the OLC when I get home from work this
afternoon, and email it to you.

The file looks complete in See You. The CAI utility did not complain
about it's integrity.

We also wondered about the internal battery in the 302, but after
checking the manual I
cannot even find any suggestion that one exists. I know that the
earlier Cambridge models
had them. The manual states " Flash memory is used for firmware as
well as flight logs. "

Regards, Bernie.

On Oct 26, 5:08*pm, Bernie wrote:
I flew yesterday (26 October) and had two hours, later I used the
Cambridge utility on my *PDA to download the flight log from the
Cambridge 302.

First thing I noticed was that the utility said the flight was 111
hours long, and that the date of the flight was 21 October.

I later checked the log file in See You and it thinks it was 21 Oct.
also.

I then noticed that I had not reset the date in my PDA after replacing
the battery a few weeks back, it thought it was 2002.

However I can't see how the date in the secure .igc file could or
should be affected by that.

The only other thing I can think is that when I last flew (17th Oct ),
I flipped the master switch off rather than doing an orderly shutdown
on the 302.

Any ideas?

First is the name of the file correct? Not the date but the actual
name of the file, should be a 0AQxxxx file name. If that is correct
the 302 is fine and it is the date on the PDA that is the problem.
The PDA will store the file under the current date it thinks it is.
If the file name is different then it is likely a 302 problem.

Thanks Tim.
I will check the file name tonight when I get home. (I'm in Australia,
we are working right now!)

I would have thought that the date in an .igc file would have been
derived from the GPS satellite data.

Certainly, when I copied the file from the PDA to my PC, it was
timestamped 2002, as per the PDA.
If the .igc file also said 2002, I would tend to agree with you. But
just 4 days earlier?

Regards, Bernie.

Mr. Baer, from 13,000km away I believe Mr. Taylor has the answer.
Jim

On Oct 26, 5:57*pm, JS wrote:
Mr. Baer, from 13,000km away I believe Mr. Taylor has the answer.
Jim

Ah? SeeYou and any other sane software will derive the date/duration
of the file from the IGC file HFDTE record and B record timestamps and
does not care what a file is named. And no software will care about
the filesystem time stamp on a file. What is going on should be
obvious within the IGC file.

If the download utility did not complain about security fail then the
battery backup should be fine.

Darryl

On Oct 27, 12:07*pm, Darryl Ramm wrote:
On Oct 26, 5:57*pm, JS wrote:

Mr. Baer, from 13,000km away I believe Mr. Taylor has the answer.
Jim


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.

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

Thank you for your assistance and analysis Darryl.

I ran the valicam2 utility against the igc file and it checks OK:
Log Data Integrity OK
Signature Data Integrity OK
Security OK

The internal battery has never been replaced, as the unit is just over
two years old (Last calibrated 9/5/08 at the factory)
The C302 showed 'Seal OK' when I turned it on, pretty sure of that,
but will check again next time.

I'll check the antenna connection before powering on next time, and
hope that you are correct and this was a on-off error.

Regards, Bernie