[time-nuts] FW: [ntp:questions] Start of new GPS 1024 week epoch

[Mark C. Stephens]

David Malone is on the ball Magnus, he replied to your post with a patch for nnmea refclock drver...

The changes to reclock_nmea will be interesting to see over next few weeks..
I do hope it is officially picked up, as there are a lot of people stranded in 1993!


--marki

-----Original Message-----
From: questions-bounces+marks=non-stop.com.au at lists.ntp.org [mailto:questions-bounces+marks=non-stop.com.au at lists.ntp.org] On Behalf Of David Malone
Sent: Wednesday, 14 August 2013 5:30 AM
To: questions at lists.ntp.org
Subject: Re: [ntp:questions] Start of new GPS 1024 week epoch

Magnus Danielson <magnus at rubidium.dyndns.org> writes:

>Remember that any Sunday, it is likely that a GPS reciever have slipped 
>a multiple of 1024 weeks. NTP drivers should be able to recognice it 
>and compensate for it, as it is a re-occuring bug in many recievers.

>This issue have been discussed over and over again at time-nuts.

It seems my ancient GPSclock 200 has recently slipped back to December 1993 too. Resetting it hasn't helped and I doubt I will be able to do a firmware update, so I've made a hack to refclock_nmea.c (version ntp-4.2.6p5), by replacing:

        reftime.l_ui += caltontp(&date);

with 

        reftime.l_ui += caltontp(&date);
	while (reftime.l_i + 512*7*86400 < rd_timestamp.l_i)
		reftime.l_i += 1024*7*86400;

I'm trying to adjust the timestamp given by NMEA might be slow by some multiple of 1024 weeks, and so tries to adjust it so that it is reasonably close to the system time associated with the read of the NMEA data.  I'm not sure if I've got the code exactly bang-on, but it has got ntp running with the unit again.

	David.

_______________________________________________
questions mailing list
questions at lists.ntp.org
http://lists.ntp.org/listinfo/questions