![]() |
If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
![]()
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 ![]() HFGTYGLIDERTYPE ![]() 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 |
#2
|
|||
|
|||
![]()
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 |
#3
|
|||
|
|||
![]()
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 ;-) |
#4
|
|||
|
|||
![]()
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 he http://www.cumulus-soaring.com/cai_d...g_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 |
#5
|
|||
|
|||
![]()
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 hehttp://www.cumulus-soaring.com/cai_d...aining_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 |
#6
|
|||
|
|||
![]()
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. |
#7
|
|||
|
|||
![]()
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 hehttp://www.cumulus-soaring.com/cai_d...aining_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. |
#8
|
|||
|
|||
![]()
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 |
#9
|
|||
|
|||
![]()
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 hehttp://www.cumulus-soaring.com/cai_d...aining_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 |
#10
|
|||
|
|||
![]()
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 hehttp://www.cumulus-soaring.com/cai_d...aining_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. |
|
Thread Tools | |
Display Modes | |
|
|
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
Cambridge Model 20 Flight Recorder WANTED | N6TU | Soaring | 1 | May 28th 08 07:14 PM |
FSDO enforcement- GPS before effective date - which date to put in Aircraft Log for Part 43? | Ron A. | Instrument Flight Rules | 18 | March 15th 06 02:30 PM |
Date of effect now 1 October 2004 for revised IGC-approvals for certain legacy types of GNSS flight recorder | Ian Strachan | Soaring | 0 | March 15th 04 02:32 PM |
Date of effect now 1 April 2004 for revised IGC-approval for certain legacy types of GNSS flight recorder | Ian Strachan | Soaring | 56 | December 2nd 03 08:08 AM |
Cambridge 302 problem: "Could not get FAT.(A)" while trying to download flight logs | Jason Armistead | Soaring | 5 | July 13th 03 02:36 PM |