petervince1952@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.
--
These are my opinions. I hate spam.
Timing product manufacturers used a variety of OEM GPS timing receivers over the years including the Motorola Oncore series. The 1024 Week-Roll-Over dates for Oncore receivers, computed from the firmware version compile date, are listed here:
http://www.synergy-gps.com/images/stories/pdf/motorola%20oncore%201024%20week%20roll.pdf
Synergy is adding 8 channel Motorola binary commands to our u-Blox based SSR-6Tf OEM timing receiver that plugs into an Oncore 8 channel slot - available "soon."
Art Sepin
-----Original Message-----
From: time-nuts [mailto:time-nuts-bounces@febo.com] On Behalf Of Hal Murray
Sent: Thursday, September 08, 2016 2:54 PM
To: Discussion of precise time and frequency measurement time-nuts@febo.com
Cc: hmurray@megapathdsl.net
Subject: Re: [time-nuts] Z3801A gps week rollover
petervince1952@gmail.com said:
Can I just ask why the Z3801As are having week roll-over problems now
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.
--
These are my opinions. I hate spam.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.febo.com%2fcgi-bin%2fmailman%2flistinfo%2ftime-nuts&data=01%7c01%7cart%40synergy-gps.com%7c408bcd4a64434c427d9208d3d832af29%7cc81f9fdec0e04d8c95779afaa0cad9ed%7c1&sdata=jhAM9HQSsGEdLO%2bD6Z4ul5ddcmMTeibYI8J2UGgesYU%3d
and follow the instructions there.
That makes sense - thanks guys!
Peter
On 8 September 2016 at 22:53, Hal Murray hmurray@megapathdsl.net wrote:
petervince1952@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.
--
These are my opinions. I hate spam.
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.
Hi,
On 09/08/2016 11:53 PM, Hal Murray wrote:
petervince1952@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.
Cheers,
Magnus
Hi
On Sep 9, 2016, at 3:06 AM, Magnus Danielson magnus@rubidium.dyndns.org wrote:
Hi,
On 09/08/2016 11:53 PM, Hal Murray wrote:
petervince1952@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.
Bob
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.
On 09/09/2016 01:17 PM, Bob Camp wrote:
Hi
On Sep 9, 2016, at 3:06 AM, Magnus Danielson magnus@rubidium.dyndns.org wrote:
Hi,
On 09/08/2016 11:53 PM, Hal Murray wrote:
petervince1952@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