[teqc] teqc decimation on rinex files
lou at unavco.org
Thu Sep 9 08:24:54 MDT 2004
Whatever behavior teqc has is probably independent of the build
(Linux, Solaris, Windows, etc.) and what is being described goes
back at least 4 or 5 years. The algorithm for the decimation
needs to know both the original sample interval and the decimation
interval. For original intervals > 1 sec, the original interval
can be successfully extracted from the data (most of the time),
thus specifying -O.int with the original interval is usually not
required, but it doesn't hurt if it is included. (Thus Teresa's
For original intervals <= 1 second, you _may_ have to specify the
original interval using -O.int to get the "expected" decimation.
(Thus Jeff's recommendation to include -O.int.) If you don't, there
is a chance that the two intervals will be end up getting set to
the same value by teqc, and when that happens you get the "unexpected"
decimation pattern (first epoch, following epochs at intervals specified
by -O.dec; e.g. 22, 52, 22, 52, ...). BTW, the same thing happens if you
force the same value with both -O.int and -O.dec (e.g. original interval
is 1 sec, and you use -O.int 30 -O.dec 30). Sometimes, though,
you get the expected decimation with original intervals <= 1 sec by
just using -O.dec (as Marcin observes).
The safest method is to use:
-O.int <original_interval> -O.dec <decimation_interval>
to get the "expected" decimation on the epochs, since this
requires the least automagic parameter determination by teqc,
though (again) the -O.int part is hardly ever needed if the
original interval > 1 sec.
> I met the problem months ago but left it unsolved. So I was glad to see
> the solution however it didn't fit to my understanding of '-O.int' which,
> I thought, affects only the RINEX header. I tried to decimate my files,
> and now I'm double confused. It seems to be no problem!
> I prepared 1s RINEX starting at second 22 and tried to decimate it
> to 30s RINEX. The only option applied was '-O.dec 30' (no '-O.st',
> no '-O.int'), and the result 30, 0, 30, 0, ... (not 22, 52, 22, 52, ...).
> There were no problems with '-O.dec 5' too (25, 30, 35, ...).
> I use teqc 2002Mar14 release, under both W2K and Linux works the
> same. What your teqc version? Wasn't it corrected?
> Marcin Sekowski
> Institute of Geodesy and Cartography
> Warszawa, Poland
> msek at igik.edu.pl
>>Yes that does work, and the command still works on input rinex files
>>that happen to be 5 sec or 30 seconds as well so I wont need to have a
>>special teqc call just for the 1 second files, and that is a relief.
>>Jeff Freymueller wrote:
>>>I believe you just need to add -O.int 1 to your command line. This, I
>>>think, tells teqc that the input data interval is 1 second, and this
>>>makes it realize that it should be decimating to 0 and 30 seconds. The
>>>reason is not very intuitive to me but I know this works.
>>>Dr. Jeffrey T. Freymueller Office: 907-474-7286
>>>Geophysical Institute Fax: 907-474-7290
>>>University of Alaska, Fairbanks Home: 907-479-3550
>>>PO Box 757320 Cell: 907-322-7632
>>>Fairbanks, AK 99775-7320 email: jeff at giseis.alaska.edu
>>>Download Alaska GPS data: ftp://fairweather.giseis.alaska.edu/pub/gpsdata/
>>teqc mailing list
>>teqc at ls.unavco.org
> teqc mailing list
> teqc at ls.unavco.org
More information about the teqc