302 security failures

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.