[ANSS-netops] xlak date stamp wrong; notes on NCSN TrueTime fix

[Dietz, Lynn]

Our clock, like yours, said January 1994 after the UTC-day change on
Saturday evening. But the field which stores the current year for GPS
epoch management (which you can manually change with the F68 serial
command, or with the front panel keypad) showed 1996 when initially
interrogated. We changed that field to 2013, rebooted, and now get the
correct timestamp.

So from what you read, the TrueTime week rollover seems to be tied to
its manufacture date, not any real GPS week rollover. That's rather
non-intuitive.


On Mon, Aug 19, 2013 at 2:13 PM,  <mwithers at memphis.edu> wrote:
>
> If your clock said 1996, then I don't know what's going on.  If it was 1994
> like ours, then its the week rollover.  Based on what I've been reading some
> programs had hooks to get past the 1999 rollover but then would experience
> the
> rollover 19 years from their manufacture.  For us, that was August 18, 2013.
> The week counter went from 1023 to 0 making the clock think it was 1024
> weeks
> ago (or January 1994).  There was also apparently a feature built in that
> allows you to set the year manually and it then figures out which epoch its
> in.
>
> I suspect there is a decent chance that the clocks that didn't rollover over
> last weekend will at some point in the future, 19 years after they were
> manufactured.  So it might be useful to try to find out what that date is.
>
> Mitch
>
> Center for Earthquake Research and Information (CERI)
> University of Memphis                Ph: 901-678-4940
> Memphis, TN 38152                   Fax: 901-678-4734
>
>
> On Mon, 19 Aug 2013, Dietz, Lynn wrote:
>
>> Will Kohler logged onto the School Peak TrueTime via its serial port
>> interface, and found that the year returned by the F68 command (Year
>> Entry for GPS Epoch Management) was 1996.  We set this year to 2013
>> and did a warm restart F79, and the reported time was corrected.  We
>> also power-cycled the TrueTime to verify that our fix would survive,
>> and it did. Now F68 reports the current year, and the output time is
>> correct. Adsend is running again, producing properly-timestamped data.
>>
>> FYI, only the School Peak TrueTIme clock (1 of 7 in the network) went
>> to Jan 2, 1994 this past weekend. It's firmware rev is:
>>
>> School Peak F18:  TRUETIME XL     ACE3 sys ver 030 GPS-XL V1.047
>> 182-6064v008
>>
>> The manual says that the firmware is supposed to keep the F68 year
>> up-to-date if the clock has GPS lock, so we're not sure why this one
>> was set at 1996.
>>
>> I will visit our other TrueTime clocks, ensure that F68 shows 2013,
>> and note their firmware revs.
>>
>> Lynn
>>
>>
>> On Sun, Aug 18, 2013 at 2:03 PM,  <mwithers at memphis.edu> wrote:
>>>
>>>
>>> We were manually able to reset the dates and it seemed to keep the
>>> correct
>>> date after a power cycle.  It was suggested that it might be a epoch
>>> rollover
>>> of a 10 bit week number.  They occur a little more than every 19 years.
>>> The
>>> last one was in January 1999 so the next one shouldn't happen until 2019
>>> (more modern systems use 13 bits to store the week number).  Its possible
>>> depending on how the firmware was written to handle the first rollover,
>>> that
>>> subsequent rollovers would occurr on 19 year intervals with a static
>>> offset
>>> from 1999.  That would mean that our clocks would return to 1994 (and I
>>> think in fact that they did).  So perhaps it did rollover and the
>>> firmware
>>> had the ability to recognize and account for the next rollover once we
>>> manually intervened?
>>>
>>> Unfortunately, now we have a few remote nodes to visit.
>>>
>>> Mitch
>>>
>>> Center for Earthquake Research and Information (CERI)
>>> University of Memphis                Ph: 901-678-4940
>>> Memphis, TN 38152                   Fax: 901-678-4734
>>>
>>>
>>> On Sun, 18 Aug 2013, Oppenheimer, David wrote:
>>>
>>>> Yes. We had a true time clock at remote EW node exhibit the same
>>>> behavior.
>>>> the hour minute were correct.  Wierd
>>>>
>>>>
>>>> On Sun, Aug 18, 2013 at 9:18 AM, <mwithers at memphis.edu> wrote:
>>>>
>>>>>
>>>>> Is anyone else who still uses analog data and gets time from an XLAK
>>>>> having
>>>>> problems?  All of our clocks appear to have reset to Jan 2, 2013 at UTC
>>>>> midnight last night.  This causes adsend to have the wrong date.  And
>>>>> if
>>>>> you have adsend set to sync the system time to it, your system date is
>>>>> wrong.
>>>>>
>>>>> Mitch
>>>>>
>>>>> Center for Earthquake Research and Information (CERI)
>>>>> University of Memphis                Ph: 901-678-4940
>>>>> Memphis, TN 38152                   Fax: 901-678-4734
>>>>>
>>>>>
>>>>> ______________________________**_________________
>>>>> ANSS-netops mailing list
>>>>> ANSS-netops at geohazards.usgs.**gov <ANSS-netops at geohazards.usgs.gov>
>>>>>
>>>>>
>>>>> https://geohazards.usgs.gov/**mailman/listinfo/anss-netops<https://geohazards.usgs.gov/mailman/listinfo/anss-netops>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> David Oppenheimer                   office: 650.329.4792
>>>> U.S. Geological Survey              fax:    650.329.4732
>>>> 345 Middlefield Road - MS 977   email: oppen at usgs.gov
>>>> Menlo Park, CA 94025
>>>>
>>>
>>
>>
>