302 security failures

On Apr 5, 11:28*am, Darryl Ramm wrote:
On Apr 5, 7:03*am, T8 wrote:

Anyone else got one, lately?

And yes, I do have the flash memory upgrade. *Have flown the ship
about a hundred hours since the upgrade, this is the first such
problem (yesterday). *Didn't think to check to see if the memory just
'rolled over', but it is probably close, IIRC 302 holds right around a
hundred hours of flight logs at 4sec interval.

-T8

Could you clarify this is the security fail on download with a
Cambridge PDA utility software where the hardware/battery seal is
known to be good but the IGC file is invalid. Have you tried a non-
Cambridge utility like ConnectMe, that has never helped me when this
has happened but some people believe it helps with this sometimes.

I have ran my 302 at 1 sec sample rate since getting one of the early
flash memory upgrades, easilly enough to wrap memory, but I dont'
think that proves anything. I had only one bad download/security fail
in past use of that 302.

Darryl

More data:

302 has good seal as displayed on Screen # 8 (or there about) --
verified this after the failed d/l.

Flight logs are being transferred by Cambridge utility to a SD card on
an Ipaq 3970. The Cambridge utility reports three things at the end
of the download -- paraphrasing: "Flight log integrity Okay /
Signature Okay / Security Fail". I've 'verified' the downloaded igc
file with valicam2 and get the same three messages on yesterday's
file.

I've never used another utility to transfer logs -- the CAI utility
works fine.

-Evan Ludeman / T8

On Apr 5, 9:02*am, T8 wrote:

Next time you go to the glider try to download the same log. If it
fails make another flight, then try to download that new log, and the
one that failed previously. If either fails please try a different
download utility. Let us know what happens please.

I think, from my own experience, it is possible for the security fail
to go away without anything being done to the 302.

I never clear my 302 and record all flights at 2 second interval.
Memory was probably cleared when sent in for calibration and service
but the last time that happened was 2005. I have experienced about
2 security fails in over 700 hours logged at 2 sec and I don't think
any in the last 185 hours.

Looking back at my notes, I had a suspicion that the security fail
problem was related to the download utility being used, and that using
a different utility didn't show the problem. That was based on a
postdownload review of saved flight logs and their securty as reported
by Cambridge Aero Explore Plus. I must have lost interest though,
since I didn't come to any firm conclusion about that.

Andy (GY)

Looking back at my notes, I had a suspicion that the security fail
problem was related to the download utility being used, and that using
a different utility didn't show the problem. *That was based on a
postdownload review of saved flight logs and their security as reported
by Cambridge Aero Explore Plus. *


I just checked those logs. It turns out they were different flights
on the day day. I took a relight. The log files are 5A9C3GP1.IGC and
5A9C3GP2.IGC. The first fails security check and the second passes
security check when validated with Aero Explorer Plus. There was about
35 minutes between the first landing and the second takeoff and I did
nothing to the 302. A log for a flight 7 days earlier also reports
good security.

I don't remember now if the download utility failed them both, or just
the first one, but I removed the 302 and took it in to Cambridge as I
was on business in Memphis soon after seeing the problem.

This supports the idea that the 302 will heal itself, but not the idea
that the downloader utility type had a role.

Andy (GY)

Has anyone tried sending their failed logs to R-Track? I would think
they might be able to pinpoint the glitch in the checksum calculation.
There's probably an errant byte somewhere, maybe due to the memory
wrap-around, maybe not.