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

[mwithers at memphis.edu]

Yeah, I read it on the internets so it must be true.  Maybe not but the data
fit the theory.

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:

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