Contact: UNAVCO teqc guru
Last modified: 26 July 200t

Question 1:

What documentation exists for teqc?

Answer:

There is an HTML tutorial. Execute

	teqc ++sym

for a table of the symbols now used in the ASCII time plot.

A detailed log of changes can be found at /software/teqc/log.html.

The main differences over time have been translator enhancements for reading/translating various native receiver formats. All formats should work equally well on little-endian processors (e.g. Intel, Athalon, etc. used in PCs e.g. for Solaris x86, Linux x86, Microsoft Windows) and on big-endian processors (Solaris Sparc, HP PA-RISC, Mac, SGI, etc. used in most UNIX systems).

You may also run across the occasional RINEX file with "v2" as the program name, which was a very early debugging version of teqc (circa 1996, early 1997), or the pre-teqc release name "rt".

Question 2:

Where do I find the teqc source code? Or executables?

Answer:

The UNAVCO Facility does not make the teqc source code available, except in special circumstances usually requiring a non-disclosure agreement.

You can find a listing of links to executables for most computer platforms at /software/teqc/teqc.html#executables.

Question 3:

I execute

	teqc

and it doesn't ask me any questions. It just tells me what GPS week it currently is and prints out some other seemingly meaningless stuff. When do I get to input the input file?

Answer:

teqc is completely 100% non-interactive. Almost all the information it uses to run is supplied on the command line, the exception being information supplied in the environment variables $teqc_OPT, $teqc_CONFIG, and/or $teqc_PATH, which are automatically examined after execution of teqc has started. (If these have not been set yet, then all the information is via the command line.) Any "input" files are supplied on the command line or in these environment variables.

Executing just

teqc

does, it fact, return the current GPS week based on your computer system's time.

Some people are expecting a help menu when they type teqc. Instead, this is obtained by executing:

teqc +help

or

teqc -help

Question 4:

I'm using a PC with Microsoft DOS (or Microsoft DOS emulation). Certain teqc goes to stderr, and I can't figure out how to save this as a file. How do I do it?

Answer:

To make up for the shortcoming in certain shells (including UNIX C-shell csh) where separate redirection of stdout and stderr is difficult or not allowed, teqc has built in capabilities for doing this using the options +err, ++err, +out, and ++out which you should investigate further in the documentation. In short, to capture the stderr as a file, execute:

teqc +err my_help_file {rest of options}

and the stderr information will be written to the file my_help_file. Just make sure your +err option is the first thing on the command line; otherwise, any messages going to stderr before this will still go to the screen.

Question 5:

What's going on with all these +'s and -'s on the command line options? Why not just use - like the rest of UNIX? Is there a difference?

Answer:

Many of the options used by teqc have two states: either used to turn something off or on, or used to input or output something. In order to keep the total number of flags (option names) to a minimum, each flag might be proceeded by a - or a +:

• - means you want to turn an option off; or you are inputting something, like a file
• + means you want to turn an option on; or you are outputting something, like a file

Examining the results of teqc +help should help clarify the meanings, and will show you the default settings of various options in teqc. If you do not find a - or + differentiation in the help, then either sign should work, like for obtaining help itself.

Question 6:

I am trying to translate the Trimble DAT file foobar.dat into RINEX using teqc and it keeps erasing the DAT file and not producing any output in the RINEX file. The command line I am using is:

teqc -tr d +nav foobar.dat > foobar.97o

Answer:

(An aside and the best general complaint about UNIX I ever heard, though the same thing applies for command-line Microsoft DOS in this instance: "UNIX not only allows you to shoot yourself in the foot, but it gives you an automatic weapon and a couple of loaded clips as well." Moral: Think before you pull the trigger.) Some user errors can't be detected by software until it's too late. This is may be one of those cases. The correct command line is:

teqc -tr d +nav foobar.97n foobar.dat > foobar.97o

The +nav option always takes an argument (the intended name of RINEX NAV file) which immediately follows on the command line. What happened in the "incorrect" (i.e. unintentional) command line is that teqc grabbed the name of the target DAT file as this name, reopened the file, thus clobbering the contents of the original foobar.dat. teqc then had no target files or stdin to process, so the intended RINEX OBS file foobar.97o was empty.

Procedures are implimented in teqc to at least inform the user that output files of options +obs, +nav, or +met are being rewritten under similar situations.

Question 7:

When I use Trimble's r-ulitities to convert my downloaded r00 files, I get DAT, MES, EPH, and ION files. Can I use teqc to directly translate the r00 files? If not, do I need anything besides the DAT files when using teqc?

Answer:

The Trimble format for the r00 files is proprietary, so you must use Trimble software to convert them into some other form. teqc can read the resulting binary Trimble DAT format.

You need not supply anything besides the DAT file. However, if the corresponding MES file exists in the directory, it will be read first to extract certain metadata. The most important of these pieces of metadata is the GPS week of the first observation epoch. Surprisingly, this information is not necessarily in the DAT file. Even more problematical, sometimes the necessary record is present containing a valid GPS week value, but the value is wrong (and usually this is GPS week 0, which is a valid, but unlikely, GPS week).

Question 8:

teqc can't determine the correct GPS week from the native binary file I have. What do I do?

Answer:

Reasonable attempts are made by teqc to establish the GPS week number for all native binary formats, but sometimes these attempts fail. You can always explicitly set the GPS week by using the -week option with one of three argument formats: 1) GPS week number by itself, 2) year:day_of_year, or 3) year:month:day. You can use a ':' (colon) delimiter or a '/' (slash) delimiter for 2) or 3). Sometimes you will get a hint about the correct GPS week from a mismatch between what teqc thought was the GPS week and ephemeris information in the file.

Question 9:

Now that I have my RINEX files resulting from translation from native binary format by teqc, I've been comparing them with the RINEX files produced by other translators, and they are not the same. What are the differences? Can I change the observables that are listed in a RINEX OBS or MET file?

Answer:

The most noticable difference may be the order and types of observables in the RINEX OBS file. By default, teqc now spews 7 observables when doing a translation from a native binary format with a dual-frequency, P-code, full-wavelength receiver:

L1, L2, C1, P2, P1, D1, and D2.

(Earlier versions of teqc--or the alpha version rt--spewed 9 observables by default with the following order:

C1, L1, L2, P1, P2, D1, D2, S1, and S2.)

At least the first five should be familiar to you--the pseudoranges and the phase values of L1 and L2. D1 and D2 are the Doppler values of L1 and L2, respectively, in Hz. S1 and S2 are signal-to-noise values reported by the receiver, but are not part of the official RINEX version 1 or 2 specification. If you do not want this set of observables in your RINEX files, you can use the -O.obs option to set the observables you want in the order you want them. For example:

teqc -tr d -O.obs l1+L2+ca+P2+P1 foobar.dat > foobar.97o

will give you the observables L1, L2, C1, P2, and P1 in that order. (Notice that the observable names for the -O.obs option are not case-sensitive and that CA = C1.) The above order for the observables is actually a desirable order for the first five observables if A/S is on for most SVs, since the C/A-code pseudorange will be reported instead of the P1-code pseudorange, the P1 observable in the RINEX OBS file will be empty for most SVs for many formats, and therefore your RINEX OBS file will generally be smaller in overall byte-size than if you had used -O.obs l1+l2+c1+p1+p2.

You can also alter the observables from an existing RINEX OBS (or MET) file. Suppose you had executed:

teqc -tr d foobar.dat > temp.97o

You can still get just the observables you want by now executing:

teqc -O.obs l1+l2+ca+p2+p1 temp.97o > foobar.97o

The next most-often-noted difference may be the LLI flag (0-7) and the SNR number (0-9) which immediately follow each observation value. These numbers, if non-zero, look like they are the "fourth" and "fifth" decimal place values of the observation values (zero values can be given as "0" or " " [blank]). The LLI flag actually contains up to three pieces of information:

1. bit-0 (1) loss-of-lock for this SV and this frequency (L1 or L2) (original meaning of the LLI flag)
2. bit-1 (2) switch wavelength factor to opposite of last WAVELENGTH FACT L1/2 record setting for this SV and this frequency (L1 or L2)
3. bit-2 (4) Anti-spoofing (A/S) is on for this SV
   OR
   bit-2 (4) some other signal degradation/noise enhancement in effect

Unfortunately, the RINEX version 2 specification is ambiguous as to which observable should get what kind of LLI flag. The translation in teqc takes this approach:

1. bit-0 (1) is applied only to the L1 or L2 observations, as appropriate, for the specific SV
2. bit-1 (2) is applied only to the L1 or L2 observations if L1 or L2, respectively, is observed in a squaring (half-wavelength) mode for the specific SV
3. bit-2 (4) is applied to all observations for that SV

What other translators do is a bit problematical.

The teqc algorithm used for setting the SNR (0-9) value may follow the Berne piece-wise linear algorithm used in the Berne translators, or some other algorithm. An approximate map is supplied as comments in the RINEX header.

teqc uses a simplified subset of RINEX possibilities when reporting the wavelength factors for L1 and L2 for SVs. There will only be the default WAVELENGTH FACT L1/2 header record with possible values sets of "1 1" (dual-frequency receiver) or "1 0" (L1-only receiver). Squared (half-wavelength) L1 or L2 observations are only reported using bit-1 of the LLI flag.

The RINEX version 2 specification does not say how to report each observation value with regards to least-significant decimal place. Is the observation value chopped or rounded? teqc internally rounds each value to the least-significant decimal place using the C library floor() function. What other translators do here is problematical.

In RINEX NAV files, you may notice that teqc translations yield an extra least-significant decimal place when compared to translating the same native binary file with some other translators. The resulting format is consistent with the RINEX version 2 specification.

Question 10:

I have a RINEX file another.97o produced by another translator and executed:

teqc another.97o > temp.97o

diff another.97o temp.97o 

I see no differences except for the PGM / RUN BY / DATE line and a few COMMENT lines, but the UNIX diff says that there are other differences. What's going on?

Answer:

If the differences are not in the printable characters that you would normally see, the differences are probably in the whitespace characters that you don't normally see but that diff does see. There are three general possibilities:

(1) teqc, during the creation of temp.97o (a reformatting subset of the editing mode), leaves off extra spaces at the end of observation lines by performing a space cleanup from the right to the right-most printable character or the beginning of the line, whichever comes first. This is valid RINEX version 2, and generally results in smaller files.

(2) If right-most spaces are not the difference, then it might be the end-of-line characters. At the end of "ASCII" lines, for example, UNIX uses a newline ('\n' = CTRL J = 0x0a), MacIntosh uses a carriage return ('\r' = CTRL M = 0x0d), and Microsoft DOS uses a carriage return followed by a newline. For example, if another.97o were originally created on a MS DOS system and you are doing the above commands on a UNIX system, the file temp.97o will only have lines terminated in a newline.

(3) If right-most spaces and end-of-line characters are not the difference, then it might be the end-of-file characters. Some Microsoft DOS-created files end in MS DOS end-of-file (CTRL Z = 0x1a). If files ending in CTRL Z are then read and written with certain editors (e.g., certain vi versions), an additional carriage return and newline pair (0x0d 0x0a) are appended to the file!

These latter two problems highlight one of the illusions of RINEX: there is no such thing as a portable ASCII file. A good RINEX reader essentially has to treat a RINEX file like a binary file, since there is no telling where it came from and how it was sent to the computer you are using and who did what to it along the way.

Question 11:

I have what is supposed to be a RINEX file and it looks like a RINEX file to me, but teqc doesn't seem to be able to read it. What's the problem?

Answer:

First, see point (2) in the previous answer. This may be an end-of-line situation that the teqc author has not seen yet. Forward the RINEX file to UNAVCO, along with as much information as possible about where the file came from and how it was sent to you and the various OSs and protocols along the way. All reasonable efforts will be made to correct this type of teqc RINEX reading problem.

Second, your RINEX file may have new RINEX features in it the recognition of which have not been incorporated into teqc. This occurred for a while following the introduction of the SENSOR MOD/TYPE/ACC and SENSOR POS XYZ/H header lines in RINEX MET files and the specification of GLONASS RINEX NAV files, officially introduced into the RINEX specification in April 1997. (The first official release of teqc was also in April 1997!)

Third, teqc may be complaining about some type of formatting being used this "RINEX" file which is not valid. A common example is extra blank lines were there shouldn't be any. Basically, if you have a supposed RINEX file which has "features" in it (like extra blank lines) which are not specified in the RINEX specification, then these features probably shouldn't be there, and therefore you don't really have a valid RINEX file. Some of these types of "features" (like extra blank lines) can be ignored with teqc by using the +relax option.

Question 12:

I have RINEX files foobar.97o and foobar.97n, I'd like to qc ("quality check") them. How do I do this with teqc? What options should I set?

Answer:

At a minimum, execute:

teqc +qc foobar.97o

This will use all the default settings of the qc mode (qc settings via the environment variables $teqc_OPT and $teqc_CONFIG not withstanding), which have been set to what most users probably want most of the time. If the RINEX NAV file foobar.97n is in the same directory as the RINEX OBS file foobar.97o, it is automatically located and loaded for ephemeris information.

A short qc report will go to stdout (about one page), so this can be captured using:

teqc +qc foobar.97o > foobar.qc

Two other sets of files are automatically created by default. One is the qc report file, which will always end in .YYS where YY is the last two digits of the year when the OBS data start. The first part of the qc report file is the short report segment, which is identical to what is sent to stdout. This segment can be suppressed by using the -short option. The second part of the qc report file is the long report segment. This segment can be suppressed by using the -long option. The entire report file can be suppressed by using the -report option.

The other files which are automatically created by default are the plot file(s). Currently, these are generally the same type of COMPACT format as used in the plot files produced by the original QC program and follow the same naming convention. All the plot files can be suppressed by using the -plot option.

The other option that users may want to consider changing is the elevation mask (or cutoff) angle for satellites. By default this is set to be 10 degrees above the local horizontal plane. (Why not the "horizon"? More about this next.) Use the -set_mask option to change the local mask angle (in degrees).

An increasingly needed option is changing the horizon angle. If you are looking at data from a mountain top or from a satellite, you can make the elevation angle less than the default of 0 degrees. If you are looking at data from a volcano crater, you can make the elevation angle more than 0 degrees. Use the -set_hor option to change the local horizon angle. (Sorry--no azimuthally dependent horizon function is available yet. It's fixed at a constant value for all azimuths.)

So, if you don't want the short qc report segment, but do want the long qc report segment, but want the short qc report segment in a separate file foobar.qc, don't want any plot files, and want to change the elevation mask to 15 degrees, execute:

teqc +qc -s -plot -set_mask 15 foobar.97o > foobar.qc

To find out all the possible qc options and their settings, execute:

teqc +qc ++config

The two dozen or so options are the general teqc options available in all teqc modes. These are easily generated with just:

teqc ++config

Question 13:

When I'm using teqc's qc mode, what's the difference between qc-lite and qc-full?

Answer:

qc-lite means that no ephemeris information was pre-loaded with the -nav option and no native binary data is being input (which could contain ephemeris information), and therefore no antenna point-position calculation can be performed and no SV elevation or azimuth can be computed.

qc-full means either that ephemeris information was pre-loaded with the -nav option, or a native binary format was input (in which ephemeris information is likely to be present). However, a qc-full run always starts off internally as a qc-lite run and continues that way until the antenna point-position is made, at which point teqc switches to a qc-full mode for each SV for which there is ephemeris information. If there is no ephemeris information, that SV continues in a qc-lite mode until ephemeris information is encountered (when using a binary format) or until the end of the time window. If not enough information was present to perform a point-position calculation of the antenna, then the result is identical to a qc-lite run.

The idea is that the qc full>>>>>... indicator shows an intent to try and find an antenna point-position, if possible, and all the goodies that result once this is established. The qc lite>>>>>... indicator shows that no antenna point-position calculation is possible, due a complete lack of SV ephemerides.

Question 14:

Why doesn't teqc use the antenna position in the input RINEX OBS file, or in the input binary data, for a qc-full run?

Answer:

In general, teqc doesn't trust these values. Besides, the issue for a qc-full run is the presence of satellite ephemerides, not an estimate of the antenna position.

Question 15:

I have some RINEX files created by a translator (i.e. convertor) other than teqc, but teqc isn't reading them. It is complaining about missing header records. What's going on?

Answer:

By strict definition, you probably don't have RINEX files. teqc follows the document "RINEX: The Receiver Independent Exchange Format Version 2" available from the University of Berne, to the extent that the RINEX specification is unambiguous, with the exception of allowing observables S1, S2, and LC (aka L3). In the header description of each type of RINEX file (OBS, NAV, and MET), there is a unambiguous designation indicating whether a particular header record is optional or not. From the point of view of teqc, if your RINEX-like file is missing one or more of the non-optional header records, it is not RINEX version 2.

Granted, many of these "non-optional" header records are not really necessary for doing most operations. For example, about the only header records that teqc really needs for doing qc on an OBS-like file is:

# / TYPES OF OBSERV
WAVELENGTH FACT L1/2  [default and any others]

The rest of the records are pretty much ignored in qc mode. The point is that software has to draw the line somewhere, and the line here is the Berne RINEX version 2 definition. If you start bending the rules, then pretty soon you have to deal with reading /etc/passwd-like files as potential RINEX files.

You can determine if your RINEX-like foobar.x file is RINEX version 2 (and allowing observables S1, S2, and/or LC) by executing:

teqc +v foobar.x

teqc will let you know about each little thing it doesn't like about it, one at a time.

The +relax option allows teqc to read certain RINEX-like blobs of stuff (or even trying to treat /etc/passwd-like stuff like RINEX) and complain at some point where it doesn't understand what is in the file.

Question 16:

I have a bunch of RINEX OBS and NAV files. How do I qc all of them?

Answer:

What you do depends on exactly what you want to do. There are two general possibilities:

1. you want a qc on all the files taken as a single session, or
2. you want a qc on each OBS and NAV pair separately.

teqc +qc fbar03[4-6][0-1].97o

or if these are the only RINEX files in the directory:

teqc +qc *.97o

Recall that the NAV files are automatically located and read by teqc as long as the names are related to the OBS files.

Case 2) requires a separate execution of teqc for each RINEX pair, which is most easily done by creating a shell script (batch file for Microsoft DOS folks). The details of this script depend on the shell that you are using. An example of how to do this is given in the teqc tutorial using the Korn shell ksh.

Question 17:

I don't have a RINEX NAV file for my OBS data foobar.97o, but I do have a RINEX NAV file nearby.97n. Can I use this for qc-ing my data? If so, how?

Answer:

Easy. Execute:

teqc +qc -nav nearby.97n foobar.97o > foobar.qc

You have just done an explicit pre-load of a specific RINEX NAV file, in this case nearby.97n. If the RINEX NAV file foobar.97n had existed, it would have been read and used also.

Notice the sign on the -nav option: - means we are intending to input something, in this case an existing RINEX NAV file.

Question 18:

I executed:

teqc +nav nearby.97n +qc foobar.97o > foobar.qc

and now file nearby.97n is now empty and the qc run said "qc lite" instead of "qc full". What happened?

Answer:

(See aside on UNIX first.) Compare this command line with the one suggested in the previous answer. You gave teqc the command to rewrite nearby.97n with the +nav option which reopened the file, destroying the original contents. Then you gave teqc the command to start the qc mode with +qc. Since there was no input NAV file (following from the previous question where foobar.97n did not exist), the qc run was without ephemeris information, i.e. qc-lite.

If you had executed:

teqc +qc +nav nearby.97n foobar.97o > foobar.qc

thereby turning the qc mode on first, teqc would have detected a possible command line error and terminated before clobbering the existing nearby.97n.

Lesson: teqc does have some internal smarts to help users from clobbering themselves. When doing a qc mode, the +qc option should immediately follow teqc on the command line so that some of these smarts can be activated.

Question 19:

How do I interpret the teqc qc results?

Answer:

The short answer is: More or less like interpreting the results of the original UNAVCO QC qc results, or see the teqc tutorial on interpreting teqc's qc results. The main differences are in the symbols used in the ASCII time plot of the short report (stdout or short report segment of the qc report file) and some additions to the long report segment of the qc report showing multipath and signal-to-noise as a function of elevation angle if doing qc-full (i.e., with ephemeris information).

The differences in the ASCII time plot symbols are

• slips in MP1 are now represented by "1" (one)
• slips in MP2 are now represented by "2"
• gaps are no longer represented by "G" and/or "-", just "-"
(minus)
• "Y" is now "y" for A/S on with L1, L2, P1, and P2 observables present
• the symbol "m" has been added to indicate multipath slips in both MP1 and MP2 having a value near an integral value of milliseconds, but not the same value for all SVs at the observation epoch
• the symbol "^" has been added to indicate partial SV data when below the elevation mask
• the symbol "L" has been added to indicate a loss-of-lock for L1 or L2 reported by the receiver, but no other problems (this is only rarely, if ever, seen)
• the symbol "_" (underscore) has been added to indicate that the SV is above the horizon but below the elevation mask, but not being tracked; this can be turned off by using the -hor option
• the Clock line "Clk" nows shows whether the receiver clock is gaining time with "+" or losing time with "-" at the millisecond clocks resets
• missing epochs on the Clock line are shown with "^", though this symbol has a lower priority than either clock reset symbol

which are explained in more detail in the ASCII symbol hierarchy and the clock symbol hierarchy in the teqc tutorial.

Other differences are described in the teqc tutorial. In general, the seasoned user of the original QC should have very little trouble making the switch to the teqc qc mode.

Question 20:

I've heard that I can qc binary data directly with teqc without first translating to RINEX. Is this true?

Answer:

Absolutely, as long as the binary format is one of the native formats that teqc can read, and more capability for reading other native formats is being added all the time. There are two slightly annoying caveats, however:

(1) You must supply some information about the length of time for the binary data. Unlike ASCII RINEX OBS files, there is no sensible way to read the existing native binary formats backwards. Therefore, the only way for teqc to find out how long the observation session is would be to require a complete reading of the input, and then go back and do the qc mode during a second reading of the input. This is not possible if using stdin, and violates the teqc design requirement as a nominal one-pass filter (roughly, one full reading of any input file). Oddly enough, the length of the session time window is only needed for one thing in the teqc qc process: to determine the bin size of one ASCII character for the ASCII time plot. The easiest way to supply this information is with the +d (delta) option, as seen in the next example.

(2) The qc results you obtain from qc-ing a binary file may be slightly different than if you translate to RINEX and then qc the RINEX files. This has to do with the ephemeris information. When doing a qc of RINEX files, with one or more RINEX NAV files, the ephemeris information is read first so that an antenna point-position can be calculated as soon as possible. With native binary formats, the placement of ephemeris records in the data is generally non-deterministic. Therefore, it may take reading a significant portion of the data to accumulate enough ephemerides so that calculation of a point-position is possible, if at all.

There is a simple solution to this difficulty, however. You can pre-load an existing RINEX NAV file, say from the same site but the previous day, when doing the qc of a binary file. Then each SV will probably have an initial ephemeris for the position calculation (or, if not all, at least enough SVs will probably have initial ephemerides for the calculation).

So, the qc of the Trimble DAT file foobar.dat might look like:

teqc +qc -nav foobar_old.97n -tr d +dh 24 foobar.dat > foobar.qc

where the -nav foobar_old.97n is the preload of an existing RINEX NAV file foobar_old.97n and the +dh 24 is the total time window for the ASCII time plot (24 hours, in this case). The qc statistics, however, are only for the length of time for which there is data, up to the (in this case, 24 hour) cutoff of the window.

Question 21:

Can I translate to RINEX during the qc of binary data?

Answer:

Absolutely. For example, modify the command from the previous question to:

teqc +qc -nav foobar_old.97n -tr d +dh 24 +nav foobar.97n +obs foobar.97o foobar.dat > foobar.qc

where the +nav foobar.97n specifies the output RINEX NAV file, +obs foobar.97o specifies the output RINEX OBS file, and, if there were MET data, +met foobar.97m would specify the output RINEX MET file. Notice that instead of the RINEX OBS file going to stdout, now it is the qc short report. The rule is: If doing qc mode of teqc, stdout is always the qc short report. If doing a translation and a qc mode simultaneously, use the +obs option to extract the RINEX OBS file, if it is desired.

Question 22:

I seem to be able to do quite a bit with teqc, but some of my command lines are getting pretty long. Is there any way to avoid this?

Answer:

Absolutely. Time to learn about the environment variables $teqc_OPT, $teqc_CONFIG, and $teqc_PATH and configuration files in general, which are covered thoroughly in the teqc tutorial. In short, you can stuff your options into the environment variable $teqc_OPT, or into one or more ASCII files called configuration files, or use both. The environment variable $teqc_OPT is always looked for, and if it exists, its contents are read just like part of the command line. The environment variable $teqc_CONFIG can contain the names of one or more configuration files with options, which are used if $teqc_CONFIG exists and the configuration files listed in it exist and are readable. The $teqc_PATH environment variable can be used to specify one or more path prefixes to the config files, or the entire path can be used in $teqc_CONFIG. Furthermore, you can access one or more configuration files using the command line, say:

teqc -config config_file_1 -config config_file_2 foobar.dat > foobar.qc

or equivalently:

teqc -config config_file_1,config_file_2 foobar.dat > foobar.qc

There is a well-defined option hierarchy to which options take precedence over others in case of a conflict. Basically, the order is 1) left-to-right command line options, 2) left-to-right options in $teqc_OPT, 3) options encountered in left-to-right specified config files on the command line, and then 4) options encountered in specified config files in $teqc_CONFIG, using also $teqc_PATH. This option hierarchy is covered in more detail in the teqc tutorial.

Analogous to real estate, there are only three things to remember with teqc: flexibility, flexibility, and flexibility.

Question 23:

I've noticed that in RINEX files resulting from teqc translations from native binary formats that there is no version number for teqc in the PGM field, just a date stamp. Are there version numbers for teqc?

Answer:

The date stamp is the "version number". You can also execute:

teqc +id

or

teqc -id

to extract this information, plus the usual information about the GPS week. UNAVCO will maintain a log where you can find a reverse chronological list of changes, enhancements, bug fixes, etc. for teqc based on this date stamp and major teqc releases.

Question 24:

How can I make use of teqc for real-time data processing?

Answer:

teqc can be used to translate the real-time binary outputs of various receivers, like Trimble SSE or SSi, Ashtech Z-12, or TurboRouge receivers. To do this, the raw data from the receiver can either be stored in small data files of some desired length and then passed on to teqc to be translated into RINEX. Alternatively, on a multiprocessing operating system such as UNIX or Linux, the incoming binary data stream from the receiver can be piped into teqc, the output of which can be one or more RINEX files. teqc would have to be stopped and restarted to cleanly terminate each RINEX file set. The only special treatment for each execution of teqc is that it might need to be supplied with the correct GPS week, using the -week option, corresponding to the first epoch of the data stream, since some real-time formats do not include any information about the GPS week.

Comments or questions about this page? Send e-mail to Lou Estey (louunavco.org).

Last modified Monday, 25-Jun-2007 11:44:17 MDT

Home | About Us | Contact Us | Support | Search | Facility | PBO | Education & Outreach

Comments: webmasterunavco.org
© 2008 UNAVCO, Inc.