[teqc] Problem with tecq +smtt

Geoff Blewitt gblewitt at unr.edu
Sat Aug 20 12:03:55 MDT 2005


Well done Lou.  Yes, I think Trimble ought to fix this problem, even 
though its rare.

There's no telling how this might affect the various GPS software 
programs out there.  For example, in the common flavor of RINEX using 
"tecq -smtt" (the default option) the reported time tag in RINEX is 
non-integer in two cases: (1) the receiver time tag was really 
non-integer, or (2) the (cumulative) non-integer part reflects how much 
the clock has been steered, and does not truely reflect the real time 
tag. In this flavor of RINEX its impossible to tell the difference. 
(With "gipsy", which doesn't directly read this flavor, it first 
requires us to run "clockprep", which of course has the same problem - 
it has no way of knowing that the time tag is real or an artifact of 
1-msec clock steering).

To answer one of your questions, yes, the analogous ".0010000" problem 
is with a different receiver.  (Typically a specific receiver clock 
drift is always in only one direction).

Thanks,
- Geoff

Lou Estey wrote:
> hi Geoff,
> 
> 
>>I'm using the Trimble 5700, firmware is 2.10/1.22
>>In addition, I find ".001" time tags too (as I would have expected).
>>
>>
>>>Hmm.  Are all files from the same receiver, or at least the
>>>same receiver type and firmware?
>>
>>Its happening with all 3 receivers that I've got large files for.
>>All are the same receiver type and firmware.
>>I haven't yet checked normal daily files from other receivers.
> 
> 
>>If I understand this correctly, this test doesn't prove one way or the 
>>other as to whether tecq +smtt is doing the right thing.  That's because 
>>its impossible to resolve a ~1 meter level jump (due to change in range) 
>>without a more sophisticated model than eyeballing the data.  However, 
>>the test is consistent with tecq being correct, and the receiver has 
>>very rare cases of .999 time tags.
>>
>>I've made the dat file available by anonymous ftp at
>>gneiss.nbmg.unr.edu
>>filename: ANTE0422.05.dat  (168.8 Mb)
> 
> 
>>The first anomalous time tag occurs at date/time:
>>grep "5  3  3  9 57 44.999" <rinex file>
>>where the rinex file can be created using teqc +smtt
> 
> 
> Ok, getting the dat file, I ran
> 
> teqc +rx_clk_off +smtt +diag -O.obs - ANTE0422.05.dat > junk 2>&1
> 
> which creates a file with the recording parsing (+diag) mixed
> with RINEX time stamp lines (no observables; -O.obs -).  This
> also puts out the optional receiver clock offset value at the
> end of the RINEX time stamp line (+rx_clk_off).  Then
> 
> [438] grep "\.999000" junk
>   05  2 21  4 56 44.9990000  0  6G20G 1G14G22G11G25                  -0.000499895
>   05  2 22 23 36 44.9990000  0  9G 3G26G16G22G21G29G18G 6G15         -0.000499844
>   05  2 23 20 58 14.9990000  0  7G 2G10G 5G 6G30G21G29               -0.000499905
>   05  2 24 12 37 14.9990000  0  8G 7G11G29G28G 8G19G26G27            -0.000499926
>   05  2 26 22 19 44.9990000  0  8G26G16G22G 6G21G29G18G15            -0.000499935
>   05  2 27 17 51 14.9990000  0  6G 2G10G 5G30G 9G 4                  -0.000499872
>   05  3  1 18 58 14.9990000  0  6G 2G10G 5G30G 6G 4                  -0.000499847
>   05  3  1 20 58 44.9990000  0  8G26G10G16G30G 6G21G29G18            -0.000499775
>   05  3  2  5  1 44.9990000  0  6G 1G20G23G11G25G14                  -0.000499878
>   05  3  3  9 57 44.9990000  0  8G10G 3G23G 8G28G19G13G27            -0.000499836
>   05  3  3 21 18 14.9990000  0  9G26G10G16G30G 6G21G29G18G15         -0.000499823
>   05  3  6  0 53 14.9990000  0  9G 1G 3G19G22G 9G21G18G15G14         -0.000499874
>   05  3  6  8 47 14.9990000  0  7G 3G23G 8G16G19G13G27               -0.000499760
>   05  3  8 21 57 44.9990000  0  8G26G16G22G 6G21G29G18G15            -0.000499813
> 
> (14 cases found -- same as you reported) and
> 
> [440] grep "\.001000" junk
> 
> (0 cases found -- maybe you see these from other dat files?)  Next,
> I used the parsing info in file "junk" to cut out a chunk of the
> dat file around the first ".999000" case:
> 
> [441] chop +64779974 -64787735 ANTE0422.05.dat > first.dat
> 
> (chop is a little C utility that I wrote; you can do the same thing
> with dd bs=1 skip=# and dd bs=1 count=# and some fiddling around)
> (I've attached the file first.dat (I hope) to this email.)
> Then I did a little modification to the teqc source to print out the
> reported receiver time directly from the dat file.  (In a dat file,
> this time is in milliseconds; I'm converting into seconds prior to
> printing):
> 
> [442] teqc +smtt +rx_clk_off -O.obs l1+l2+c1+p2 first.dat 2>&1 | more
> 
> and here is our problem epoch with the two epochs just before and after:
> 
>   05  8 18  9 57 15.0000000  0  8G10G 3G23G 8G28G19G13G27             0.000493299
>    -2956190.56249  -2288224.32046  23778114.8204   23778112.9734
>    -5857040.62149  -4546684.82047  22752907.2974   22752906.1564
>    -2687064.22749  -2074704.02747  22584311.5164   22584307.9614
>   -12972434.46549 -10088756.02347  21833569.1804   21833568.0824
>    -3761315.63349  -2907840.44547  23822894.9614   23822892.9494
>    -8158403.02749  -6338818.30147  22663243.4844   22663240.2734
>   -13719580.25049 -10672444.09448  20818371.4694   20818369.5354
>   -14583077.60249 -11345502.04748  21254671.3054   21254669.7464
> time= 381450.000000
>   05  8 18  9 57 30.0000000  0  8G10G 3G23G 8G28G19G13G27             0.000496731
>    -2968026.53549  -2297447.18747  23775862.1724   23775861.3444
>    -5839806.64549  -4533255.73847  22756186.0704   22756185.4264
>    -2634356.87549  -2033633.37547  22594341.8054   22594337.8634
>   -12997555.12149 -10108330.55547  21828788.9774   21828788.0864
>    -3802841.14549  -2940197.96147  23814992.3984   23814991.4414
>    -8172671.06649  -6349936.22347  22660528.8134   22660525.6054
>   -13689702.78949 -10649162.97348  20824056.6564   20824054.8284
>   -14591306.38349 -11351914.07848  21253105.0394   21253104.3674
> time= 381464.999000
>   05  8 18  9 57 44.9990000  0  8G10G 3G23G 8G28G19G13G27            -0.000499836
>    -4555144.48849  -3534162.44547  23473843.7344   23473843.3524
>    -7397847.30949  -5747313.39847  22459701.3054   22459700.8284
>    -4156996.97749  -3220106.18047  22304592.9454   22304589.2734
>   -14598052.98449 -11355471.73847  21524224.1884   21524223.5394
>    -5419737.66849  -4200117.33647  23507307.3444   23507305.8134
>    -9762235.49249  -7588557.84447  22358044.4534   22358041.7034
>   -15235125.61749 -11853388.55148  20529972.1884   20529970.6174
>   -16174914.14849 -12585894.14848  20951754.9534   20951753.5394
> time= 381480.000000
>   05  8 18  9 58  0.0000000  0  8G10G 3G23G 8G28G19G13G27            -0.000496405
>    -4566705.74649  -3543171.22347  23471643.8754   23471642.4574
>    -7380322.21949  -5733657.47747  22463036.3914   22463035.3014
>    -4104141.93449  -3178920.44547  22314650.9224   22314647.4844
>   -14623090.23449 -11374981.26647  21519459.6024   21519458.9264
>    -5461168.59049  -4232401.15247  23499423.1024   23499421.8284
>    -9776257.92649  -7599484.41047  22355376.3284   22355373.3594
>   -15205007.54349 -11829919.93048  20535703.5634   20535701.6174
>   -16183062.09049 -12592243.18748  20950204.3204   20950203.2424
> time= 381495.000000
>   05  8 18  9 58 15.0000000  0  8G10G 3G23G 8G28G19G13G27            -0.000492971
>    -4578128.28949  -3552071.89846  23469470.1024   23469468.3714
>    -7362653.32849  -5719889.51247  22466397.8444   22466398.3284
>    -4051218.55549  -3137681.45747  22324721.7344   22324718.0004
>   -14648083.06249 -11394456.19147  21514704.1804   21514702.7734
>    -5502547.71149  -4264644.60947  23491549.7974   23491548.1684
>    -9790155.80549  -7610313.91047  22352731.3594   22352728.1524
>   -15174772.16049 -11806359.89548  20541457.1804   20541455.4384
>   -16191168.54349 -12598559.91048  20948661.5394   20948660.8554
> 
> So you can see that the receive time reported in the dat file is
> _not_ on an integer second (as it should be), and that teqc is
> doing exactly the right time with +smtt: giving us the reported
> receiver time exactly as it is in the data file. (We also see the
> ~1 ms jump in the phase and pseudorange values as expected with
> +smtt when a millisecond receiver clock reset occurs.)
> 
> I feel vindicated -- `teqc +smtt` is doing exactly what it should
> in this case; my current opinion is that this is an issue with the
> 5700 firmware ( NP 2.10 / SP 0.00).  Maybe someone from Trimble
> should take a look.  (Brian Frohring?)
> 
> --lou
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> teqc mailing list
> teqc at ls.unavco.org
> http://ls.unavco.org/mailman/listinfo/teqc


More information about the teqc mailing list