[time-nuts] Z3801A gps week rollover

Magnus Danielson magnus at rubidium.dyndns.org
Fri Sep 9 15:58:53 UTC 2016



On 09/09/2016 01:17 PM, Bob Camp wrote:
> Hi
>
>
>> On Sep 9, 2016, at 3:06 AM, Magnus Danielson <magnus at rubidium.dyndns.org> wrote:
>>
>> Hi,
>>
>> 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.

Cheers,
Magnus



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