[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