[time-nuts] TymServe 2100 1995 Issue - A Kludgy Fix

Bob Camp kb8tq at n1k.org
Sat May 9 20:14:30 UTC 2015


Hi

As far as I can see, the 13 bit week stuff is still very much in the “testing” phase. I’d say that counting 
on it working on anything made before 2013 is a bit of a stretch. I would also bet that roughly 90% of the
“current”  timing GPS chip set designs do not yet fully support it. That might change with a firmware upgrade
(if one ever comes out for your chip set etc.). Based on how well things like leap years seem to get taken 
care of, we’ll really only know in 20 years or so.

Yes it’s a bit confusing, it’s all snarled up in the “block III will be here in 2008” ... err…2014 … err …2017 …errr...
confusion. 

Bob

> On May 6, 2015, at 12:04 PM, Brian Inglis <Brian.Inglis at SystematicSw.ab.ca> wrote:
> 
> On 2015-05-05 11:32, Alan Ambrose wrote:
> 
>> It's not that simple. First, it's not 20 years, but 1024 weeks (19.6 years).
>> And not UTC weeks (which may have leap seconds) but GPS weeks (which do not,
>> and are always 604800 seconds long). etc
> 
>> Don't think it's _that_ much code though. There's some open source ACM date
>> algorithms, and it would be easy enough to implement a quick and dirty fix,
>> adding a number of days offset, while the rest of the algorithm is tested.
> 
> See http://www.leapsecond.com/notes/gpswnro.htm
> This was first noted in 1996 and has been happening since the first rollover
> in August 1999 so some affected NTP GPS drivers have been patched to add 1024
> weeks while the input is more than 512 weeks in the past.
> 
>> Will the next time this problem reoccurs be another 20 years?
> 
> The next rollover is about April 2019, but this can happen any time an older
> receiver's internal date representation used for GPS to UTC conversion overflows.
> Looks like Tymserve 2100 picked about Sep 1995 for its date epoch so it hits now.
> 
> Newer GPS receivers support the extra 3 bits added to GPS extended week allowing
> 8192 weeks (157 years) between rollovers - 2137 is the next big rollover problem,
> but NavStar will likely not be sending the same data on the same frequency then.
> 
> -- 
> Take care. Thanks, Brian Inglis
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.




More information about the Time-nuts_lists.febo.com mailing list