[teqc] Problem with tecq +smtt

Lou Estey lou at unavco.org
Sat Aug 20 11:13:55 MDT 2005


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: first.dat
Type: application/octet-stream
Size: 7761 bytes
Desc: 
Url : http://ls.unavco.org/pipermail/teqc/attachments/20050820/e9341c22/first.obj


More information about the teqc mailing list