TEQC — Tutorial | UNAVCO Page 1 of 7

Time-Windowing with teqc

Section 13.

As mentioned above in Section 9, teqc always windows the input data (somewhere between 1 Jan 1980 and 31 Dec 6075), though this is
usually transparent to the user. There are eight different windowing strategies for you to be aware of; different information is supplied (or
not supplied) to use each of these different strategies.

The nomenclature in the following table is as follows. A bracketed value is one determined by teqc from the target files (i.e., implied),
whereas a non-bracketed value is explicitly supplied by the user (via a configuration option using the command line, $teqc_OPT,
$teqc_CONFIG, or another configuration file). start refers to the argument of the configuration option flag -st[art_window], delta refers to the
arguments of the configuration option flags +d... or -d..., and end refers to the argument of the configuration option flag -e[nd_window],
and dir refers to whether a + or - was used with the delta configuration flag. The eight different windowing options are:

1. [start] [end] (user supplies nothing except target files)

2. [start] delta (dir == +) e.g. +dh 7 for 7 hours from the start
3. delta [end] (dir == -) e.g. -dm 60 for 60 minutes from the end
4. start [end]
5. [start] end
6. start end
7. start delta (dir == + or -)
8. delta end (dir == + or -)

where the missing value is computed by teqc. Let's take a look at what these cases mean, and you'll see that this is really simplier than it
initially appears.

For case (1), probably the most common, the user supplies nothing but the list of target files. teqc then does a fast search of the target files
to be processed to determine the start and end times. If you input a file type for which a fast search algorithm has not yet been written or
use stdin as the target, then you must use explicit windowing (case (6), (7), or (8)). Currently, the fast search algorithm has been
implemented only for RINEX OBS, NAV, and MET files. The start time will be the first observation epoch or event epoch (RINEX OBS or MET
files) or the first TOE epoch (RINEX NAV files) in the first target file listed and the end time will be the last epoch in the last target file listed.
(As mentioned above, if your target files are not listed in a time-sequential order, or if one or more of your target files are not internally
time-sequential, something will run afoul later in the execution process and teqc will tell you about it.)

As an example, let's return to:

teqc +qc -nav fbar0010.97n fbar0010.97o fbar0020.97o fbar0030.97o

Here the target files to be processed are fbar00*0.97o. The fast search looks at the beginning of fbar0010.97o to determine the start time of
the window and looks at the end of fbar0030.97o to determine the end time of the window. No need you to worry about much of anything
here.

http://facility.unavco.org/software/teqc/tutorial.html 3/14/2012
TEQC — Tutorial | UNAVCO Page 2 of 7

For cases (2) and (3), the user supplies a +d... option or a -d... option with an argument. Currently, ... could be Y for years, M for months, d
for days, h for hours, m for minutes, or s for seconds. The leading + or - means "give me a positive time delta from the start" or "give me a
negative time delta from the end", respectively. Let's suppose, again, that the fbar00*0.97o files above are each 24-hours worth of data.
Then the configuration option +dh 6 together with the file fbar0010.97o would mean: "start at 00:00:00.0 1 Jan 1997 and end at 06:00:00.0
1 Jan 1997", i.e. a delta of +6 hours from the (implied) window start. The configuration option -dh 6 together with the file fbar0010.97o
would mean: "start at 18:00:00.0 3 Jan 1997 and end at 00:00:00.0 4 Jan 1997", i.e. a delta of -6 hours from the (implied) window end.

For cases (4) and (5), you supply explicitly either just a new partial or complete start time or just a partial or complete end time using the
configuration option flags -st or -e with an argument. The argument for a complete start or end time is easy to understand; it has the
format of [YY]YYMMddhhmmss[.sss...], though metacharacters like : (colon), , (comma), ; (semicolon), / (slash), \ (backslash), + (plus), -
(minus), = (equal), _ (underscore), ~ (tilda), # (pound) can be used to improve readability. I.e.

19970229105937
970229105937
970229105937.000000
1997-02-29_10:59:37

all mean "1997 Feb 29 10:59:37.000000", given that the base year is 1980 (see result of executing teqc ++config: base year of 1980 implies
that all two-digit years are assumed to occur from 1980-2079 A.D.) Note: Always be sure to include two digits for the month number, day
number, hour, minute, and second.

Let's suppose we return to our command

teqc +qc -nav fbar0010.97n fbar0010.97o fbar0020.97o fbar0030.97o

but want to start the time window at "1997 Jan 1 00:09:30.004". You could use the configuration option -st 970101000930.004 and things
will work fine, though a bit cumbersome. There is, in fact, another way to use the -st option by using the partial argument format (or
"masked" format), for example

-st 930.004
-st 9:30.004
-st 00:09:30.004

all of which are interpreted as the same thing: 9 minutes and 30.004 seconds. Here, teqc recognizes that you are suppling only a partial
start time (using minutes and seconds, in this case). It then gets the real start time as it would in case (1) or case (2) using the fast search
algorithm, and then applies a mask overlay to the start time and inserts your partial start time (changing just the minutes and seconds, in
this case). So the argument for -st or -e has a format closer to:

[[[[[[YY]YY]MM]dd]hh]mm]ss[.sss...]

In other words, it is assumed that you are supplying whole seconds, to which you can further specify decimal seconds if desired. Numbers to
the left of the seconds are interpreted as minutes, hours, and so on.

For cases (6), (7), and (8), you are explicitly assigning the window of interest, and, again, partial arguments can be used for the start and/or
end times. You can supply an explicit (partial or complete) start and end time, explicit (partial or complete) start time with a delta (a-la cases
(2) and (3)), or an explicit (partial or complete) end time with a delta.

http://facility.unavco.org/software/teqc/tutorial.html 3/14/2012
TEQC — Tutorial | UNAVCO Page 3 of 7

By using case (7), you can easily force your teqc processing to start at the same time of day and span the same length of time, regardless of
the start and end times of the input target files. For example, suppose you wish to have a start time of 00:00:00.0000000 at each day and
want exactly 24-hours worth of teqc processing. This is easily accomplished with something like

-st 00:00:00 +dh 24 .

The start and end times of the time window are both inclusive, i.e. these times are included in the window. Therefore, if in the preceeding
example you want to extract just short of 24 hours where the sampling interval is perhaps 30 seconds, then you could use

-st 00:00:00 +dm 1439.5

which would have a start time of 00:00:00.0000000 and an end time of 23:59:30.0000000.

You might think that just about every conceivable type of window possibility has been covered. Well, not quite yet. You can even introduce
holes in the overall time window during which you are not interested in anything. teqc skips over all input that occur during your specified
window holes, hole boundaries inclusive. Here the configuration option -hole followed by a file name is used. The file named is an ASCII file
listing the holes that you want in your time window. The format of the hole file for each window hole is always

[YY]YY MM dd hh mm ss[.sss] [YY]YY MM dd hh mm ss[.sss]

where only the presence of white-space as delimiters is needed. Thus, the file:

97 2 15 00 00 00 1997
2 15 03 00 00.00
97 2 15
06 00 00 97 2 15 09 00 00

is perfectly OK (though a little hard to read by humans). A more readable file (for humans) that does the same thing is:

97 2 15 00 00 00 97 2 15 03 00 00
97 2 15 06 00 00 97 2 15 09 00 00

Obviously, this is a listing of start and end times for each hole desired. How many holes can you list in a file? As many as you want (or until
computer memory is saturated). How many files do you get to name with the -hole option for each teqc run? Currently, one, so make sure it
includes all the holes you want for the execution. Also remember: each hole includes the exact start and stop time of the hole.

Time Binning with Option tbin

You can also invoke a time binning style of auto-windowing with option -tbin. The -tbin option is only available in versions of teqc made on
or after 18 July 2008.

This is a powerful option to create batches of RINEX or BINEX output files in various lengths, e.g. daily, 8-hour, hourly, 30-minute, 15-
minute, 5-minute, ..., from one or more input files (manufacturers' formats, RINEX, or BINEX, and as usual, the input files all have to be of
the same type). The -tbin option can create smaller output files than the input files (e.g. hourly files from daily files), and it also makes long
files from several shorter files. It can use mixed length input files. So, the input might be a list of files of varying lengths, some shorter than
a day, and the output could be binned into daily files.

http://facility.unavco.org/software/teqc/tutorial.html 3/14/2012
TEQC — Tutorial | UNAVCO Page 4 of 7

Two options are used for time binning. The first and required option is -tbin which has two arguments, such as -tbin 1h myfile. The first
and required argument, such as 1h, is the time duration for each bin (output file). The trailing letter specifies time units: s for seconds, m
for minutes, h for hours, d for days. You must use d, h, m, or s. Time durations in sub-seconds are allowed: if sub-seconds are indicated,
then resulting filenames will expand to include an additional ".ddd" after the seconds value showing the time down to milliseconds. Any value
for the time duration is allowed: caveat emptor! If you type 1s and the input data is most of a day long, you are asking for tens of thousands
of files to be made.

The second argument for -tbin, such as myfile, is the prefix part of the output filenames. The prefix can be a 4-char ID, or some other
printable string without whitespace.

The output filenames have the form <root> == prefix + doy-of-year, where the filenames themselves would be:

a) <root>0.yyo if delta (bin time duration) in days is an integer

b) <root>a.yyo - <root>x.yyo if case (a) doesn't work, but 24/(duration in hours) results in an integer hour, with the hour indicated by a
letter from a to x: a = start in hour 0, ..., x = start in hour 23

c) <root>[a-x]00.yyo - <root>[a-x]59.yyo if cases (a) and (b) don't work, but 60/(delta in minutes) results in an integer 00 = start in minute
0, ..., 59 = start in minute 59

d) <root>[a-x][00-59]00.yyo - <root>[a-x][00-59]59.yyo if cases (a)-(c) don't work, but 60/(delta in seconds) results in an integer (or maybe
all remaining cases as well ...) 00 = start in second 0, ..., 59 = start in second 59

In a teqc command like

teqc -tr d +obs + +nav + -tbin 1h mytbinfile inputdatafile

the extra bare + signs after +obs and +nav mean make a sequence of obs and nav files which match the 1 hour time bins made with the -
tbin 1h temp arguments. The + argument after the +obs and +nav options only has meaning when using the -tbin option. If you tried that
without -tbin you'd end up with a file named + .

The option +nav +,+ means make separate GPS and GLONASS nav files for the time bins.

For example, a command to translate from Trimble to RINEX

teqc -tr d +obs + +nav myfull.nav -tbin 1h myhourly grnr2600.dat

will put all the GPS nav messages into one file myfull.nav, but the RINEX obs are tbinned as hourly files:
teqc: creating file myhourly260a.97o ...
teqc: creating file myhourly260b.97o ...
teqc: creating file myhourly260c.97o ...

This example may be what you want if the tbin window is shorter than about 2-4 hours. Recall that the -tr d part is not required when the
input file is a Trimble DAT/ION/EPH/MES download fileset (dat file) file.

There is a second option, -ast, aligned start time, which may be used with -tbin to specify the start time of the first bin. This option is not
required for time binning. If no -ast option is specified, time binning uses a default alignment starting at 00:00:00 on the first data (obs,

http://facility.unavco.org/software/teqc/tutorial.html 3/14/2012
TEQC — Tutorial | UNAVCO Page 5 of 7

nav, or met). Option -ast - or -ast _ means start alignment to the first epoch that is output; -ast [[[[[[YY]YY]MM]DD]hh]mm]ss[.sssss] means
start alignment at the specified time. Sub-seconds may be used with -ast.

Note the common and different option -st is reserved to mean when to start the data, which by default is the first epoch found. Don't
confuse -ast and -st.

Option tbin works for all these cases:

n manufacturer's format or BINEX files -> m RINEX filesets

n RINEX files of same type -> m RINEX files of same type as input
n manufacturer's format or BINEX files -> m BINEX files
n RINEX filesets -> m BINEX files

The RINEX filenaming scheme with tbin is:

daily = 0.[onghem]
hourly = [a-x].[onghem]
minute = [a-x]00.[onghem] - [a-x]59.[onghem]
second = [a-x][00-59]00.[onghem] - [a-x][00-59]59.[onghem]
subsec = [a-x][00-59]00.000.[onghem] - [a-x][00-59]59.999.[onghem]

where

-- user supplied
== day of year
[a-x] for hours 00 - 23
== year modulo 100
[onghem] -- RINEX suffix, e.g. 'o' for RINEX obs file, etc.

Note that teqc should select the coarsest filenaming binning in order to do what you've asked. Which filenaming binning is used depends on
the -tbin unit selected or the -ast time unit. For example if using the default -ast (i.e. not explicitly specified) and using -tbin 30m test,
then the minute filenaming binning is used; but if -tbin 1h test or -tbin 60m test, then the hourly filenaming binning is used.

For creating RINEX with time-binning, you have pretty good control over which files end up being created with time-binned names; e.g.:

+nav temp.gps,temp.glo +obs + -tbin 1h temp == all GPS nav messages go into RINEX file temp.gps and all GLONASS nav messages go into
RINEX file temp.glo (in other words, neither are time binned), but all RINEX obs files are time-binned (to 1-hour in this case)

+nav +,temp.glo +obs + -tbin 60m temp == all GLONASS nav messages go into RINEX file temp.glo, but all RINEX GPS nav files and all
RINEX obs files are time-binned (again, to 1-hour)

+nav +,+ +obs + +met + -tbin 3600s temp == all RINEX (GPS and GLONASS nav, obs, and met) files are time-binned (and again, to 1-hour)

+tbin 3600s temp is a short-hand for the previous command (notice the + in +tbin), i.e., all RINEX files are time-binned.

The only difference to create time-binned BINEX is to use the +binex option (which takes its usual argument), and the resulting BINEX files
will be named differently from time-binned RINEX:

http://facility.unavco.org/software/teqc/tutorial.html 3/14/2012
TEQC — Tutorial | UNAVCO Page 6 of 7

<root> = prefix + GPS week + '_' + day_of_week (Sun=0,...,Sat=6)

daily = <root>.bnx
hourly = <root>[a-x].bnx
minute = <root>[a-x]00.bnx - <root>[a-x]59.bnx
second = <root>[a-x][00-59]00.bnx - <root>[a-x][00-59]59.bnx
subsec = <root>[a-x][00-59]00.ddd.bnx - <root>[a-x][00-59]59.ddd.bnx

Examples of tbin usage:

1) You want the input broken up into daily files and the created obs filenames to start with test:

teqc -tr d +obs + -tbin 1d test input.obs

If, say, the data started on day 2007:165, the output files would be named:
test1650.07o
test1660.07o
test1670.07o
test1670.07o
...
No nav files are made.

2) You want the input broken up into files of 1/12 sidereal days with filenames starting with sidx, and you want the first file to be time
aligned to 00h30m09s (GPS time, as usual) of the first day of data, and you want the data to start at 01h30m10s in the first file; use:

teqc -tr d +obs + -tbin 7180.3409 sidx -ast 00:30:09.000 -st 01:30:10 input.obs

If the data started on day 2007:165, then the output files would be named: sidx165a3009.07o (but data here doesn't start in file until
01:30:10)
sidx165c2950.07o
sidx165e2930.07o
...

Note that a sidereal day is 23h 56m 4.091s, so 1/12th is 7180.3409 seconds.

3) With an input of one Topcon TPS file, cp_1p.tps the command

teqc cp_1p.tps

translates the input to RINEX as a single stream to stdout. To create hourly time-binned RINEX obs files, and distinct nav files for GPS and
GLONASS, use:

teqc +nav +,+ +obs + -tbin 1h temp cp_1p.jps

creating temp027m.03n ...

creating temp027k.03o ...
creating temp027k.03g ...

http://facility.unavco.org/software/teqc/tutorial.html 3/14/2012
TEQC — Tutorial | UNAVCO Page 7 of 7

creating temp027l.03o ...

creating temp027l.03g ...
creating temp027o.03n ...
creating temp027m.03o ...
creating temp027m.03g ...

4) If you want the nav messages in a single RINEX nav file (temp0270.03n) for GPS and a single RINEX nav file (temp0270.03g) for GLONASS,
with time binning making 1 hour obs files:

teqc +nav temp0270.03n,temp0270.03g +obs + -tbin 1h temp cp_1p.jps

creating temp027k.03o ...

creating temp027l.03o ...
creating temp027m.03o ...
creating temp027n.03o ...
creating temp027o.03o ...
creating temp027p.03o ...

5) Use of the +tbin short-hand

teqc +tbin 1h mytbinfile grnr2600.dat

is a short-hand for

teqc +nav +,+ +obs + +met + -tbin 1h mytbinfile grnr2600.dat

Notice the +tbin instead of -tbin.

6) BINEX example with +tbin

teqc +binex 0x7f-03 +tbin 15m tmp input.obs

! Notice ! using RINEX OBS default observable list

! Notice ! using RINEX MET default observable list
teqc: creating file tmp1488_1a00.bnx ...
teqc: creating file tmp1488_1a15.bnx ...
teqc: creating file tmp1488_1a30.bnx ...
teqc: creating file tmp1488_1a45.bnx ...

The options +obs, +nav, or +met will not be required with the -tbin option in new versions of teqc, if the input target files are RINEX (but if
the input is more than one file, the input files still all have to be of the same type). This simplified command syntax choice will be in the
next full release after September 2009.

http://facility.unavco.org/software/teqc/tutorial.html 3/14/2012