time-nuts@lists.febo.com

Discussion of precise time and frequency measurement

View all threads

Re: [time-nuts] Z3801A gps week rollover

HM
Hal Murray
Thu, Sep 8, 2016 9:53 PM

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.

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.
AS
Art Sepin
Thu, Sep 8, 2016 10:50 PM

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

  • 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://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.

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 > - 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://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.
PV
Peter Vince
Thu, Sep 8, 2016 10:51 PM

That makes sense - thanks guys!

 Peter

On 8 September 2016 at 22:53, Hal Murray hmurray@megapathdsl.net wrote:

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.

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. >
MD
Magnus Danielson
Fri, Sep 9, 2016 7:06 AM

Hi,

On 09/08/2016 11:53 PM, Hal Murray wrote:

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 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
BC
Bob Camp
Fri, Sep 9, 2016 11:17 AM

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:

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.

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.
MD
Magnus Danielson
Fri, Sep 9, 2016 3:58 PM

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:

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

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