Cambridge 302 Flight Log Date Error?

[Paul Remde]

Hi,



I'm bringing this topic to this forum because it appears to be a unique and
strange issue that doesn't make any sense to me. I'm a big fan of the
Cambridge 302 and yet I can't explain this issue.



Below is the header from a flight log from a Cambridge 302 (or 302A). The
customer is certain that he flew on Saturday, July 12th and yet the 302
flight log shows the date as July 8th. SeeYou therefore displays the date
as July 8th. The filename (87C....) shows that the date was 8 (2008), 7
(July), C (the 12th) - which matches the date the customer says he flew the
glider. Yet the date in the IGC file itself shows July 8th. He did not
fly the glider on July 8th. This is very strange. The flight log passes
security checks. The customer downloaded the flight several times with the
same result. I am quite certain that the recorded date comes from the GPS,
not the PDA that was used for the download.



I'm baffled. Have any of you ever seen this before? Do you have any
suggestions? I don't think this flight was a badge or record, but it would
be a shame to have the problem affect an important flight in the future.



Thanks,



Paul Remde
Cumulus Soaring, Inc.



ACAM3AZ

HFDTE080708

HFFXA050

HFPLTPILOT:Dave Piotrowski

HFGTYGLIDERTYPE:DG808

HFGIDGLIDERID:808JC

HFDTM100GPSDATUM:

HFRFWFIRMWAREVERSION:F2.0

HFRHWHARDWAREVERSION:300 Series Version 2

HFFTYFRTYPE:CAMBRIDGE AERO INSTRUMENTS, 302+

HFGPS:GARMIN,LVS-25,12,18000

HFPRSPRESSALTSENSOR:INTERSEMA, MS5534-AP, 20000

I033638FXA3941ENL4247REX

LCAMSBVER:5FWVER:F20001

C150302175427150302000103

C0000000N00000000WTAKEOFF

C2820939N08150150WStart B 28

C2910729N08213384WOcala 15

C2848250N08156510WFlyingBaron8

C2803511N08145473WWinterHavn23

C2824427N08150271WFINISH 26

C0000000N00000000WLANDING

B0210033709213N10745337WV0194700000000000000128

[BB]

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

[Todd]

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 ;-)

[Paul Remde]

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.

I'll be documenting the bug and the work-around in my next Cumulus Soaring,
Inc. newsletter. Basically, as long as you clear the memory every now and
then (once per season would be enough for most glider pilots) there is no
way the bug can bite you. The procedure for clearing the 302's memory is
documented here:
http://www.cumulus-soaring.com/cai_downloads.htm#302_Training_Presentation

A friend here in MN recently had a flight log failure that cost him a state
record. He had the logger set to log every second - which made the
potential for the problem 4 times worse that it would be with a 4 second
logging interval. I have since set the interval to 4 seconds and cleared
the memory in his logger (with his permission of course). When the logging
interval is set to 4 seconds the logger has enough memory for 100 hours.

Good Soaring,

Paul Remde
Cumulus Soaring, Inc.
http://www.cumulus-soaring.com

"BB" > wrote in message
...
>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

[Uncle Fuzzy]

On Jul 17, 9:53*pm, "Paul Remde" > 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.
>
> I'll be documenting the bug and the work-around in my next Cumulus Soaring,
> Inc. newsletter. *Basically, as long as you clear the memory every now and
> then (once per season would be enough for most glider pilots) there is no
> way the bug can bite you. *The procedure for clearing the 302's memory is
> documented here:http://www.cumulus-soaring.com/cai_downloads.htm#302_Training_Present...
>
> A friend here in MN recently had a flight log failure that cost him a state
> record. *He had the logger set to log every second - which made the
> potential for the problem 4 times worse that it would be with a 4 second
> logging interval. *I have since set the interval to 4 seconds and cleared
> the memory in his logger (with his permission of course). *When the logging
> interval is set to 4 seconds the logger has enough memory for 100 hours.
>
> Good Soaring,
>
> Paul Remde
> Cumulus Soaring, Inc.http://www.cumulus-soaring.com
>
> "BB" > wrote in message
>
> ...
>
>
>
> >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- Hide quoted text -
>
> - Show quoted text -

Whoa! Is this going to be one of those things I never hear about
(well, I guess not in this case) until something bad happens to me?
Then all I hear is "EVERYBODY knows that ......"
My 302A is set to 4 seconds, but I've flown it enough that it has
overwritten the first couple months of 2007 flights. They still show
up when you use the Cambridge utility to transfer files, but they fail
the transfer. To date, I've never had a problem with a file.
Is there risk involved in clearing the memory using the utility Paul
linked to? Call me paranoid, but I've even gone to the extreme of
cutting the TX line from my iPAQ to the 302A to avoid any possibility
of hosing up a flight record. (I had two files strangely segmented
prior to cutting the line.)
TIA

[[email protected]]

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" > 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.
>

[Paul Remde]

Hi,

Please see my notes below. ***

Thanks,

Paul Remde

"Uncle Fuzzy" > wrote in message
...
On Jul 17, 9:53 pm, "Paul Remde" > 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.
>
> I'll be documenting the bug and the work-around in my next Cumulus
> Soaring,
> Inc. newsletter. Basically, as long as you clear the memory every now and
> then (once per season would be enough for most glider pilots) there is no
> way the bug can bite you. The procedure for clearing the 302's memory is
> documented
> here:http://www.cumulus-soaring.com/cai_downloads.htm#302_Training_Present...
>
> A friend here in MN recently had a flight log failure that cost him a
> state
> record. He had the logger set to log every second - which made the
> potential for the problem 4 times worse that it would be with a 4 second
> logging interval. I have since set the interval to 4 seconds and cleared
> the memory in his logger (with his permission of course). When the logging
> interval is set to 4 seconds the logger has enough memory for 100 hours.
>
> Good Soaring,
>
> Paul Remde
> Cumulus Soaring, Inc.http://www.cumulus-soaring.com
>
> "BB" > wrote in message
>
> ...
>
>
>
> >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- Hide quoted text -
>
> - Show quoted text -

Whoa! Is this going to be one of those things I never hear about
(well, I guess not in this case) until something bad happens to me?
Then all I hear is "EVERYBODY knows that ......"
My 302A is set to 4 seconds, but I've flown it enough that it has
overwritten the first couple months of 2007 flights. They still show
up when you use the Cambridge utility to transfer files, but they fail
the transfer. To date, I've never had a problem with a file.
Is there risk involved in clearing the memory using the utility Paul
linked to? Call me paranoid, but I've even gone to the extreme of
cutting the TX line from my iPAQ to the 302A to avoid any possibility
of hosing up a flight record. (I had two files strangely segmented
prior to cutting the line.)
TIA

*** I'm sorry to tell you this, but you must have missed when you cut the
PDA transmit line because it would not be possible for the PDA to request
the download from the 302A if the transmit line was not working.
*** Theoretically, the bug should only affect the one file that bridges the
gap when the memory wraps. In my friend's logger files before and after the
bad flight log pass security checks fine.
*** I highly recommend clearing the memory every spring.

[BB]

Thanks once again Paul!

Why am I so paranoid? The rules have changed this year,

6.7.4.4 ‡ Flight Recorder category requirements
....
6.7.4.4.3 ‡ To be valid, a flight log must pass applicable security
checks

A6.7.4.4 ....For National contests the security checks must be valid.
Logs produced by IGC sanctioned units with
security seal failures are not accepted.

Of course, I get my first security fail two weeks before the
Nationals.

Before, nobody worried about security seal errors. Now we have to.
Replace those backup batteries!

John Cochrane

[Uncle Fuzzy]

On Jul 18, 5:17*am, "Paul Remde" > wrote:
> Hi,
>
> Please see my notes below. ***
>
> Thanks,
>
> Paul Remde
>
> "Uncle Fuzzy" > wrote in message
>
> ...
> On Jul 17, 9:53 pm, "Paul Remde" > 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.
>
> > I'll be documenting the bug and the work-around in my next Cumulus
> > Soaring,
> > Inc. newsletter. Basically, as long as you clear the memory every now and
> > then (once per season would be enough for most glider pilots) there is no
> > way the bug can bite you. The procedure for clearing the 302's memory is
> > documented
> > here:http://www.cumulus-soaring.com/cai_downloads.htm#302_Training_Present...
>
> > A friend here in MN recently had a flight log failure that cost him a
> > state
> > record. He had the logger set to log every second - which made the
> > potential for the problem 4 times worse that it would be with a 4 second
> > logging interval. I have since set the interval to 4 seconds and cleared
> > the memory in his logger (with his permission of course). When the logging
> > interval is set to 4 seconds the logger has enough memory for 100 hours..
>
> > Good Soaring,
>
> > Paul Remde
> > Cumulus Soaring, Inc.http://www.cumulus-soaring.com
>
> > "BB" > wrote in message
>
> ....
>
> > >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- Hide quoted text -
>
> > - Show quoted text -
>
> Whoa! *Is this going to be one of those things I never hear about
> (well, I guess not in this case) until something bad happens to me?
> Then all I hear is "EVERYBODY knows that ......"
> * My 302A is set to 4 seconds, but I've flown it enough that it has
> overwritten the first couple months of 2007 flights. *They still show
> up when you use the Cambridge utility to transfer files, but they fail
> the transfer. *To date, I've never had a problem with a file.
> * Is there risk involved in clearing the memory using the utility Paul
> linked to? *Call me paranoid, but I've even gone to the extreme of
> cutting the TX line from my iPAQ to the 302A to avoid any possibility
> of hosing up a flight record. (I had two files strangely segmented
> prior to cutting the line.)
> TIA
>
> *** I'm sorry to tell you this, but you must have missed when you cut the
> PDA transmit line because it would not be possible for the PDA to request
> the download from the 302A if the transmit line was not working.
> *** Theoretically, the bug should only affect the one file that bridges the
> gap when the memory wraps. *In my friend's logger files before and after the
> bad flight log pass security checks fine.
> *** I highly recommend clearing the memory every spring.- Hide quoted text -
>
> - Show quoted text -

Nope. I don't use the iPAQ

[Uncle Fuzzy]

On Jul 18, 5:17*am, "Paul Remde" > wrote:
> Hi,
>
> Please see my notes below. ***
>
> Thanks,
>
> Paul Remde
>
> "Uncle Fuzzy" > wrote in message
>
> ...
> On Jul 17, 9:53 pm, "Paul Remde" > 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.
>
> > I'll be documenting the bug and the work-around in my next Cumulus
> > Soaring,
> > Inc. newsletter. Basically, as long as you clear the memory every now and
> > then (once per season would be enough for most glider pilots) there is no
> > way the bug can bite you. The procedure for clearing the 302's memory is
> > documented
> > here:http://www.cumulus-soaring.com/cai_downloads.htm#302_Training_Present...
>
> > A friend here in MN recently had a flight log failure that cost him a
> > state
> > record. He had the logger set to log every second - which made the
> > potential for the problem 4 times worse that it would be with a 4 second
> > logging interval. I have since set the interval to 4 seconds and cleared
> > the memory in his logger (with his permission of course). When the logging
> > interval is set to 4 seconds the logger has enough memory for 100 hours..
>
> > Good Soaring,
>
> > Paul Remde
> > Cumulus Soaring, Inc.http://www.cumulus-soaring.com
>
> > "BB" > wrote in message
>
> ....
>
> > >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- Hide quoted text -
>
> > - Show quoted text -
>
> Whoa! *Is this going to be one of those things I never hear about
> (well, I guess not in this case) until something bad happens to me?
> Then all I hear is "EVERYBODY knows that ......"
> * My 302A is set to 4 seconds, but I've flown it enough that it has
> overwritten the first couple months of 2007 flights. *They still show
> up when you use the Cambridge utility to transfer files, but they fail
> the transfer. *To date, I've never had a problem with a file.
> * Is there risk involved in clearing the memory using the utility Paul
> linked to? *Call me paranoid, but I've even gone to the extreme of
> cutting the TX line from my iPAQ to the 302A to avoid any possibility
> of hosing up a flight record. (I had two files strangely segmented
> prior to cutting the line.)
> TIA
>
> *** I'm sorry to tell you this, but you must have missed when you cut the
> PDA transmit line because it would not be possible for the PDA to request
> the download from the 302A if the transmit line was not working.
> *** Theoretically, the bug should only affect the one file that bridges the
> gap when the memory wraps. *In my friend's logger files before and after the
> bad flight log pass security checks fine.
> *** I highly recommend clearing the memory every spring.- Hide quoted text -
>
> - Show quoted text -

Hmm. Last post went out incomplete. I carry the iPAQ as a receiver
only, to run XCSoar. I do all my downloading and configuring of the
302A with a standard serial cable and a laptop. I'll include the
memory clearing in my January routine from now on! Thanks.

[5Z]

On Jul 18, 8:05*am, BB > wrote:
> 6.7.4.4.3 ‡ To be valid, a flight log must pass applicable security
> checks
>
> A6.7.4.4 ....For National contests the security checks must be valid.
> Logs produced by IGC sanctioned units with
> security seal failures are not accepted.

OK, but what if the previous and subsequent files are OK? I would
thing the contest committee could be convinced that there was no
tampering, especially if this is a "known" problem. Let's not talk
here about badges and records, just contests...

A couple years ago at a contest I also had a flight fail security.
All prior and subsequent flights have been OK. CAI could not find
anything wrong with the 302.

I fly with a 2 second logging interval, anything longer makes analysis
and replay not nearly as much fun or useful. I have never cleared my
302 memory and I've flown well over 200 hours since that one and only
incident.

-Tom

[Andy[_1_]]

On Jul 18, 7:05*am, BB > 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

[Andy[_1_]]

On Jul 18, 9:23*am, Andy > 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