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

[Bob Camp]

Hi

The only definitive statement I have seen for implementation of the 13 bit week is
that it will be part of the Block III deployment process. Anything going on now is
“testing only”. Block III now looks like a 2017 sort of thing. 

There may be people out there with fancy simulators that are 100% perfect. They 
*could* have coded and tested a 13 bit solution a few years ago. My observation is
that *very* few people do this. The normal approach seems to be to wait until there
are on the air signals and then test against them. That way you can cope with any
odd last minute adjustments in the transmitted format. 

Bob

> On May 10, 2015, at 8:26 PM, Henry Hallam <henry at pericynthion.org> wrote:
> 
> 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.
> _______________________________________________
> 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.