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 <[email protected]> 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 <[email protected]> >> 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 -- [email protected] >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. > > _______________________________________________ > time-nuts mailing list -- [email protected] > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
