GPS rollover, older GPS units & OpenCPN

[codger]

Originally Posted by transmitterdan

I’ll take a look and see what can be done to make sunrise/set not produce bogus times. But I can’t really fix wrong NMEA data.

I think that would be a great improvement, thanks for looking into it. (And yes, if the data in the NMEA stream is garbage it's reasonable to expect that Dashboard will produce garbage results as well!)

[hoolie]

Originally Posted by transmitterdan

Sunrise and sunset calcs require date and location.

I wrote the code for the various types of clocks. But they do not depend on location.

I’ll take a look and see what can be done to make sunrise/set not produce bogus times. But I can’t really fix wrong NMEA data.

The date offset is a fixed amount AFAIK (1024 weeks?) and my old laptop says the GPS date is 5th November 2000. It might be feasible to compare GPS date and system date and apply a fixed offset if the difference is >15 years for instance?

It is of interest as with my old laptop GPS module there's no way it can be updated.

[Tehani]

Originally Posted by SVHarmonie

The “wrong date” error on older GPS actually does not usually come from the April 2019 rollover of the week epoch number from 1024 to 0000 but from a rollover error that appeared in October 2108 when the week number went from 999 to 1000.

At least one vendor of GPS chips used in lots of products did not allow sufficient memory space to handle the number in decimal format. (Software QC? We need no stinkin’ QC!!)

The error actually only affects the human readable version of the date, and then whatever OTHER software relies on that—which would be everything on the N2K network... Internal position fixing calculations are not affected because they do not use the decimal version of the date.

That fault with the Raystar 120 I found in 2 devices in a date before October 2018. So it is likely that the two problems concur with the same effect.

[requiem]

Another scenario that could be seen with the rollover problem is described at https://kb.meinbergglobal.com/kb/tim...umber_rollover

There are 3rd party GPS receivers out there which take a very simply approach with a fixed week number limit, e.g.:

“If the transmitted week number is below 860 we assume a rollover has already occurred, and thus add 1024 to get a full week number. If the week number is above 860 we assume a rollover has not yet occurred.”

This approach is similar to extending a 2 digit year number to a full 4 digit year number. If you take 90 as a limit the resulting range would be 1990..2089.

For the GPS week number example this results in a valid range like 860 .. 1884 for the extended week number, but after real week number 1884 the calculation yields a number in the range 0..860, thus a wrong date 1024 weeks in the past.

The worst thing with this approach is that this switchback doesn't occur at the same time as the scheduled week number rollover in the satellite data. Instead, it can occur at an arbitrary weekend when the number reaches the threshold determined by the firmware developers.

This has happened with some 3rd party GPS receivers in February 2016, and some other 3rd party GPS receivers are expected to have problems after July, 2016. The exact time at which these kind of problems will occur depends on the GPS receiver model and firmware version, and is not related to the GPS system-specific rollover dates mentioned above.

[requiem]

Originally Posted by hoolie

The date offset is a fixed amount AFAIK (1024 weeks?) and my old laptop says the GPS date is 5th November 2000. It might be feasible to compare GPS date and system date and apply a fixed offset if the difference is >15 years for instance?

It is of interest as with my old laptop GPS module there's no way it can be updated.

Yes, 5 November is indeed about 1024 weeks ago. The fixed offset method is what my previous post mentioned; it basically offsets that 20 year window to instead start from an arbitrary date (say, the build date of the software). It will still break eventually, just closer to 20 years in the future instead of on the date of the next rollover.

The underlying problem arises if the software has no access to a known-good date or is switched off for more than 20 years. If those conditions are avoided, the problem can be worked around; you can use a larger counter for the date, and so long as you start with a good date and run the software somewhat regularly it can calculate the "real" date. A calibration option in the preferences would allow the software to re-align itself to the correct date.

Edit:
If you have a system date, and trust it, you might as well just use that. For those without a system clock at all, a method to "recalibrate" should still work. Thus, I think that's a more robust option.

For my particular case, I'm curious what date is seen if no GPS is attached. If it's zero'd out, that's a case for using the system clock (if available).