Quick and dirty GPS week number rollover fix

[dl9sec]

Hi,

I am using a mature Perthold ST22 (SkyTraq Venus 6 based) GPS module which suffers from the "GPS week number rollover" problem (https://en.wikipedia.org/wiki/GPS_Week_Number_Rollover).

There is no new firmware for the module, so this must be fixed in the application. By adding 1024 weeks to the date value given at the NMEA GPRMC sentence we will get a correct date (e.g. 14.10.2000 + 1024 weeks = 30.05.2020).

With a quick and dirty fix the GPS date is converted to a UNIX timestamp epoch, the 1024 weeks are converted to seconds and added to the timestamp. After that the timestamp is converted back to the timecore datum_t format.

Datefixing can be configured by WK_ROLLOVER_M, a multiplier value. For no fixing set to 0. For old GPS set to 1 after April 2019 and set to 2 for the next rollover in somewhere in 2038.

LEAP_YEAR() and ConvertToTimestamp() are taken from the timecore (unfortunately declared as private there...).

Attached the patch file...

Regards, Thorsten

GPS_week_number_rollover_qndfix.patch.txt

[lab-mathias-claussen]

Hi dl9sec,

for the modules not able to get a fimrware fix i would suggest that in the webinterface will be an option for the offset so you don't have to fiddle with the code itself and add defines. This shoudl keep one fimrware for all devices. For the functions to add the offset in the timecore we will see how to export the requiered functions nicly.

Regards and 73

DK3MC

[dl9sec]

Hi Mathias,

I fully agree :-) Would be really nice to have it in the Web UI. I was not sure if this is a real problem for a lot of users, because there wasn't any request concerning this issue. Therefore just a quick and dirty hack also as a hint and guide...

Regards, Thorsten

[lab-mathias-claussen]

Added option in the webinterface to set the rollover count