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

Henry Hallam henry at pericynthion.org
Mon May 11 00:26:30 UTC 2015


Is the 13-bit week number somewhere in the L1 C/A message? I see it in
the CNAV definition for broadcast on L2C and L5 (and eventually, with
GPS III, L1C), but I don't see any indication of a 13-bit week number
in the LNAV section of IS-GPS-200H.  So as far as I can tell, it is
not being and will not be broadcast on L1 any time soon.  Please
correct me if I'm wrong :)

Henry

On Sat, May 9, 2015 at 1:14 PM, Bob Camp <kb8tq at n1k.org> wrote:
> 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.
>
> _______________________________________________
> 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