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

On Thursday, January 1, 2015 1:30:26 PM UTC+1, Tim Newport-Peace wrote:

Not quite.

The date is received as a 10-bit number from satellite transmission. The
GPS engine stores the epoch number. It is the epoch number which is lost
when the RTC battery discharges.

Epoch 0 ran from 6th Jan 1980 when GPS went active.
Epoch 1 (the current epoch) ran from 22nd Aug 1999.
Epoch 2 will begin on 7th April 2019.
Epoch 3 will begin on 21st November 2038
and so on.

Any fix needs to be ready for 7th April 2019 or we go back to page 1.

It would seem that Garmin introduced a temporary solution at in the
middle of 2000, causing all GPS OEM modules not to have a problem from
1996 to End of October 2014. This fix works correctly from 1.January
2005 +- 512 weeks, which has now expired. Hence the current rash of
problems.

Well I hoped that GPS Epoch changes are handled better by Garmin. So the fix that I suggested would work for about next 4 years until April 2019.

Do you remember what happened with GPS 25 module when the first GPS Epoch finished in 1999 ? Was it able to get proper position and time but it had wrong date, or it was not able to get the position at all ? If the former, it may be possible to create a revised 'dirty fix' that would work after April 2019

wrote:
On Thursday, January 1, 2015 1:30:26 PM UTC+1, Tim Newport-Peace wrote:

Not quite.

The date is received as a 10-bit number from satellite transmission. The
GPS engine stores the epoch number. It is the epoch number which is lost
when the RTC battery discharges.

Epoch 0 ran from 6th Jan 1980 when GPS went active.
Epoch 1 (the current epoch) ran from 22nd Aug 1999.
Epoch 2 will begin on 7th April 2019.
Epoch 3 will begin on 21st November 2038
and so on.

Any fix needs to be ready for 7th April 2019 or we go back to page 1.

It would seem that Garmin introduced a temporary solution at in the
middle of 2000, causing all GPS OEM modules not to have a problem from
1996 to End of October 2014. This fix works correctly from 1.January
2005 +- 512 weeks, which has now expired. Hence the current rash of
problems.

Well I hoped that GPS Epoch changes are handled better by Garmin. So the
fix that I suggested would work for about next 4 years until April 2019.

Do you remember what happened with GPS 25 module when the first GPS Epoch
finished in 1999 ? Was it able to get proper position and time but it had
wrong date, or it was not able to get the position at all ? If the
former, it may be possible to create a revised 'dirty fix' that would work after April 2019

Sounds to me that Garmin implemented some sort of windowing code to handle
the epoch rollover. It sounds very much like the code that was implemented
for the Y2k bug.

Long term it would be good if the logger manufacturers could support some
sort of date initialization if the rtc battery dies.

Pete

Do you remember what happened with GPS 25 module when the first GPS Epoch
f=
inished in 1999 ? Was it able to get proper position and time but it had
wr=
ong date, or it was not able to get the position at all ? If the former,
it=
may be possible to create a revised 'dirty fix' that would work after
Apri=
l 2019


Yes, the GPS wouldn't acquire position at all until it was reset, I was in
a comp at the time and left the GPS powered up while I borrowed another and
lfew. I used the reset command and after searching the sky it acquired the
position again.

On Thu, 01 Jan 2015 20:42:05 +0000, Peter von Tresckow wrote:

Long term it would be good if the logger manufacturers could support
some sort of date initialization if the rtc battery dies.

The fix is simple and obvious and has been so since the early '90s when
EEPROM memory became available at sensible prices: throw out the battery-
backed RAM and replace it with EEPROM/Flash memory.

Simply put, any GPS receiver built since, say, the mid-90s that used
battery-backed RAM for its epoch ID storage reflects badly on its maker.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

On Thursday, January 1, 2015 11:00:07 PM UTC+1, John Ferguson wrote:

Yes, the GPS wouldn't acquire position at all until it was reset, I was in
a comp at the time and left the GPS powered up while I borrowed another and
lfew. I used the reset command and after searching the sky it acquired the
position again.

So we may expect the same during the 2019 rollover. There are some questions abut what is going to happen after the rollover:
a) will GPS 25 acquire the position after the reset ? (imho quite probably yes)
b) what UTC date will be sent by the module when RTC is reset due to depleted RTC battery. It is difficult to predict, depends how Garmin implemented the date fix for the previous rollover

On Thu, 01 Jan 2015 23:39:48 +0000, Martin Gregorie wrote:

On Thu, 01 Jan 2015 20:42:05 +0000, Peter von Tresckow wrote:

Long term it would be good if the logger manufacturers could support
some sort of date initialization if the rtc battery dies.

The fix is simple and obvious and has been so since the early '90s when
EEPROM memory became available at sensible prices: throw out the
battery-backed RAM and replace it with EEPROM/Flash memory.

Simply put, any GPS receiver built since, say, the mid-90s that used
battery-backed RAM for its epoch ID storage reflects badly on its maker.

GPS engines acquire satellites much faster if they have a rough idea of
the time. The vendors not going to throw out the RTC with its battery-
backed RAM, but yes using a few bits of non-volatile storage to prevent
the date from going backwards would be a very good idea.

-Dave