[teqc] Curing files with GPS rolllover issues

François Meyer fmeyer at obs-besancon.fr
Fri Apr 12 13:06:06 UTC 2019


On Fri, 12 Apr 2019, lplopresti at enter.net wrote:

> On 2019-04-12 07:47, Uwe Hessels wrote:
>> Dear colleagues,
>> 
>> i also still use an old Ashtech Z12T after the week rollover.
>> With the command:
>> teqc -ash s -week ${year}:${dayofyear} +obs inputrawfile.ash 
>> outrinexfile.19O
>> i get rinex files, which at least teqc interpreted as correct (+qc):
>> 
>> 2019 Apr 12 
>> 2019 Apr 12
>> 
>> *********************
>> QC of RINEX  file(s) : PTBG102B.19O
>> *********************
>> 
>> 4-character ID          : PTBG
>> Receiver type           : ASHTECH Z-XII3T (# = RT902232501) (fw = 
>> 1L01-1D04)
>> Antenna type            : ASH701945E_M    SNOW (# = CR6200327009)
>> 
>> Time of start of window : 2019 Apr 12  01:00:00.000
>> Time of  end  of window : 2019 Apr 12  01:59:30.000
>> Time line window length : 59.50 minute(s), ticked every 10.0 minute(s)
>> Observation interval    : 30.0000 seconds
>> Total satellites w/ obs : 14
>> NAVSTAR GPS SVs w/o OBS :  4   5   7   8  10  13  15  16  20  21  24 
>> 25
>>                           26  27  28  29  30  32
>> Rx tracking capability  : unknown
>> Poss. # of obs epochs   :    120
>> Epochs w/ observations  :    120
>> Epochs repeated         :      0  (0.00%)
>> Complete observations   :   1076
>>  Deleted observations   :     51
>> Obs w/ SV duplication   :      0  (within non-repeated epochs)
>> Moving average MP12     : 0.607154 m
>> Moving average MP21     : 0.556778 m
>> Points in MP moving avg : 50
>> Mean S1                 : 44.23 (sd=5.37 n=1124)
>> Mean S2                 : 41.51 (sd=4.87 n=1124)
>> No. of Rx clock offsets : 0
>> Total Rx clock drift    :  0.000000 ms
>> Rate of Rx clock drift  :  0.000 ms/hr
>> Avg time between resets : Inf minute(s)
>> Freq no. and timecode   : 2 14341 000002
>> Report gap > than       : 10.00 minute(s)
>>        but < than       : 90.00 minute(s)
>> epochs w/ msec clk slip : 0
>> other msec mp events    : 0 (: 25)   {expect ~= 1:50}
>> IOD signifying a slip   : >400.0 cm/minute
>> IOD slips               :     28
>> IOD or MP slips         :     28
>>       first epoch    last epoch    sn1   sn2
>> SSN 19  4 12 01:00 19  4 12 01:59 44.23 41.51
>>       first epoch    last epoch    hrs   dt  #expt  #have   %   mp1 
>> mp2 o/slps
>> SUM 19  4 12 01:00 19  4 12 01:59 1.000  30     -    1076  -   0.61 
>> 0.56     38
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> I don't have OPUS to check, but perhaps the user can test with one of 
>> my files.
>> 
>> Only the navigation files stay 1024 weeks off.
>> 
>> Best regards, Uwe Hessels.
>> 
>> 
>> 
>> Am 11.04.2019 um 21:39 schrieb Joe Evjen:
>>> FYI only, passing along a possible fix for GPS-week-rollover-affected 
>>> GPS data files.
>>> 
>>> A user of https://geodesy.noaa.gov/OPUS/ reported collecting a 
>>> post-rollover data file on
>>> an old ashtech receiver which looked normal, except all time tags were 
>>> 1024 weeks off, in
>>> August 1999. Using teqc
>>> 
>>> "with: Teqc -week 2048 B_T3_A99.235 > RT310980.19o Original as 
>>> downloaded B file > output
>>> file. That generated a rinex file with the correct date. The file 
>>> appears to be a typical
>>> rinex file. However opus returns “...opus doesn’t recognize format...”
>>> 
>>> 
>>> 
>>> 
> Uwe,
>
> Correcting the Nav file depends on what you do with the RINEX 
> Observation file. OPUS understands that every Nav file for a certain day 
> is the same for the observation time period and thus does not need to 
> use any individual station Nav file. My personal processing program 
> requires the Nav file and if I do not feel like correcting it I copy a 
> different receiver Nav file and rename it to match the Observation file.

That works for sure, but the main issue (at least for me, and maybe for 
Uwe also) is that it breaks existing automated processing schemes 
and makes the Z12 final products rely on the availability of files from 
another receiver. Might be temporarily ok, but any problem/maintainance/
outage/removal of the second receiver will break production on the Z12.
An autonomous solution would remain far more reliable.

> Lawrence Paul Lopresti
>
>>> _______________________________________________
>>> teqc mailing list
>>> teqc at postal.unavco.org
>>> https://postal.unavco.org/mailman/listinfo/teqc
>>> 
>> 
>> --
>> Mit freundlichen Grüßen, Uwe Hessels
>> _________________________________________________
>>   Dipl.Ing. Uwe Hessels
>>   Bundesamt für Kartographie und Geodäsie
>>   Geodätisches Observatorium Wettzell
>>   Betriebsgruppe Mikrowellenverfahren VLBI-GNSS-DORIS
>>   Sackenrieder Str. 25
>>   D - 93444 Bad Kötzting
>>
>>   Tel:             +49 (0) 9941 / 603-208 oder -128
>>   FAX:             +49 (0) 9941 / 603-222
>>   switchboard      +49 (0) 9941 / 603-0
>>   e-mail (office)  G_GPS at fs.wettzell.de
>>   e-mail (office)  uwe.hessels at bkg.bund.de
>>   e-mail (altern.) hessels at fs.wettzell.de
>>   URL              http://www.fs.wettzell.de
>>                    http://www.bkg.bund.de
>> _________________________________________________
>> 
>> _______________________________________________
>> teqc mailing list
>> teqc at postal.unavco.org
>> https://postal.unavco.org/mailman/listinfo/teqc
> _______________________________________________
> teqc mailing list
> teqc at postal.unavco.org
> https://postal.unavco.org/mailman/listinfo/teqc

-- 
Dr François Meyer  Tel : (+33) 3 81 66 69 27   Mob : (+33) 6 27 28 56 83
Dir. exécutif plateforme OscIMP
Dir. LNE-LTFB, laboratoire temps-fréquence associé au LNE
Institut UTINAM / OSU Theta
41b avenue de l'Observatoire, BP1615
25010 Besancon cedex - FRANCE
** Universite de Franche-Comte ** CNRS UMR 6213 ** UMS 3245


More information about the teqc mailing list