Cambridge 302 Flight Log Date Error?

I flew on July 13 producing a normal header
ACAM3H9
HFDTE130708
HFFXA050
HFPLTPILOT: John H. Cochrane
HFGTYGLIDERTYPE:ASW-27B
HFGIDGLIDERID:BB
HFDTM100GPSDATUM:

However, on July 5, I got the dreaded "security fail" -- even though
the security seal (screen 9) shows "good". Yes, rebooted everything,
downloaded over and over again with the cambridge program, tried again
next week -- all to no avail. The 13th downloads normally. If this is
a related bug or others are experiencing the same thng I'd like to
know, especially with nationals only 2 weeks away.

John Cochrane

Per the IGC GNSS specs

2.5.4. Date of flight - the date used in the file name and in the H-
record (DTE code) is the UTC date of the
first valid fix in the flight log transferred after flight. That is,
the date applicable to the time in the first line
in the B (fix) record, not the date at the time of switching on, or of
take-off. This is particularly important
for recorders operated in time zones where they are switched on close
to midnight UTC. (AL6)

Therefore, one would conclude that there must be some fix form the 8th
on the log. But, interestingly the "B" records (flight gps fix points)
only have UTC Time in them.

So the question would be: Did you power up your 302 on the 8th?
(maybe, just to do a new flight declaration)

Also, is there a big gap in the first few "B" record times? (i.e. a
few points from the 8th followed by times from the 12th)

"B" record format (in part)
B H H M M S S D D M MM MM N D D D M MM MM E V P P P P P G G G G G CR
LF
Time UTC 6 bytes HHMMSS
Latitude 8 bytes DDMMmmmN/S
Longitude 9 bytes DDDMMmmmE/W

Or, for you conspiracy theorists: This is a result of some secret
military test on the GPS system meant to test for gaps in the space
time continuum ;-)

I purchased my 302 in 2002 and have had very little trouble with it.
However since starting to post to the OLC I have had two files (71B
and 81A) which would not verify. Gary Kammerer at Cambridge told me
that somewhere in the firmware there is a bug that causes this problem
periodically and they are unable to find it. He told me that he
"believed" that Phil Schlosser was working on it. I tried to contact
Phil since I have worked with him before on other problems but I got
no reply. Then I read that he was working with Kellerman's group.

Gary told me that he does not think the problem has anything to do
with memory wrap.

If you're attempting an important badge or record carry a backup for
your 302.


On Jul 18, 12:53 am, "Paul Remde" <p...@remde.us> wrote:
> Hi John,
>
> There is a strong theory that when a single flight log fails, the cause is a
> bug in the 302 when the memory gets full and wraps.  I am trying to get
> Cambridge to fix it.  I hope they will.
>

On Jul 18, 7:05 am, BB <john.cochr...@gsb.uchicago.edu> wrote:
> Why am I so paranoid?

No you are not paranoid John, just justifiably concerned. I have
twice had the security fail issue with my 302. The first time I sent
it back to Cambridge, the second time I just waited for the problem to
go away. I still don't understand it and I know it will bite me
again.

So far the security issue hasn't cost me a flight but if I ever get
back to Nationals flying I suppose it could. I did lose a Regional
day though due to a utility date math error that prevent the log from
being downloaded.

There is a lot to be said for dissimilar redundancy.


Andy

On Jul 18, 9:23 am, Andy <a.dur...@netzero.net> wrote:
>  The first time I sent it back to Cambridge, the second time I just waited for the problem to go away.  

That probably wasn't very clear. My recollection is that the problem
is only seen on some, perhaps one, log. Later logs will have good
security even if no corrective action is taken. I have never erased
my 302. I record at 2 second period and have recorded over 500 hours
of flights. I think I have seen the security issue twice.


Andy