Cambridge 302 and GPS-NAV owners – IMPORTANT NEWS

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