[teqc] Different times in rinex files if combined than if separate
Lou Estey
lou at unavco.org
Mon Aug 7 08:16:13 MDT 2006
The problem identified (an extra week increment during translation
of Trimble .dat and .mes files where one or more of the .dat files
start during the next week) goes back a long time. I've tested
earlier versions (e.g. 14 Mar 2002, 29 Feb 2000, 1 Jul 1998)
and they all have essentially the same problem. Jack deserves some
sort of prize for discovering and reporting this one!
At any rate, I have a fix in place, so using the .dat and .mes files
that Jack was reporting about, now:
[1429] ls *.[dm]??
39320381.dat 39320381.mes 39320382.dat 39320382.mes 39320390.dat 39320390.mes
[1430] teqc +mds *.dat 2> /dev/null
2004-02-07 12:32:30 2004-02-07 12:44:00 41889 39320381.dat
2004-02-07 12:49:30 2004-02-07 23:59:45 1719171 39320382.dat
2004-02-08 00:00:00 2004-02-08 08:26:30 1272415 39320390.dat
[1431] teqc *.dat > tmp.obs 2> /dev/null; teqc +mds tmp.obs
2004-02-07 12:32:30 2004-02-08 08:26:30 3460268 tmp.obs
[1432] teqc +ver
executable: teqc
version: teqc 2006Aug5
build: Solaris 5.9|UltraSparc IIi|cc -xarch=v9 SC5.5|=+-|*Sparc
--lou
> When the target *.dat files have a week rollover, we've discovered
> that:
>
> [1390] teqc +meta *.dat | grep date
> [1391] teqc *.dat > tmp.obs; teqc +meta tmp.obs | grep date
>
> results in the same end date/time for the last .dat file and the
> rinex file -- as long as only the .mes file for the first .dat is
> present, but including the .mes file for the data of the 1st day of
> the second week is what causes the double increment of the week value.
>
> I suspect this has been a latent bug for some time, and I'll be
> working on a fix.
>
> --lou
>
>> Jack,
>>
>> Another person on the list pointed out that you were probably asking
>> about the date (yr-mon-day) and not the time (hr-min-sec) on the final
>> RINEX file, since the raw data showed:
>>
>> 2004-02-07
>> 2004-02-07
>> 2004-02-08
>>
>> and the RINEX started on the 7th, but shows the end to be on the 15th.
>> (My bad. Sorry, a case of me focusing on describing moss on the trees
>> instead
>> of noticing the forest burning down.)
>>
>> Anyway, _that_ part of what teqc did is wrong. Obviously, this is
>> related
>> to the transition of the 7th to the 8th in Feb 2004 being a week
>> rollover,
>> and teqc switched to a week later than it should have.
>>
>> Two questions:
>>
>> Do you get get the epochs for the 8th of the 3rd .dat file incorrectly
>> being
>> translated as being on the 15th if you use "+smtt" during the
>> translation?
>>
>> What version of teqc are you using? (`teqc +id`) If you're not using
>> the
>> latest (20 July 2006), could you get the latest at
>> http://facility.unavco.org/software/teqc/teqc.html#executables
>> and try it and see if it shows the same problem?
>>
>> cheers,
>> --lou
>>
>>> Jack,
>>>
>>> The short answer is: that's what should happen!
>>>
>>> The time tags in a RINEX file are in receiver time, synched to GPS time
>>> at the start (by convention). Handling of receiver millisecond resets,
>>> which are typical e.g. in Trimble and Ashtech receivers, can be handled
>>> in one of two ways:
>>>
>>> a) ms jumps in time tag, smooth phase and pseudorange (rx time
>>> not necessarily = GPS time, except at the start by convention)
>>> or
>>> b) smooth time tag, ms (equivalent) jumps in phase and pseudorange
>>> (rx time = GPS time)
>>>
>>> Either style is equally valid under the RINEX specification, though
>>> many translators in the early days produced only style (a).
>>>
>>> Clockprep, for example, converts RINEX style (a) into RINEX style (b).
>>> The other way you can control style is with the smtt option of teqc.
>>> By default, teqc uses "-smtt" == "not smooth time tag", i.e. style (a)
>>> (-- for all teqc versions up to now and still current, though
>>> I am probably going to change this soon) Using "+smtt" gives style (b).
>>>
>>> So, executing `teqc +meta <whatever>.dat` on each Trimble .dat file
>>> starts off with rx time = GPS time but drifts due to accumulated
>>> millisecond resets in the file. If you instead execute
>>> `teqc +smtt +meta <whatever>.dat`, you would see the end times on
>>> your files are:
>>>
>>> final date & time: 2004-02-07 12:44:00.000
>>> final date & time: 2004-02-07 23:59:45.000
>>> final date & time: 2004-02-08 08:26:30.000
>>>
>>> During a translate on raw data files to RINEX, teqc (-smtt) keeps
>>> the accumulated millisecond resets intact when moving from one raw
>>> file to the next, so your style (a) RINEX file has 199 ms resets
>>> from GPS time resulting in the final receiver time of 08:26:29.801.
>>> (If teqc didn't do this, there would be huge time, phase, and
>>> pseudorange
>>> jumps at the boundaries of the input .dat files.)
>>>
>>> If, instead, you translate with +smtt -- resulting in style (b) RINEX --
>>> the final time will be 08:26:30.000 (GPS time == rx time), which matches
>>> what you'd see above with `teqc +smtt +meta <whatever>.dat` on the
>>> last .dat file.
>>>
>>> A good question. Hope this helps!
>>>
>>> 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
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>>
>>>> Why am I getting different results when running teqc
>>>>
>>>> (a) on three files separately to generate three rinex files
>>>>
>>>> vs
>>>>
>>>> (b) on the three files together to generate one rinex file?
>>>>
>>>> I have three .dat files from a Trimble 5700 receiver. teqc +meta
>>>> tells me the times are consecutive, with a short break between the
>>>> first 2:
>>>>
>>>> tcsh: teqc +meta JAR1/39320381.dat
>>>> ! Notice ! GPS week initially set= 1256
>>>> filename: JAR1/39320381.dat
>>>> file format: Trimble .dat
>>>> file size (bytes): 41889
>>>> start date & time: 2004-02-07 12:32:30.000
>>>> final date & time: 2004-02-07 12:43:59.998
>>>>
>>>> tcsh: teqc +meta JAR1/39320382.dat
>>>> ! Notice ! GPS week initially set= 1256
>>>> filename: JAR1/39320382.dat
>>>> file format: Trimble .dat
>>>> file size (bytes): 1719171
>>>> start date & time: 2004-02-07 12:49:30.000
>>>> final date & time: 2004-02-07 23:59:44.882
>>>>
>>>> tcsh: teqc +meta JAR1/39320390.dat
>>>> ! Notice ! GPS week in Trimble Record 21/55h = 1256; (default) GPS
>>>> week = 1257
>>>> ! Notice ! GPS week initially set= 1257
>>>> filename: JAR1/39320390.dat
>>>> file format: Trimble .dat
>>>> file size (bytes): 1272415
>>>> start date & time: 2004-02-08 00:00:00.000
>>>> final date & time: 2004-02-08 08:26:29.921
>>>> sample interval: 15.0000
>>>>
>>>> If I run teqc separately on the three files to generate rinex files,
>>>> the times in the rinex files agree with the times above. However, if
>>>> I try <to generate a single rinex file, using
>>>>
>>>> teqc -O.int 15 -O.at "TRM22020.00+GP" -tr d +obs jar1038a.04o \
>>>> JAR1/39320381.dat JAR1/39320382.dat JAR1/39320390.dat
>>>>
>>>> the following lines show up in the middle of the file, where the day
>>>> changes, and the times from the last file are shifted from 2/8 to 2/14:
>>>>
>>>> 04 2 7 23 59 44.8800000 0 12G 6G 2G24G10G29G27G16G 8G13G17G21G26
>>>> -54146557.39547 -42177446.79545 -13116597.0694 -13116602.5974
>>>> 2414.5164
>>>> :
>>>> :
>>>> 04 2 14 23 59 59.8800000 4 1
>>>> END OF STATIC OBSERVATION COMMENT
>>>> 04 2 14 23 59 59.8800000 0 12G 6G 2G24G10G29G27G16G 8G13G17G21G26
>>>> -54182718.82847 -42205624.56645 -13123478.7334 -13123483.7764
>>>> 2406.5474
>>>>
>>>> The last epoch in the file is
>>>> 04 2 15 8 26 29.8010000 0 9G14G25G30G 4G 6G20G24G 5G 1
>>>>
>>>> Jack Saba
More information about the teqc
mailing list