Hi Dave, 768 weeks (3 * 256). Right.
In any modulus arithmetic situation you face a "windowing" decision. Look at your wristwatch right now. Mine says 14:46, or 2:46 PM. You are likely to say quarter 'till 3, rather than 3/4 after 2. Both are mathematically correct, but one is more "conventional". Like you say, it's a matter of where the fence is. But aside from these hourly conventions, reading your wristwatch may be just plain wrong. It could be quarter 'till 3 on Saturday, or maybe quarter 'till 3 Friday, or Sunday. The hands by themselves don't tell you. You have to rely on context, or memory, or common sense, or something external. If you are reading this posting via a time-nuts archive, was today June 21 of 2014, or 2013, or 2015? And even if you're a futuristic LongNow.org member, is it 02014 or 12014 or 22014? True, there are often hints, but not mathematical certainty. Especially if you only have 10-bits to encode the epoch. So how is a 58503A GPS time/frequency to know if today is GPS cycle number 0, or 1, or 2? In a few hours we begin GPS week 774. But is that in November 1994, or June 2014, or February 2034? How can the 58503A know for sure? In general, some absolute or external context is needed to remove the ambiguity in the cyclical hands of a wristwatch or calendar. Similarly this notion of absolute time or Gregorian calendar is lacking in GPS. This context is provided by unspecified manufacturer-specific heuristics in individual GPS receivers, or user input. When programmers face the 10-bit, 1024-week (19.6 year) GPS week issue, they have to decide how to handle the window. There are many algorithms: none is perfect, but most work fine. It does not surprise me that some use the 1/2 point, or 3/4, or 7/8 points as the "date line" boundary to go back 1024 weeks or go forward 1024 weeks. I suspect many use a firmware revision date as an arbitrary origin and then use a -0/+19.6 year for their window. Perhaps some use a -9.8/+9.8 year window. Or if the 256 week hunch is correct, a -4.9/+14.7 year window. Unfortunately, we're never given the source code to commercial GPS/GPSDO. Using GPS simulators is still beyond the reach of us amateur time/frequency experimenters. So we just encounter these boundary points as they occur. If you go back in the time-nuts archives there are a number of magic dates where strange things happen. /tvb ----- Original Message ----- From: "Dave Martindale" <[email protected]> To: "Tom Van Baak" <[email protected]>; "Discussion of precise time and frequency measurement" <[email protected]> Sent: Saturday, June 21, 2014 1:06 PM Subject: Re: [time-nuts] 58503A date code problem Interesting. It was May 22 this year when I first noticed that my Garmin 45XL was reporting a date in 1994, exactly 1024 weeks early. That's also consistent with Garmin having used 768 weeks as their "fence" for a GPS week being in the past instead of the future. It's really the same as the International Date Line, picking an arbitrary line that advances and retards the apparent time as you cross it. But the delta-time for the GPS week rollover is nearly 10 years, instead of 24 hours. - Dave On Sat, Jun 21, 2014 at 3:44 PM, Tom Van Baak <[email protected]> wrote: > Hi Daniel, > > What you have is a 58503A, the GPS time/frequency receiver (the 58530A is a > GPS bandpass filter). > > Note that today is MJD 56829. Exactly 1024 weeks (7168 days) ago was November > 4, 1994. So this looks like a typical GPSDO week number rollover issue. It > shouldn't affect the time or the 1PPS or the 10 MHz. One thing to try is > manually setting the date using a SCPI command. > > You can check www.realhamradio.com/GPS_websites_list.htm to see if anyone > else has seen this on their 58503A or Z3801A receivers. > > Did you notice it happened just today, or did it start happening maybe a few > weeks ago? > > I ask because recently we passed the 3/4 mark in the current 1024-week (19.6 > year) GPS cycle. Specifically, on 2014-05-04 it was 768 weeks since the last > rollover (1999-08-15) and 256 weeks before the next rollover (2019-03-31). > > /tvb > > ----- Original Message ----- > From: "Daniel Burch" <[email protected]> > To: <[email protected]> > Sent: Saturday, June 21, 2014 10:06 AM > Subject: [time-nuts] 58503A date code problem > > >> Hi All, >> >> I have a HP/Symm 58530A that has the correct time, but date keeps >> defaulting to 1994, Nov, 4 after GPS Lock. The pre-lock is 1996, so I do >> see a change when it locks, just to the wrong date.....time is exactly >> correct and tracks. >> >> Any ideas? >> >> Thanks! >> >> db > _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
