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

[mwithers at memphis.edu]

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
>>>
>>
>
>