[time-nuts] Z3801A gps week rollover
magnus at rubidium.dyndns.org
Fri Sep 9 11:58:53 EDT 2016
On 09/09/2016 01:17 PM, Bob Camp wrote:
>> On Sep 9, 2016, at 3:06 AM, Magnus Danielson <magnus at rubidium.dyndns.org> wrote:
>> On 09/08/2016 11:53 PM, Hal Murray wrote:
>>> petervince1952 at gmail.com said:
>>>> Can I just ask why the Z3801As are having week roll-over problems now - I
>>>> didn't think it was 2048 weeks since GPS "zero-hour" until late on the 6th
>>>> of April 2019?
>>> It's probably 1024 weeks since a date was built into the firmware.
>>> It's like the year 2000 problem. If you aren't worried about old people and
>>> I tell you somebody was born in 03, you can assume that's 2003 rather than
>>> 1903. For GPS, a handy value for the cutoff is the date the firmware was
>>> built. Any date that looks like it is older than the firmware is probably
>>> off by a rollover.
>> We had this discussion in NTP context, and people where saying "We won't fix receiver problems" and where not helpful. When I explained how GPS time actually worked and just showing how the receivers was attempting to correct the GPS signal behaviors they realized that 1024 week wrap-around is more of a GPS generic problem and accepting time modulus 1024 weeks was not too hard. I don't know if that ever made it into the code thought.
> The bigger problem for NTP is when the leap second correction process is thrown off by the “time warp”. When leap seconds get fixed in
> mid-August rather than the end of June … not a good thing.
Uhm, not same bug.
The UTC offset message is expressed in GPS-week modulo 256, so if it is
off modulo 1024 does not care, it can adjust leap-second corrections
correctly even if it's can display the correct date.
Naturally, you can implement this incorrectly.
More information about the time-nuts