[teqc] Ashtech Z12 spurious rollover bug

François Meyer fmeyer at obs-besancon.fr
Wed Nov 9 07:34:01 MST 2016


On Wed, 9 Nov 2016, Lou Estey wrote:

> Thanks for this information, François.  This is a strange thing to happen
> this GPS week (1922):
>
> 1922 (base10) == 0111 1000 0010 (base2)
>
> If it had happened last week or the week before:
>
> 1921 (base10) == 0111 1000 0001 (base2)
> 1920 (base10) == 0111 1000 0000 (base2)
>
> then one assume it had something to do with a base2 bit rollover.

That also was my first thought (before I realized that to get to 128
I was shamelessly adding 2 days (sunday, monday) to 126 weeks...)

Data files follow soon in a separate mail.

> Obviously the workaround for teqc users is to use the '-week' option with
> the correct GPS week value.  (For anyone not familiar with this, see
> 'tip of the week' http://postal.unavco.org/pipermail/teqc/2016/002117.html )
>
> Could you send me (not the list) a sample file from a Z12 doing this?
>
> cheers,
> --lou
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Louis H. Estey, Ph.D.              office:  [+001] 303-381-7456
> UNAVCO, 6350 Nautilus Drive           FAX:  [+001] 303-381-7451
> Boulder, CO  80301-5554            e-mail:  lou  unavco.org
>     WWW:  http://www.unavco.org   http://jules.unavco.org
>
> "If the universe is the answer, what is the question?"
>                                               -- Leon Lederman
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> On 09-Nov-16 05:43 AM, François Meyer wrote:
>> Hi,
>> 
>> A number of Ashtech Z12 receivers had a spurious rollover event at the week 
>> boundary this sunday ; it makes them generate raw files with
>> bogus (1024 week late) dates,
>> both in the file name and the content.
>> 
>> It looks as if firmware had somehow determined that 1999 aug 21 is still to 
>> come, therefore ceased to add 1024 to WN hence
>> jumped back to 1997 march 23 (WN 898) instead of 2016/11/06 (WN 1922).
>> 
>> Proper week number must be supplied as an argument to teqc
>> at processing time. Data quality looks otherwise unaffected at that point.
>> 
>> Our sample is :
>> receiver type:           ASHTECH Z-XII3
>> receiver firmware:       1L01
>> 
>> but other colleagues have been affected, maybe with different
>> flavors.
>> 
>> Can this be fixed anyhow ? thanks,
>> 
>> regards
>


More information about the teqc mailing list