Cambridge 302 and GPS-NAV owners – IMPORTANT NEWS

I wonder if the affected FR manufacturers could add a mod to detect a timestamp prior to "now" and munge it to the current epoch?

Would FAI accept this solution?

-Tom

On Wednesday, December 3, 2014 10:55:08 PM UTC-8, David Kinsell wrote:
Newer systems use a 13 bit integer instead of 10 to keep track of the
week, doubt there's any chance that would ever be retrofit into the units.

On Thu, 04 Dec 2014 18:08:27 -0800, tom wrote:

I wonder if the affected FR manufacturers could add a mod to detect a
timestamp prior to "now" and munge it to the current epoch?

Interesting idea, but quite hypothetical when it comes to Cambridge.

Garrecht Avioncs seems to have source code for the GPS module, and
intends to provide a fix in that code for their Volksloggers. It should
be straightforward to add another 20 years of life that way.

As the details of the problem have come out, it's become clear that the
fix being applied to Cambridge units isn't very good and won't make them
as reliable as they were prior to November. Probably makes more sense to
just go buy a Nano or something similar if you need to replace the
logging capability.

-Dave

Now you are trashing all C302s. The all purpose instrument.
Logger. Vario. Flight director. Navigation instrument.

Originally Posted by David Kinsell[_2_]

On Thu, 04 Dec 2014 18:08:27 -0800, tom wrote:
[color=blue][i]
...

Garrecht Avioncs seems to have source code for the GPS module, and
intends to provide a fix in that code for their Volksloggers. It should
be straightforward to add another 20 years of life that way.


-Dave

Hi All,

1)
yes, we probably have a fix for the GPS25 modules, but it has to be confirmed working under all circumstances by a GPS simulator. This will of course take some time ...

2)
We do NOT have the sourcecode ...

3)
The only two solutions Garmin has officially suggested to us a

a) recharge the battery for 2 days and reinitialize the module by it's serial interface to a new date = obviously this only works for another 2-5 months.

Also, the rechargeable batteries inside the GPS25 also age with time - Garmin should know this. We got lots of new modules at beginning of the 2000s which were not able to hold their time and date for even 2 weeks.

b) replace module by GPS15 module.

For technical reasons, both solutions are not an option for us, thus we'll continue work on the firmware-patch, and at the same time on a software-only solution (new VALI-GCS files, maybe new VL firmware).



Good luck with the CAI solution.

On Fri, 05 Dec 2014 17:09:59 +0000, Georg Garrecht wrote:
[color=blue][i]
'David Kinsell[_2_ Wrote:
;892916']On Thu, 04 Dec 2014 18:08:27 -0800, tom wrote:

...

Garrecht Avioncs seems to have source code for the GPS module, and
intends to provide a fix in that code for their Volksloggers. It
should

be straightforward to add another 20 years of life that way.


-Dave
Hi All,

1)
yes, we probably have a fix for the GPS25 modules, but it has to be
confirmed working under all circumstances by a GPS simulator. This will
of course take some time ...

2)
We do NOT have the sourcecode ...

3)
The only two solutions Garmin has officially suggested to us a

a) recharge the battery for 2 days and reinitialize the module by it's
serial interface to a new date = obviously this only works for another
2-5 months.

Also, the rechargeable batteries inside the GPS25 also age with time -
Garmin should know this. We got lots of new modules at beginning of the
2000s which were not able to hold their time and date for even 2 weeks.


Yes, isn't it strange that when the problem first blew up in 1999, no one
suggested that merely replacing the battery was an adequate solution?
Yet now some people are claiming this is a "fix". It's a temporary Band-
Aid (rtm) that can fall off at any time. Probably when you're least
expecting it.


b) replace module by GPS15 module.

For technical reasons, both solutions are not an option for us, thus
we'll continue work on the firmware-patch, and at the same time on a
software-only solution (new VALI-GCS files, maybe new VL firmware).


Ian seems to be using the GPS15. As you no doubt are aware, it requires
a physical adapter, has an even tinier battery, and is no longer in
production. New firmware for the GPS25, or the VL, seems to be the right
solution. Glad you're pursuing the issue so vigorously. Perhaps Garmin
could be coerced into doing new firmware if the proper level of
complaints were directed their way. They released new firmware for GPS15
in 2009, but I can't find any info on whether it would have the same
issue pop up in 2019, or some other date.



Good luck with the CAI solution.

Tnx, but I don't suffer from delusions that the 302 is some kind of great
navigational device like some people do. When mine dies, I'll just
replace the logging function with something better.

-Dave

On Friday, December 5, 2014 8:43:04 PM UTC+1, Georg Garrecht wrote:
Hi All,

1)
yes, we probably have a fix for the GPS25 modules, but it has to be
confirmed working under all circumstances by a GPS simulator. This will
of course take some time ...

2)
We do NOT have the sourcecode ...

3)
The only two solutions Garmin has officially suggested to us a

a) recharge the battery for 2 days and reinitialize the module by it's
serial interface to a new date = obviously this only works for another
2-5 months.

Also, the rechargeable batteries inside the GPS25 also age with time -
Garmin should know this. We got lots of new modules at beginning of the
2000s which were not able to hold their time and date for even 2 weeks.

b) replace module by GPS15 module.

For technical reasons, both solutions are not an option for us, thus
we'll continue work on the firmware-patch, and at the same time on a
software-only solution (new VALI-GCS files, maybe new VL firmware).


Hi Georg,

Observing how my CAI 302 and my friend's Volkslogger work, when they are affected by the date issue, I believe that it is possible to make a simple dirty fix in the logger firmware without the necessity to change the firmware of GPS 25 module. This fix would work quite probably for about next 20 years (being more precise for about next 1024 weeks)

The affected CAI 302 & Volkslogger, which I have access to, are able to get correct position fix and correct time from GPS satellites. The only incorrect thing is date that is moved into past by 1024 weeks. To give an example, when we were flying on wave on Dec 13th 2014, IGC files produced by my CAI 302 & my friend's Volkslogger had a date of April 29th 1995. Next day the date in the IGC file was April 30th 1995.

So it looks that when power in the module backup battery runs out, the firmware initializes the RTC date and it uses a 10 bit variable where it stores number of weeks that passed from a module internal epoch date. A bug in the module firmware does not handle properly the 10 bit variable overflow and recently it started to cause moving the RTC date by 1024 weeks into past. Based on the fact that the issue recently appeared on many loggers, I estimate the internal GPS 25 module epoch date as near of beginning of 1995 year..

Good news is that the RTC time & position work correctly at least for now. Also looking at the behavior of the GPS 25 module, a next overflow on the 10 bit variable will occur about 1024 weeks from now, so the issue could be manageable for about next 20 years.

Taking my observations into account, I would like to suggest a simple 'dirty' fix to be implemented into the logger firmware that would resolve this issue for next 20 years. I would look as follows:

1) When a NMEA sentence with a date is received from the GPS module by logger, check the date inside the sentence. If the date is in past (say before Jan 1st 2015), it means that the GPS module is affected by the date issue. If no issue is detected, process the sentence in normal way. Otherwise go into step 2)
2) Add 1024 weeks to the date inside the NMEA sentence. Use the changed NMEA sentence for all further processing by the logger firmware

As you can see it is a pretty dirty fix, but should be very simple to implement. Alternatively, it should be possible to develop a 'less dirty' fix, which would move the module RTC clock by 1024 weeks when the date issue is discovered by sending to the module Sensor Initialization Information (PGRMI) with a corrected date. However, it would be more difficult to implement and quite probably not worth to spend additional effort comparing to the simple fix.

Cheers
Kris

On Thursday, December 4, 2014 9:49:54 PM UTC-5, David Kinsell wrote:

it's become clear that the
fix being applied to Cambridge units isn't very good and won't make them
as reliable as they were prior to November.
-Dave

Oh my!

To all Model 10/20/25,302A and 302 owners who have been following this topic, were happy with there instrument prior to this issue and want to keep using these devices(that's thousands of flight computer/recorders)you can send your recorder to a qualified equipment tech who will replace the 3v re-chargeable battery internal to the Garmin Receiver, send appropriate commands to the Garmin Receiver to reset the date and re-seal the instrument. After that, you are good to go for MANY more years.

IF you do not use the instrument for greater than 5 months, then power the instrument overnight to re-charge the Garmin battery as CHEAP insurance. With a little extra care they are as reliable as they were--no better and no worse then prior to this issue.....Gary

On Friday, December 5, 2014 8:48:04 AM UTC-5, Soaring Tech wrote:
On Thursday, December 4, 2014 9:49:54 PM UTC-5, David Kinsell wrote:

it's become clear that the
fix being applied to Cambridge units isn't very good and won't make them
as reliable as they were prior to November.
-Dave

Oh my!

To all Model 10/20/25,302A and 302 owners who have been following this topic, were happy with there instrument prior to this issue and want to keep using these devices(that's thousands of flight computer/recorders)you can send your recorder to a qualified equipment tech who will replace the 3v re-chargeable battery internal to the Garmin Receiver, send appropriate commands to the Garmin Receiver to reset the date and re-seal the instrument. After that, you are good to go for MANY more years.

IF you do not use the instrument for greater than 5 months, then power the instrument overnight to re-charge the Garmin battery as CHEAP insurance. With a little extra care they are as reliable as they were--no better and no worse then prior to this issue.....Gary

Thank you Gary for clearing this up.

Dennis

A recent posting by Ian Macphee on the Aus-soaring list says that there
was an older aluminum color case version of the 302, and a newer black
case version. Supposedly the black units don't have the date problem
because they don't use the GPS25. It may just be age of batteries, but
I'm curious if the failures have been following this pattern.

I have a black case unit, just tested as good. Clock had drifted by 8
minutes prior to lock, then corrected itself. Unit probably built 2006
or 2007, battery might have been replaced recently, not sure.

-Dave



On Fri, 05 Dec 2014 02:49:36 +0000, David Kinsell wrote:

On Thu, 04 Dec 2014 18:08:27 -0800, tom wrote:

I wonder if the affected FR manufacturers could add a mod to detect a
timestamp prior to "now" and munge it to the current epoch?

Interesting idea, but quite hypothetical when it comes to Cambridge.

Garrecht Avioncs seems to have source code for the GPS module, and
intends to provide a fix in that code for their Volksloggers. It should
be straightforward to add another 20 years of life that way.

As the details of the problem have come out, it's become clear that the
fix being applied to Cambridge units isn't very good and won't make them
as reliable as they were prior to November. Probably makes more sense
to just go buy a Nano or something similar if you need to replace the
logging capability.

-Dave

My 302 just tested fine and it has the Black case and was manufactured in 2010.

Randy