On 09/09/2016 01:17 PM, Bob Camp wrote:
Hi
On Sep 9, 2016, at 3:06 AM, Magnus Danielson <mag...@rubidium.dyndns.org> wrote:
Hi,
On 09/08/2016 11:53 PM, Hal Murray wrote:
petervince1...@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
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
