[ntp:questions] Start of new GPS 1024 week epoch

unruh unruh at invalid.ca
Wed Aug 14 11:54:59 UTC 2013


On 2013-08-14, Mark C. Stephens <marks at non-stop.com.au> wrote:
> Good on you David and welcome back to 2013.
> I do hope that some official changes are made to refclock_nmea to catch this receiver bug and process it accordingly.
> There are a lot of folks 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: 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.

Surely if the receiver is delivering the wrong date, it is the receiver
manufacturer that needs to make the changes, not ntp, including sending
you a new receiver if necessary. Warrenty limits notwithstanding, this
fails that "fitness for purpose" test, and you could hardly have
detected it when you bought it. 


>
> 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.

Except of course if the rd_timestamp.l_i is way out (that is why one
would want to use a gps clock to fix it-- eg on bootup with the
Raspberry Pi say), 
>
> 	David.
>
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions



More information about the questions mailing list