UNAVCO Home UNAVCO Home
   |    |   |  
UNAVCO Home UNAVCO Facility

Software Remote PC Software RedHat Linux Auxiliary utilities Downloading & Data Transfer AOA Ashtech Trimble Other Pre-Processing TEQC Other Processing GAMIT/GLOBK Bernese GIPSY-OASIS II Trimble Geomatics (TGO) 		TEQC — Tutorial

Table of Contents

  • Section 1. -- Introduction: teqc
  • Section 2. -- UNAVCO World Wide Web Support & Contact
  • Section 3. -- Types of Data
  • Section 4. -- Basic Modes of Operation
  • Section 5. -- Operating Systems and Hardware
  • Section 6. -- Standard Input, Standard Output, and Standard Error
  • Section 7. -- General Concepts About Syntax
  • Section 8. -- Using teqc for RINEX Formatting & RINEX Format Verification
  • Section 9. -- Using teqc for RINEX Header Editing & Extraction; Introduction to Configuration Options and Files and the teqc Option Hierarchy
  • Section 10. -- Configuration Options and Command Line Options
  • Section 11. -- Using teqc for Quality Checking (qc) Mode
  • Section 12. -- Using teqc with Multiple File Input or File Names Including a , (comma)
  • Section 13. -- Time-Windowing with teqc
  • Section 14. -- Splicing with teqc
  • Section 15. -- Translating with teqc
  • Section 16. -- Special Translator Considerations and Options
  • Section 17. -- Wavelength Factors: What teqc Does With Them
  • Section 18. -- Basic Commands: A Review
  • Section 19. -- Using teqc in Scripts: Substitution for Batch Mode
  • Section 20. -- Differences Between teqc's qc Mode and Original UNAVCO QC
  • Section 21. -- Interpreting teqc's qc Mode Output
  • Section 22. -- "Strange" Behavior (i.e. Don't Panic)

Last modified: 8 Aug 2007

Introduction: teqc
Section 1.

This document describes and serves as a tutorial for the main features of teqc (pronounced "tek"). Although the capabilities of teqc extend beyond using just RINEX files, the most common type of data format that will probably be used by most users is the RINEX format, either as input, or output, or both. Consequently a shorthand for the three basic kinds of RINEX formats is used throughout this document:

  • OBS for RINEX observation data file,
    NAV for RINEX navigation message file,
    MET for RINEX meteorological data file.
Also, teqc currently handles RINEX version 1 and 2 files (through to version 2.10), though an attempt to edit a RINEX version 1 file will result in the automatic conversion to a RINEX version 2.XX (specifically 2.10) file.

If your primary interest is translating native binary formats to RINEX, go directly to the sections on translation (Section 15 and Section 16).

If your primary interest is editing, go directly to the section on metadata editing/extraction (Section 9), or RINEX formatting (Section 8), or windowing (cutting) (Section 13)/splicing (Section 14) operations.

If your primary interest is qc-ing RINEX or native binary data, go directly to the section on the qc mode (Section 11) of teqc.

UNAVCO World Wide Web Support & Contact
Section 2.

• Information about teqc.

• This tutorial document.

• FAQs ("frequently asked questions") on teqc.

• The teqc release log (including bug fixes for the next release).

• The teqc bug report.

• A listing of release notes for each official release, covering details which might not be in this tutorial.

• There is also a teqc email forum and email archive in place. You can search the teqc emails, or list the teqc emails either by date or by thread (email subject).

    To subscribe to the teqc email forum, email: 
     
	address--    To: teqc-requestunavco.org
	message--    subscribe
    To send a message to the teqc email forum: 
    	address--    To: teqcunavco.org
	subject--    Subject: <optional, but helps maintain threads>
	message--    <body of message; comments, bug reports, questions,
                     conundrums about teqc>
    To unsubscribe, email: 
     
	address--    To: teqc-requestunavco.org
	message--    unsubscribe

• Please contact teqc technical point of contact at UNAVCO for other questions, unresolved problems, or possible bug reports.

Types of Data
Section 3.



  • RINEX Data Files:
    • RINEX version 2.XX (2.10) files are the default type of files that teqc is expecting to process and/or produce. In order to have a valid RINEX version 2.XX file, the file must conform to the specifications in the document "RINEX: The Receiver Independent Exchange Format Version 2" available from the University of Berne (or see RINEX 2.10). A minimum set of header records must be present for each file. These are the non-optional header records specified in the RINEX version 2.10 document. (Note: There are no current plans for support of RINEX 3.00.)

    RINEX version 1 files can be read with teqc and are converted to RINEX version 2.10 files on output. Also, lowercase versions of the following header lines are recognized and converted to uppercase if output (e.g. rinex version / type is read and recognized and converted to RINEX VERSION / TYPE on RINEX output).

    Each RINEX OBS file must have a header with header lines (starting at the 61st character in the line) that end with: 
      RINEX VERSION / TYPE   (must be first line)
PGM / RUN BY / DATE
MARKER NAME
OBSERVER / AGENCY
REC # / TYPE / VERS
ANT # / TYPE
APPROX POSITION XYZ
ANTENNA: DELTA H/E/N
WAVELENGTH FACT L1/2   (default values)
# / TYPES OF OBSERV
TIME OF FIRST OBS
END OF HEADER          (must be last line of header for version 2.XX)
    where valid information (i.e., format version = 1, 2, or 2.XX; file type = 'O'; satellite system = ' ', 'G', 'R', 'S', 'T', or 'M') must be present in the first line, the number and types of observations must be specified on the # / TYPES OF OBSERV record line, and default values for the L1 and L2 wavelength factors must be given. The rest of the fields in other header records can be blank if a descriptor string is expected or have some numerical value if a numerical value (even if it is zero) is expected, but these other header lines must be present with or without non-blank information. Observation data usually follows the END OF HEADER header record. (Note that RINEX version 1 does not have a END OF HEADER field, but has a blank line instead.)

    Each RINEX NAV file must have a header with header lines (starting at the 61st character in the line) that end with: 
      RINEX VERSION / TYPE   (must be first line)
PGM / RUN BY / DATE
END OF HEADER          (must be last line of header for version 2.XX)
    where valid information (i.e., format version = 1, 2, or 2.XX; file type = 'N' for a GPS navigation message file, 'G' for a GLONASS navigation message file, 'H' for an SBAS navigation message file) must be present in the first line. Ephemeris data usually follows the END OF HEADER header record. (Note that RINEX version 1 does not have a END OF HEADER field, but has a blank line instead.)

    Each RINEX MET file must have a header with header lines (starting at the 61st character in the line) that end with: 
      RINEX VERSION / TYPE   (must be first line)
PGM / RUN BY / DATE
MARKER NAME
# / TYPES OF OBSERV
END OF HEADER          (must be last line of header for version 2.XX)
    where valid information (i.e., format version = 1, 2, or 2.XX; file type = 'M') must be present in the first line and the number and types of observations specified on # / TYPES OF OBSERV header record line. Meteorological data usually follows the END OF HEADER header record. (Note that RINEX version 1 does not have a END OF HEADER field, but has a blank line instead.)

  • Trimble *.dat Download Filesets:
    • Trimble *.dat files from the more recent receivers (series 4000 through to NetRS generation) are readable with teqc. Some *.dat data records have not been coded into teqc yet (e.g. the older GPS observable Records 0, 1, 2 and 7). However, teqc should be able to read the entire file and will report records which have not be coded yet.

    MES files are not required, but if they are present and you are using target file names (not stdin), then teqc will use the matching MES file for each target input file to help resolve certain metadata.

    The ION and EPH download files are not used by teqc.

  • Trimble RT17 Stream:
    • The Trimble RT17 format from Trimble 4000 SE/SSE/SSi and later receivers is readable with teqc. Currently, only the record 55h with ephemeris information and record 57h (GPS or MET observables) have been coded, though, again, teqc will report and skip other records.

  • Trimble Standard Interface Protocol (TSIP):
    • Minimal support.

  • Ashtech Download Files (B-, E-, S-, and D-files):
    • The Ashtech download file format from various Ashtech receivers (e.g., Z-12, Z-18, GG24, L-XII, LM_XII) is readable with teqc. Normally, the Ashtech "smoothing" of the pseudoranges in not applied, but can be turned on. The translation to RINEX should work correctly in cases where the B-file "version" is 3 or greater--which is the case for any recent Ashtech firmware. For translations where the version number of the B-file is 2 or less, the phase translation will be in error. (You can find the version number by using the teqc option +diag.)

  • Ashtech RS-232 (real-time) Stream:
    • The Ashtech RS-232 (real-time) binary data format from various Ashtech receivers (e.g., Z-18, Z-18, GG24, G-12) is readable with teqc. This includes the binary MBEN, PBEN, SNAV, and DBEN records. Like with the Ashtech download format, the Ashtech "smoothing" of the pseudoranges in not applied by default, but can be turned on.

  • Ashtech R-file:
    • An R-file format can be downloaded from some receivers, such as the Z-12, and this can be directly read by teqc.

  • Ashtech U-file:
    • An U-file format can be downloaded from the micro-Z receiver, and this can be directly read by teqc, including the new "data mode 7" format.

  • Leica LB2 Format:
    • Teqc can read the Leica LB2 format, used by the Leica MC1000, CRS1000, and CRS1500 and the later system 500 and 1200 receivers. The translations assume that only one antenna port on the receiver is being used.

  • Leica MDB Format:
    • Teqc can read the Leica MDB format from system 500 and 1200 receivers.

  • Leica DS Format:
    • Teqc can read the Leica 200/300 DS fileset format, used by the earlier Leica receivers, e.g. CR233, CR244, SR299, SR299E, SP299P, SR260, SR261, SR399, SR9500. The files with the suffixes .cmp, .dat, .eph, .int, .met, .obs, and .pnt will be used. The files with the other suffixes (e.g., .chn, .alm, .atf, and .at1) are currently ignored. (Note: Leica may have never implimented/supported the .met file, which could have been used for RINEX MET translation. But there is some prototype code in teqc in case the user comes across any examples.)

  • Topcon TPS/Javad JPS:
    • Binary data from Topcon and Javad receivers can be read with teqc if the format is Topcon TPS, which is more or less equivalent to Javad JPS format. Not all TPS/JPS messages are read by teqc, though new development is done as needed. The following caveat applies however: If a set of TPS/JPS messages to be used is other than the default one or if the adopted order of messages in the default set of messages is changed in some way, make sure that the updated set of messages maintains the "epoch synchronization", i.e., the messages [~~] and [RD] precede the messages containing code, carrier phase and other types of measurements collected at the current epoch. Should the user violate this condition, he or she may not be able to correctly process corresponding raw data files with teqc or with Topcon's Pinnacle™ and other TPS post-processing software.

  • Septentrio Binary Format:
    • Septentrio Binary Format (SBF) from Septentrio receivers can be read with teqc.

  • Navcom binary:
    • Binary data from Navcom receivers can be read with teqc.

  • ConanBinary from TurboRogue/TurboStar and Benchmark ACT receivers:
    • ConanBinary data from the Turbo series of Rogue receivers is readable with teqc. (ConanBinary data from original Rogues are ordered by SV number, rather than by time, and will not translate correctly with teqc).

  • TurboBinary
    • TurboBinary data is readable with teqc. This includes data with normal-rate data, high-rate (50 Hz) data, and the so-called "30-1 second" data containing LC data. Extraction of the LC data, however, is not automatic (since it is not standard RINEX version 1 or 2) and you must use the -O.obs option to specify the LC data as one of the observation data types.

    TurboBinary data from the AOA Benchmark ACT receiver can be tranlated in the usual way for TurboBinary, or using special Benchmark translation options. For example, using the -aoa tbY option (for "Y*-codeless" receivers), the C/A-derived L1 phase value is used for the RINEX "L1" observable, rather than the Y1-codeless L1 phase value.

  • IGS RTigs format:
    • Supported, but the IGS may add new features that may not be readable by teqc.

  • JPS Soc format:
    • Supported.

  • Canadian Marconi Binary Format:
    • Teqc can read the Canadian Marconi binary format, mainly for the CMC Allstar OEM (CMT-1200) receiver. To date, this includes record IDs 21, 22, 23, 63, and 126--sufficient to write RINEX OBS and NAV files. The translation will include multiple 175-ns clock resets (the Allstar's clock steering signature) between consecutive epochs.

  • u-blox UBX Format:
    • Teqc can read the u-blox UBX format, though only decoding information in messages NAV-CLOCK (0x0122), NAV-POSLLH (0x0102), RXM-EPH (0x0231), and RXM-RAW (0x0210).

  • Rockwell Zodiac Binary Format:
    • Teqc can read the binary format used in the Rockwell Zodiac receivers. To date, this includes message (record) IDs 1000, 1002, and 1102--sufficient to write RINEX OBS files. (There are no records in the Rockwell Zodiac format which contain SV ephemerides or MET data.)

  • Motorola Oncore Format:
    • Teqc will correctly translate the Oncore format to RINEX OBS except for the L1 phase.

  • ARGO Format:
    • The two ARGO format files types, *.dat and *.orb, can be read with teqc. The ARGO *.dat file is equivalent to the RINEX OBS file; the ARGO *.orb file is equivalent to the RINEX NAV file.

  • Texas Instruments 4100 GESAR, BEPP/CORE, and TI-ROM Formats:
    • Binary data from the TI-4100 can be read with teqc, though the code for all records types has not been tested. (This is because examples of certain record types have not yet been encountered in use to date. For example, so far, only Record 1 of the TI-ROM format has been encounterd in actual files, which is sufficient to write RINEX OBS files.) These translators are being included primarily to read legacy data. To date, teqc can read what has been called GESAR and/or BEPP/CORE data (can be a mixture) or can read the original TI-ROM format. Depending on the record types in the data, it is possible to extract not only P1/CA, P2, L1, and L2, but also signal-to-noise (S1 and S2) and Doppler (D1 and D2).

  • Status on other formats:
    • for old Trimble *.dat containing records 0 or 7, try Berne's TRRINEXO program
      • ; if that does not work, try Trimble's dat2rin program; if that does not work, please contact Trimble for help
    • for Ashtech B-files prior to Version 3, try Ashtech's convert program; if that does not work, try Berne's ASRINEXO; if that does not work, please contact Ashtech for help

    Basic Modes of Operation
    Section 4.



    There are three different basic modes of operation of teqc: Any of these modes can be used by themselves, or in combination with one another. For example, some of the ways that you might use teqc are:
    • check a RINEX file or files for compliance with RINEX version 2.XX specification; for example, missing non-optional header fields are identified
    • modify (edit) any existing RINEX header fields in a RINEX file and output the resulting edited RINEX file
    • quality check a valid RINEX OBS file or files, but without a RINEX NAV file or binary ephemerides (qc "lite" == no position information)
    • quality check a valid RINEX OBS file or files using ephemerides data in a valid RINEX NAV file or files (qc "full" == position information possible)
    • window or cut (specify a sub-window of time) and/or splice two or more RINEX files
    • translate (convert) certain native binary formats (e.g., Trimble *.dat) to RINEX OBS and/or NAV files
    These modes of operation work alone or in concert with one another. As an example, a Trimble binary stream can be translated to RINEX OBS and NAV files; have empty header fields in the OBS file (such as the MARKER NAME) filled in; have the stream qc-ed, explicitly time-windowed, and auto-switched from qc-lite to qc-full when enough satellite ephemerides are encountered in the data stream, all in a single teqc run.

    It may also be helpful for the first-time user to be aware that:
    • A minimal number of assumptions have been made about the file names that teqc uses. Essentially the file names can be any valid name for the OS, except that no input file name can start with a '-' or '+' character, and names with whitespace (like spaces) are probably best avoided. The Berne-recommended naming convention for RINEX files, though not necessary for teqc, is quite acceptable and can be readily used on the command line or in scripts using teqc.
    • In general, teqc is design-ready not only for NAVSTAR GPS data, but also GLONASS data, NNSS Transit data, SBAS (e.g. WAAS, EGNOS) data, or any other future system that may become part of the RINEX standard. Just the details need to be written into the code as they become available.
    • teqc is 100% non-interactive; it will not query the user for input or to find out if something is OK. Your may receive a "Notice", "Warning", or "Error" to stderr. If something is wrong (ususally an "Error" or usage problem), teqc informs the user and terminates.
    • In general, teqc does not use hard-wired array sizes, but instead allocates and deallocates memory as needed. As long as your computer has enough computer memory, you should never run into array bound problems.
    • teqc is conservative about memory use.
    The basic design of teqc is command-line oriented, following the UNIX shell model. For the remainder of this document, it will be assumed that the user is using a UNIX OS and is familiar with basic UNIX commands. Documentation specific to other operating systems (e.g. DOS) will be included as the program is ported and tested on other operating systems.

    Operating Systems and Hardware
    Section 5.



    To date, teqc has been tested by UNAVCO personnel and other users on:
      Linux x86
      Solaris Sparc 2.3 and higher
      Solaris x86 2.6 and higher
      HP-UX 10.20 and higher (PA-RISC platforms)
      DEC Digital-UNIX OSF1 V4.0
      DEC Alpha Linux
      IBM AIX 4.3
      SGI IRIX 5.3
      Macintosh OSX
      Microsoft (95/98/NT/2000/XP)
    Support for other platforms may be included over time. If you need support on a UNIX platform not listed above and can provide a guest login on that platform with a ANSI or K&R (Kernighan and Ritchie--aka "traditional") C compiler, contact teqc technical contact.

    Standard Input, Standard Output, and Standard Error
    Section 6.



    Another basic design feature is the use of standard input (stdin), standard output (stdout), and standard error (stderr). Instead of a file as input, teqc can be in a pipeline accepting a RINEX format stream or binary data stream as stdin. Stderr is reserved for reporting problems that may occur any time teqc encounters something in any file or in stdin that it doesn't like or understand. Stdout is used for dumping the ASCII product requested by the user consistent with the command line syntax. The output from teqc then has the following caveats at the present time: stdout and stderr must be able to be separated.

    Consequently, the user is encouraged to use a shell that can distinctly separate stdout and stderr. For UNIX, this includes the Bourne shell (sh) and the Korn shell (ksh). For UNIX C-shell (csh) or for DOS--which do not allow you to direct stdout and stderr separately to different files--an option of teqc (i.e. +err filename) can be used to send what would have gone to stderr to a separate file, to avoid unpleasantries when stdout and stderr would otherwise go to the same place. For the remainder of this document, it will be assumed that the UNIX user is using either sh or ksh, though the following examples should allow a user to easily use csh or a MS DOS shell to achieve the same results.

    Though the rest of this tutorial assumes you will be using sh or ksh, you can easily use teqc with csh or a DOS to control stdout and stderr. When using csh or a DOS (or with any other shells), you can use the command options +out, ++out, +err and/or ++err to have teqc internally redirect stdout and/or stderr to specific files. Thus:
      sh or ksh:
      teqc {rest of command} 2> err.txt [stdout to screen]
      any shell:
      teqc +err err.txt {rest of command} [stdout to screen]
    or
      sh or ksh:
      teqc {rest of command} > out.txt [stderr to screen]
      any shell:
      teqc +out out.txt {rest of command} [stderr to screen]
    should be exactly equivalent. You can even use +out and +err on the same execution of teqc to write to the same file name:
      sh or ksh:
      teqc {rest of command} > temp 2>&1
      any shell:
      teqc +out temp +err temp {rest of command}
    Also, you can append to an existing file using ++out or ++err:
      sh or ksh:
      teqc {rest of command} >> out.txt 2>> err.txt
      any shell:
      teqc ++out out.txt ++err err.txt {rest of command}
    To append with either just stdout or stderr, or use ++out or ++err:
      any shell:
      teqc {rest of command} >> out.txt [stderr to screen]
      any shell:
      teqc ++out out.txt {rest of command} [stderr to screen]
    or
      any shell:
      teqc {rest of command} 2>> err.txt [stdout to screen]
      any shell:
      teqc ++err err.txt {rest of command} [stdout to screen]
    In short, regardless of what shell you are using, there should a way to accomplish what you want for redirection of stdout and stderr.

    General Concepts About Syntax
    Section 7.



    The general syntax for teqc is:
      teqc {options} [file1 [file2 [...]]]
    or (except for DOS shells):
      teqc {options} < stdin
    or similarly
      ... | teqc {options}
    The file or files listed at the end of the command line, or stdin, are the targets which are to be processed for each execution of teqc. This is mentioned since other file names may be present in the options, but any files listed in the options are part of the processing configuration and are not considered to be targets of the processing.

    Even executing just
      teqc
    (i.e., no targets present) is allowed; this returns teqc's best guess as to which GPS week it currently is based on the CPU's clock (but how good this guess is depends on how well the CPU's time is set).

    There is a mnemonic governing the use of - and + preceding each option:
      leading -:
      indicates intent to input something (besides stdin or target file list),
      or indicates intent to turn off some option
      leading +:
      indicates intent to output something, (besides stdout and/or stderr),
      or indicates intent to turn on some option
    For some options, a leading - and + do the same thing. To get help, for example,
      teqc -help
    and
      teqc +help
    both dump an extensive usage to stderr. (Following the mnemonic, only the +help should give help, but why further confuse the issue when the user is requesting for help? For this reason, both work here.) Also, the RINEX header editing option flags work the same way: e.g., -O.mo is the same as +O.mo. You can either think of -O.mo as inputting some header information (the monument name), or using +O.mo as forcing what you want the output header information to be.

    In order to try to detect possible command line input errors, target file names at the end of the command line starting with the character '-' or '+' are currently disallowed. Anything starting with the characters '-' or '+' is always assumed to be a command line option.

    Sometimes, especially with new features (e.g., new translators) as they are being added and debugged, you may be inundated with warning messages going to stderr. Most of these can usually be suppressed by including the -warn option:
      teqc -warn {rest of command}

    Using teqc for RINEX Formatting & RINEX Format Verification
    Section 8.



    Suppose you have three RINEX files (using the Berne-recommended naming conventions): fbar0010.97o, fbar0010.97n, and fbar0010.97m being your OBS, NAV, and MET filenames respectively. Let us suppose that you first wish to verify that your fbar* files can be interpreted as RINEX version 2.XX format compliant, i.e. that their format is such that they have all the bits and pieces in them to make them look like a RINEX file (but not that the information in them is necessarily valid). One way of doing this is to execute:
      teqc fbar0010.97o
      teqc fbar0010.97n
      teqc fbar0010.97m
    What you see being dumped to the screen is a re-processed RINEX version 2.XX format. All information originally in the target file will be retained in the output version (--and if its not, there's a bug, so please report this).

    Or you could execute:
      teqc fbar0010.97o > temp0010.97o
      teqc fbar0010.97n > temp0010.97n
      teqc fbar0010.97m > temp0010.97m
    in which case the re-processed RINEX files are redirected (stdout) and saved as a set of temp* files.

    After doing the above three commands, it might also be instructive to do something like:
      diff fbar0010.97o temp0010.97o | more
    to see what some of the differences between the original target file and the re-processed file might be. If the original file were produced by teqc, you shouldn't see any differences (--and, again, if you do, there's a bug, so please report this).

    If, in fact, there is some format problem with any of the above input RINEX files fbar0010.97*, teqc will output stdout (either to the screen as in the first set of examples, or redirected to files as in the second set of examples) until the problem is encountered, at which point it will report the problem using stderr and terminate. teqc makes few guesses about what a RINEX file is supposed to be; if a file has a problem, a human or some other program must be used to fix it before teqc will proceed further.

    Now suppose that you have a list of RINEX files that you wish to check for RINEX version 2.XX format compliancy, but don't want to save any re-processed stdout. There are several ways to do this (e.g., in UNIX):
      teqc fbar0010.97o > /dev/null
      teqc fbar0010.97n > /dev/null
      teqc fbar0010.97m > /dev/null
    or, using the command line option +v (any shell):
      teqc +v fbar0010.97o
      teqc +v fbar0010.97n
      teqc +v fbar0010.97m
    or:
      teqc +v fbar0010.97o fbar0010.97n fbar0010.97m
    or (UNIX shell regular expressions):
      teqc +v fbar0010.97[m-o]
    or even (e.g., if using ksh):
      teqc +v `ls fbar0010.97*`
    Essentially the +v option does three things:
    1. shuts off the dump to stdout--so teqc +v fbar0010.97o should execute faster than teqc fbar0010.97o > /dev/null,
    2. suppresses file "splicing"--so teqc understands that the input files are not necessarily of the same RINEX type, and
    3. dumps a short message to stderr saying that each input file conforms to RINEX version 2.XX specifications at the end of the execution of the file, or a error message dumped to stderr if a problem was encountered.
    teqc also examines the target(s) for proper time-ordering. For OBS and MET files, the time marker being examined is the observation and/or event epoch. For NAV files, three time markers are examined: the TOC ("time of clock") epoch, the TOE ("time of ephemeris") epoch, and the TOW ("time of transmission"). For OBS and MET files, time-ordering is required. For NAV files, a sanity check is performed on the three times for each ephemeris.

    When inputting multiple target files of the same type, teqc looks to see if this time ordering remains sequential (though neighboring epochs of exactly the same time are currently allowed)--except for RINEX NAV files, where the information is sorted before it is used. For this reason, assuming that the data in fbar0020.97o really follows fbar0010.97o, executing
      teqc +v fbar0020.97o fbar0010.97o
    will result in an error message and program termination at the first observation epoch in fbar0010.97o (assuming no other errors).

    Using teqc for RINEX Header Editing & Extraction;
    Introduction to Configuration Options and Files and the teqc Option Hierarchy
    Section 9.



    As experienced RINEX file users know, any or all of the RINEX header information may be incorrect. In principal, any of this information can be modified by anyone using an editor for ASCII files, such as "ed", "ex", or "vi" on a UNIX OS, on a file-by-file basis (which, incidentally, highlights one of the most severe vulnerabilities of RINEX--ease of intentional or non-intentional data tampering).

    However, it often occurs that the same type of information needs to be corrected on a large set of RINEX files and that the same corrected information needs to be placed in these fields on all the effected files. In this case, it may be easier to use the RINEX modification (editing) capabilities of teqc.

    For example, suppose the monument (marker) name needs to be corrected to read "the foobar site" in the OBS file fbar0010.97o. This can be accomplished by executing
      teqc -O.mo "the foobar site" fbar0010.97o > temp0010.97o
    in which case the corrected file is now temp0010.97o. The -O.mo option specifies that the original monument name in any OBS file being processed is to be overridden with the string "the foobar site". Notice the double-quotes on the command line encapsulating the string which contains blanks as white space. If you wished to change the monument name to just "foobar", you could execute
      teqc -O.mo "foobar" fbar0010.97o > temp0010.97o
    or just
      teqc -O.mo foobar fbar0010.97o > temp0010.97o
    Notice that in this case, there are no blanks in the replacement field (i.e., the new monument name), so the double-quotes are optional.

    There is a similar mechanism to change every header field in a RINEX file, except 1) RINEX comments, in which case the user can only append more comments in the RINEX header, and 2) the first header record of the RINEX file. Rather than list all the possible options here, it is easier to have teqc do it, by using the ++config option with a RINEX target file:
      teqc ++config fbar0010.97o
    which will dump all the changeable header information and the current values (i.e., those in the OBS file fbar0010.97o) to stdout. A related option, +config, shows only those options which have been set by command line or other means. To see the difference, try:
      teqc -O.mo foobar +config fbar0010.97o
      teqc -O.mo foobar ++config fbar0010.97o
    Basically, +config means: "show me what internal default option settings/values of teqc have been overridden"; ++config means: "show me how all the teqc options are set, including the internal defaults".

    Executing just
      teqc ++config
    will show the generic default configuration options of teqc (plus a few lines about the GPS week that went to stderr).

    When executing just teqc ++config (i.e. no target files), the two options -st[art_window] and -e[nd_window] show the total possible time range with which teqc is able to cope--down to a resolution less than a femtosecond (1e-15 sec). The format for the arguments of these options are YYYYMMDDhhmmss.sss. Internally, 12 bits are used to store the value of the year, giving teqc the capability of dealing with 4096 years. Thus, with the internal calendar starting at 1980 A.D. (the GPS calendar started on 6.0 Jan 1980), teqc's calendar won't become obsolete any time soon--e.g. teqc passed the Y2k transition on 1.0 Jan 2000 and the GPS week 1024 rollover on 22.0 Aug 1999 perfectly. Whether you specify it or not, teqc always works with a defined time window, where executing teqc ++config shows the maximum bounds on that time window. Note that you can't use times before 1.0 Jan 1980.

    After executing teqc ++config, you probably noticed that some of the configuration options end with something like [stuff]. The characters in the brackets and the brackets themselves are optional material included only to make the option more understandable to the user; only the characters to the left of the leading [ is used to identify the configuration option. Thus -O.mo and -O.mo[nument] and -O.monument and -O.moe_and_curly all mean exactly the same thing: the user is trying to set the monument name with the next argument. However, like the rest of the option flag name, only printable characters are allowed in the brackets; no white space is allowed.

    You can redirect this configuration information to a file, which is called a configuration file:
      teqc ++config fbar0010.97o > my_obs_config
    This ASCII configuration file (i.e., my_obs_config in the above example) can be easily edited to contain (hopefully) correct information. The meaning of the various -O flags should be fairly obvious to anyone familiar with the RINEX OBS header fields:
      -O.s[ystem]
      satellite system (G = GPS, R = GLONASS, S = SBAS, T = Transit, M = mixed)
      -O.pr[ogram]
      program used to create RINEX file (note: will be obsolete and ignored in first release after 7 Jan 1999)
      -O.r[un_by]
      name of user of program
      -O.d[ate]
      date of program execution (note: will be obsolete and ignored in first release after 7 Jan 1999)
      -O.o[perator]
      name of site operator (observer)
      -O.ag[ency]
      name of agency
      -O.mo[nument]
      monument (marker) name
      -O.mn
      monument (marker) number
      -O.rn
      receiver number
      -O.rt
      receiver type
      -O.rv
      receiver software/firmware version
      -O.an
      antenna number
      -O.at
      antenna type
      -O.px[WGS84xyz,m]
      approximate geocentric position in WGS84 cartesian coordinates, in meters
      -O.pe[hEN,m]
      antenna topocentric correction, in meters
      -O.c[omment]
      original header comment (note: use +O.c[omment] to append a new comment)
      -O.int[erval,sec]
      sampling interval, in seconds
      -O.st[art]
      date & time of first observation epoch
      -O.e[nd]
      date & time of last observation epoch
      -O.def_wf
      default wavelength factors for L1 and L2 (see note on teqc's handling of wavelength factors)
      -O.obs[_types]
      list of observables and the observables themselves in the data portion of the file
    There are also a few other options that can be used to input information, but are never output with +config or ++config:
      -O.dec[imate]
      modulo decimation of OBS epochs to # time units (seconds by default); -O.dec 30 or -O.dec 30s or -O.dec .5m results in epochs nominally at 00 and 30 seconds being output; millisecond jumps should be accounted for automatically
      -O.pg[eo,ddm]
      approximate geocentric position in WGS84 geographic coordinates, latitude and longitude in decimal degrees and elevation in meters (this input is converted to WGS84 cartesian coordinates)
      -O.sl[ant]
      input vertical topocentric antenna correction as slant height, antenna diameter, and vertical phase center offset (E and N are assumed to be zero) (this input is converted to the cartesian topocentric correction h 0 0)
      +O.c[omment]
      append a new comment field (note: you cannot change existing comments with -O.c[omment])
      -O.rename_obs
      change the character designations of the observables in the # / TYPES OF OBSERV in the RINEX OBS header, but does not rearrange the data in the file; use with care!
      -O.mod_wf
      set the wavelength factors for a specific set of SVs different from the default wavelength factors (this will not be present in the RINEX OBS header as a WAVELENGTH FACT L1/2 record; see note on teqc's handling of wavelength factors)
      -O.mov[ing] 1
      force RINEX OBS antenna position to be in kinematic (roving) state initially (especially regardless of binary flags if doing translation); note that this option has an argument: 1 to turn on and 0 to turn off
    There is a similar set of editing/extraction flags for RINEX NAV files, which you could obtain by examining: teqc ++config fbar0010.97n | more
      -N.a[alpha]
      ionosphere alpha parameters
      -N.b[eta]
      ionosphere beta parameters
      -N.leap
      leap seconds for UTC time model
      -N.UTC
      UTC time model A0 A1 t w
      -N.pr[ogram]
      program used to create RINEX file (note: will be obsolete and ignored in first release after 7 Jan 1999)
      -N.r[un_by]
      name of user of program
      -N.d[ate]
      date of program execution (note: will be obsolete and ignored in first release after 7 Jan 1999)
      -N.s[ystem]
      satellite system (G = GPS, R = GLONASS, S = SBAS, T = Transit, M = mixed)
      -N.c[omment]
      original header comment (note: use +N.c[omment] to append a new comment)
    and likewise for editing you can also use
      +N.c[omment]
      append a new comment field (note: you cannot change existing comments with -N.c[omment])
    There is a similar set of editing/extraction flags for RINEX MET files, which you could obtain by examining: teqc ++config fbar0010.97m | more
      -M.pr[ogram]
      program used to create RINEX file (note: will be obsolete and ignored in first release after 7 Jan 1999)
      -M.r[un_by]
      name of user of program
      -M.d[ate]
      date of program execution (note: will be obsolete and ignored in first release after 7 Jan 1999)
      -M.obs[_types]
      list of meteorological observables and the met observables themselves in the data portion of the file
      -M.mo[nument]
      monument (marker) name
      -M.mn
      monument (marker) number
      -M.c[omment]
      original header comment (note: use +M.c[omment] to append a new comment)
    and likewise for editing you can also use
      +M.c[omment]
      append a new comment field (note: you cannot change existing comments with -M.c[omment])
      -M.rename_obs
      change the character designations of the meterological observables in the # / TYPES OF OBSERV in the RINEX MET header, but does not rearrange the data in the file; use with care!
    Let's return to the metadata from the fbar0010.97o. Assuming that the configuration file my_obs_config from above now contains corrected RINEX OBS fields, you could execute (in sh or ksh):
      teqc `cat my_obs_config` fbar0010.97o > temp001a.97o
    or (using another teqc command line option)
      teqc -config my_obs_config fbar0010.97o > temp001b.97o
    The -config this_config_file specifies that you are inputting a configuration file called this_config_file.

    There is an important difference between the last two example commands, though it should not be apparent at this point (i.e., executing diff temp001a.97o temp001b.97o should show that the two modified files are identical). Here the option hierarchical procedure used in teqc is introduced. To make full use of teqc's capabilities, it is strongly suggested that the user eventually become familiar with this hierarchy.

    The primary rule to remember when using configuration options is:
    The first setting/value for a configuration option that is encountered is the one that's used (later settings/values for the same configuration option are ignored); except for three special cases: inputting multiple config files, multiple NAV files for the qc mode, and additional RINEX comments.
    All that is needed now is to know the order in which configuration options are processed.

    The first configuration options that are processed are the command line options, processed left to right. For example, execute:
      teqc -O.mo "the foobar site" -O.mo foobar ++config fbar0010.97o
    Here, there are two identical configuration options on the command line, -O.mo, to change the monument name, but two different arguments. Which is used? The answer is the first one encountered, which in this case is the one to the left. To convince yourself, also try:
      teqc -O.mo foobar -O.mo "the foobar site" ++config fbar0010.97o
    In the example execution from above (using sh or ksh):
      teqc `cat my_obs_config` fbar0010.97o > temp001a.97o
    the `cat my_obs_config` turns the contents of the configuration file my_obs_config into command line configuration options, the first line of which (at the top of the file) becomes equivalent to the leftmost command line option, proceeding to the last line of which (at the bottom of the file) becomes equivalent to the rightmost command line option.

    The next configuration options that are processed come from a special environment variable (if it exists), called $teqc_OPT. Actually, the executable looks for an environment variable that matches the name of the executable. So if you do cp teqc my_teqc and then use my_teqc as the executable, it will look in this case for the environment variable called $my_teqc_OPT.

    Therefore, if you set $teqc_OPT (assuming sh or ksh):
      export teqc_OPT="-O.mo foobar"
    and then execute and compare
      teqc ++config fbar0010.97o
      teqc -O.mo "the foobar site" ++config fbar0010.97o
    you will see that the monument name is set to foobar in the first case (using the environment variable $teqc_OPT) and the foobar site in the second case (using the command line option).

    The next configuration options that are processed are all the specified configuration files. A list of these are formed in the following way. First, all -config command line arguments or any in $teqc_OPT are stored. Then (assuming, again, that our executable is still called teqc), the environment variable $teqc_CONFIG is looked for, which may contain the name or the complete path and name to another configuration file. If $teqc_CONFIG exists, the name it contains is appended to the end of this list of configuration files (if any) from the command line. Now all that is needed to is to find each of these configuration files (if they exist), which is done in the following way.

    For each possible configuration file name, the name is first examined to see if it starts with a / character assuming a UNIX-style directory naming convention. (With the DOS-style convention, a \ is used; with the MacIntosh-style convention, a : is used.) If the name does start with /, teqc assumes that the configuration file name is absolute, i.e., it contains a full path preceding the file name. In this case, teqc will try only this path and name. If the file exists and can be read, it is processed as a configuration file; if it does not exist or cannot be read, teqc moves on to the next file in the list.

    If the configuration file name does not start with a /, teqc assumes that the configuration file name is relative, i.e. it contains only a partial path and file name, or perhaps just the file name. At this point, teqc looks for an $teqc_PATH environment variable, set up the same way as other $*PATH environment variable, i.e. with a : separating the different paths. If this $teqc_PATH environment variable exists, each path in it is used as a prefix to the relative configuration file name. If a file is found that can be read, it is processed as a configuration file, and then teqc moves on to the next configuration file in the list. If it cannot be found or cannot be read, teqc tries the next path as a prefix, and so on.

    If $teqc_PATH does not exist, teqc will always try the path ., i.e., the present working directory. If you use $teqc_PATH, you will probably want to make sure that . is one of your paths; teqc will not automatically include it for you in this case.

    To summarize, the hierarchy for processing configuration options is:
    1. process command line options first, left to right
    2. any -config arguments are stored as a list of configuration files
    3. if it exists, the environment variable $teqc_OPT is processed according to the same hierarchy as 1) and 2) above
    4. if it exists, the environment variable $teqc_CONFIG is appended to the end of the list of configuration files extracted from the command line and the environment variable $teqc_OPT
    5. the accumulated list of configuration files is then processed, first to last:
      • if the name of the configuration file is absolute, only that path and name are examined
      • if the name of the configuration file is relative: the list of paths in $teqc_PATH is used until a file is found and read or until all the paths in $teqc_PATH are exhausted; if $teqc_PATH does not exist, only the relative path . is tried.
      • then each configuration file is processed from left to right and top to bottom
    6. any configuration option not set by the above has a default configuration option hardwired in the teqc executable, or in the case of inputting RINEX or native binary formats (via stdin or files), the original information is used, or if that information is not present, it is null.
    If using teqc in a qc mode, a list of found-and-read configuration files will be included in both the qc short report segment and the qc long report segment.

    This may seem like a mind-boggling set of unnecessary possibilities, but you can be assured that there is a reason. So far you have only been exposed to the -O.* options for modifying header fields in RINEX OBS files. There are over 20 of these options. There is a similar set of -N.* options for RINEX NAV files and -M.* options for RINEX MET files. For general use of teqc there are about a dozen different options and with the quality checking mode (qc) there are about 7 dozen different options. To have all of these options crammed into one file (which is certainly possible), creates a near-unmanageable file if you are interested in changing only one or two parameters. Each configuration file need not have all the options specified, owing to the way that teqc looks at each file: more as a set of command line options with random order than a rigidly formatted file. If ideas are not already starting to churn in your head as to how to take advantage of this flexibility, an example in the section on scripts will show you how to easily make use of this option hierarchy.

    Furthermore, you don't really need to use any configuration files (perhaps just a few configuration options used as command line options) to have teqc produce reasonable output in most cases, as demonstrated by the first examples in this document.

    Configuration Options and Command Line Options; What's the Difference?
    Section 10.



    Syntactically, it may appear that there is no difference between what is being called a configuration option and a normal UNIX command line option for teqc. For many of the options, there is, in fact, no difference. That's the beauty of the whole teqc interface design!

    However, for an important subset of teqc configuration options there is a critical difference. These are the options that have arguments which are characters strings that might encapsulate white space, like -O.mo discussed in detail above. Currently, these are only the -O., -N., and -M. options which will edit RINEX header character fields, plus the +O.c, +N.c, and +M.c options to include any new RINEX comments. The important differences for these options are:
    • if the text string contains whitespace, the text string must be delimited by a set of " (double-quotes) (though delimiting any text string with a set of double-quotes is always permissible)
    • if the text string contains a " (double-quote) or a \ (backslash) character itself, each instance must be preceded by an additional \, i.e. \" or \\
    Using the +O.c option, some examples are shown here to (hopefully) clarify what can be done. The same fashion of operation occurs with any of the other text string options, e.g. -O.mo.

    Create a config file, comment_config, containing: 
      +O.c "  \"\\ This  is  a  \"comment.\" \\ \" \ "
    and execute 
      <prompt> teqc -config comment_config RINEX_OBS | grep comment 
      
  "\ This  is  a  "comment." \ "                            COMMENT
    where RINEX_OBS is any RINEX OBS file. Or using the command line (e.g. with ksh): 
      <prompt> teqc +O.c "  \"\\\ This  is  a  \"comment.\" \\\ \"" RINEX_OBS | grep comment 
      
  "\ This  is  a  "comment." \ "                            COMMENT
    Notice that two extra backslashes were required due to metacharacter interpretation of two of the backslashes by the shell. A similiar type of shell interpretation of the backslash is required here: 
      <prompt> teqc +O.c long=123W34\'45\" RINEX_OBS | grep long= 
      
long=123W34'45"                                             COMMENT
    where an additional \ (backslash) had to included, not for teqc, but to suppress the metacharacter meaning of the ' (single-quote) for the shell. (In this latter example, note that the text string is not delimited by a set of " (double-quotes) since there is no whitespace included in the text string.) Or using $teqc_OPT, execute (e.g. with ksh): 
      <prompt> export teqc_OPT="+O.c \"  \\\"\\\\ This  is  a  \\\"comment.\\\" \\\\ \\\" \ \"" 
      
<prompt> echo $teqc_OPT 
      
+O.c " \"\\ This  is  a  \"comment.\" \\ \" \ " 
      
<prompt> teqc RINEX_OBS | grep comment 
      
  "\ This  is  a  "comment." \ "                            COMMENT
    where lots of extra backslashes were required by metacharacter interpretation of backslashes by the shell to establish the correct value for the environment variable $teqc_OPT.

    A minor flaw occurs if trying: 
      <prompt> unset teqc_OPT 
      
<prompt> teqc `cat comment_config` RINEX_OBS | grep comment 
      
 "\ This is a "comment." \ "                                COMMENT
    (The initial unset command just eliminates $teqc_OPT in case it had a value.) Notice that each multiple whitespace area in the original comment string collapses into a single whitespace area in the RINEX comment. (The whitespace collapse occurs during the interpretation of the cat command by teqc.) In this case, this result is the best that can be accomplished given the way UNIX shells work.

    To complete the symmetry of the teqc interface, when using the +config or ++config options any existing " (double-quote) or \ characters in RINEX text fields are expanded into \" or \\ in the resulting config output. In this way, the config output is immediately usable as a valid and complete teqc config file.

    Using teqc for Quality Checking (qc) Mode
    Section 11.



    A large portion of teqc is for quality checking or qc-ing of satellite positioning data, mainly NAVSTAR GPS data, but it will generally work for GLONASS and SBAS, though for these latter systems the qc is "lite" (without orbit determination).

    To use teqc in a qc mode, try, for example:
      teqc +qc fbar0010.97o
    (assuming for the moment that the RINEX NAV file fbar0010.97o is not in the current directory). First, notice the +qc option: i.e., turn qc on. Next notice that there is only a RINEX OBS file as a target file. What you are doing here is running a qc-lite mode, i.e., devoid of any satellite positioning information.

    Executing the above should produce something if fbar0010.97o is a valid and complete RINEX OBS file. Exactly what is does (at this point) should only depend on the default qc-mode settings in teqc--which, incidentally, should represent what a majority of users feel they want from routine qc processing. However, nearly all qc parameters can be effected by the appropriate configuration option. And, yes, you can look at the qc configuration options to see what exactly you can effect, by:
      teqc +qc ++config 2> /dev/null | more
    (Some notes: Notice how this differs from executing just teqc ++config 2> /dev/null. In short, with the +qc option, you are turning on the qc mode of teqc and with ++config asking for a complete configuration option set, so now you get all the qc mode options following the general teqc options. Also, a pipe to more is used because there are a lot of qc options!)

    Now let's look at what the execution of teqc +qc fbar0010.97o (perhaps followed by a pipe to more) finally produced. Assuming a successful run, the user should have noticed at least two things: 1) There should have been a set of characters going to the screen (actually, to stderr) during execution which looked like
      qc lite>>>>>>>...
    (with perhaps some other non-critical stderr messages mixed in). This is just a linear analog indicator of how teqc is marching through the observation epochs, where the length of the final indicator matches the "length" of the ASCII time plot (default of 72 characters). 2) There was a screen dump (actually, to stdout) of the ASCII time plot and some simple statistics at the end. (Note: This latter part to stdout is roughly equivalent to what was written to the *.YYS file by the original UNAVCO QC program.) Also, in the future, what is dumped to stdout may change, though this will be settable with one or more configuration flags.

    Next, look at the result of
      teqc +qc ++config 2> /dev/null | grep report
    The result should be something like:
      +l[ong_report]
      +s[short_report]
    If either of these configuration options do, in fact, start with a +, then you should have a fbar0010.97S file in your directory, which is your qc report file on fbar0010.95o. There are two possible segments to this report: a possible short report segment followed by a possible long report segment. You should have the short segment if your configuration says +s..., and it should be absent if your configuration says -s.... For now, the short report segment is identical to the information being dumped to stdout. You should have the long report segment if your configuration says +l..., and it should be absent if your configuration says -l.... (The long report segment takes the place of what used to go to stdout in the original UNAVCO QC.)

    Next, look at the result of
      teqc +qc ++config 2> /dev/null | grep plot
    If the result is
      +plot
    then you probably have one or more plot files (in UNAVCO COMPACT format), e.g.:
      fbar0010.ion if +ion was set (ionospheric delay observable, in meters)
      fbar0010.iod if +iod was set (derivative of ionospheric delay observable, in meters/second)
      fbar0010.mp1 and fbar0010.mp2 if +mp was set (MP1 and MP2 observables, in meters)
      fbar0010.sn1 and fbar0010.sn2 if +sn was set (S/N for L1 and L2, in arbitrary units)
    These files can be viewed graphically using UNAVCO's gt or qcview executables. Using a configuration option of -plot suppresses all plot files. You can also convert the ionospheric delay observable and its derivative to relative changes in TEC (Total Electron Count == 1e16 electrons/m^2) and its derivative by using +tec.

    Next, move or create fbar0010.97n in the your working directory and execute:
      teqc +qc fbar0010.97o
    or
      teqc +qc -nav fbar0010.97n fbar0010.97o
    Here you are inputting an additional file, either by default in the first example or explicitly by using the -nav configuration option followed by the name of a RINEX NAV file. You are now running teqc in a qc-full mode, i.e., satellite positioning information is present, and if enough information is present (satellite ephemerides, plus receiver P1, P2, or C/A codes) then a position for the antenna is attempted. There is no additional flag to use the qc-full mode. If you supply binary data or NAV files or if teqc automatically finds a matching NAV file name to the supplied OBS file name, you are using qc full; if you don't supply NAV files and there is no matching NAV file, you are using qc lite. If you are supplying binary data, there is no a priori way to determine if ephemeris records are present or not without reading the entire input first, so qc-full is assumed in this case.

    The case-sensitive algorithm for building matching NAV file names from OBS file names is as follows, where YY represents two digits, e.g. YY == 97: 
      *.YYo	->   looks for *.YYn
*.YYO	->   looks for *.YYN
*.obs	->   looks for *.nav
*.OBS	->   looks for *.NAV
    Other cases for this NAV file auto-matching can easily be added to the code.

    During execution (which will probably take slightly longer than the qc-lite run), you should now see:
      qc full>>>>>>>...
    going to stderr (and, again, possibly other stderr stuff mixed in). Assuming a successful run, the general things that happen should be similar to what happened with the qc-lite run, expanded to include information about satellite position (like elevation) and antenna position. The biggest additional items, assuming a +plot configuration, are the additional COMPACT plot files:
      fbar0010.azi andfbar0010.ele (satellite topocentric azimuths and elevations as viewed from the antenna for every satellite for which an ephemeris was present in the NAV file)
    One of the fundamental design criteria was to have teqc dynamically switch from a qc-lite mode of operation to a qc-full mode of operation on a per satellite basis as an ephemeris became available. This is especially important for analyzing real-time data streams. For the normal "post-processing" (i.e., files are available), the same scheme applies. If no ephemeris is available for a particular satellite from the supplies NAV file(s), but observations for that satellite are present, the observations are completely processed using the qc-lite mode, even though the qc-full mode is on in general. Appropriate indicators are supplied in report that this occurred.

    Using teqc with Multiple File Input or File Names Including a , (comma)
    Section 12.



    Cases always arise where you want to include multiple files as input. Let's look at some of these cases. First, there may be multiple configuration files:
      teqc -config my_config_1 -config my_config_2 -config my_config_3 {rest of command}
    which works just fine, and is exactly equivalent to:
      teqc -config my_config_1,my_config_2,my_config_3 {rest of command}
    or
      teqc -config my_config_1,my_config_2 -config my_config_3 {rest of command}
    or
      teqc -config my_config_1 -config my_config_2,my_config_3 {rest of command}
    Notice that a default comma delimiter , is used to separate the different configuration file names if they are used as a single argument after a -config option flag. A comma delimiter was selected since it usually is not a shell metacharacter and is rarely used as part of a file name. If in some circumstance, a comma ends up being part of the name of a input file, then it will be necessary to use the -delim option before that file name is used. For example, suppose that the configuration file called strange,one existed and for some reason either you couldn't or didn't what to rename it to a name that did not include a comma, but you wanted to use it and you didn't know about UNIX ln. Well, to do it, you could use
      teqc -delim= -config strange,one {rest of command}
    Here you have changed the delimiting character to = (equal sign), so now strange,one is interpreted as a single configuration file name, instead of two called strange and one. Be forewarned, however: like most everything else, you only get to change the delimiter character once.

    The same type of scheme works for inputting multiple NAV files for a qc-full run:
      teqc +qc -nav fbar0010.97n -nav fbar0020.97n -nav fbar0030.97n {rest of command}
    is identical to
      teqc +qc -nav fbar0010.97n,fbar0020.97n,fbar0030.97n {rest of command}
    Recall the ordering option hierarchy for configuration files: the files to the left will be processed first. For inputting multiple NAV files with the +qc option, teqc sorts the ephemerides of each SV so there really isn't any need for you to keep to any special ordering, though the initial setup is slightly faster if you adhere to a TOW time-sequential multiple NAV file input.

    Currently, all the target file names at the end of the command line are considered to be part of the single execution of teqc. For example, what should you expect when executing this:
      teqc +qc -nav fbar0010.97n fbar0010.97o fbar0020.97o fbar0030.97o
    You turned on the qc mode with +qc. Since you are supplying a NAV file with -nav this will be a qc-full run. Assuming for a moment that each of the OBS files are for 24 hours (and no errors were encountered), what you will receive is a qc report on for the entire 3-day observation period starting with the first observation on 1 Jan 1997 and ending with the last observation on 3 Jan 1997. (The ephemeris information from fbar0010.97n may be a little out of date by the 3rd, but that's OK for this discussion.) What you will not receive (as teqc is currently implemented) is three separate reports and possibly three sets of plot files, i.e. one report (and set of plot files) for each of the supplied OBS files.

    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.

    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.

    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.

    Splicing with teqc
    Section 14.



    Recall that executing the command
      teqc fbar0010.97o
    basically spews the contents of fbar0010.97o back out to stdout. Suppose you have the RINEX OBS files fbar0010.97o for 1 Jan 1997 and fbar0020.97o for 2 Jan 1997 and you want to combine them into a single RINEX OBS file. It would have been easy if the RINEX standard had been written so that two RINEX files could be simply concatenated to one another to produce a new valid RINEX file, a la the UNIX cat system command:
      cat fbar0010.97o fbar0020.97o > oops0010.97o
    But, alas, the RINEX standard does not allow this sort of obvious simplicity and thus the file oops0010.97o is generally useless.

    However, teqc takes care of the RINEX-idiosyncratic boundary between the two files. Thus
      teqc fbar0010.97o fbar0020.97o > good0010.97o
    or using regular expressions (most UNIX shells)
      teqc fbar00[12]0.97o > good0010.97o
    produces a valid RINEX file, good0010.97o, with an added comment at the boundary: 
    
RINEX FILE SPLICE                                           COMMENT
    (Note: This splice comment occurs only in a spliced RINEX OBS file, since the current RINEX standard does not allow for comments after the headers of RINEX NAV and RINEX MET files.) Multiple files can be spliced together and any of them can be for any session length. However, the order (like always) must be time-sequential. Header information from files after the first on are winnowed to preserve only pertinent parts, and this can be further reduced by including the -phc = delete post-header comments option, e.g.
      teqc -phc fbar00[12]0.97o > good0010.97o
    Receiver clock reset information is not carried across the splice boundary of RINEX OBS files. Thus if there are millisecond receiver clock resets in the first file OBS file, and the second OBS file has these millisecond resets initialized back to zero, there will be a n-millisecond receiver clock jump at the boundary of the OBS splice.

    If desired, you can combine the window and splice operations in a single command. Use any of the windowing options in combination with the splice procedure.

    Translating with teqc
    Section 15.



    teqc is being enhanced to handle a number of native binary formats from various receivers. For now, teqc handles common formats for many dual-frequency (L1 and L2) and a few single-frequency (L1) receivers. The general use of teqc for all native binary formats is similar. You need to specify three things:
    1. the general type of receiver
    2. the general type of native binary format from this receiver,
    3. what you are interested in extracting.
    (The big-endian/little-endian problem of the different binary formats is automatically handled by teqc, so don't worry about it.)

    Teqc also reads non-native formats, at the present time limited to the RINEX format, the ARGO format, and BINEX. As you have probably already determined, the RINEX format is assumed by default. To force teqc to interpret the input in the other non-native formats, use:
    • -binex for BINEX
    • -rtigs for the IGS RTigs format
    • -soc for the JPL Soc format
    • -argo for the ARGO format
    (Note: there is no corresponding -rinex flag for RINEX since this is always assumed to be the default.)

    For native or receiver specific formats, an option flag may be needed to specify the general type of receiver, and its argument is used to specify the receiver format:
    • -ash for Ashtech
      • d -- B/E/S/D download fileset (B-file required)
      • s -- RS-232 stream format
      • r -- R-file
      • u -- U-file (note: -ash u is always required for a U-file)
    • -leica for Leica
      • lb2 -- LB2
      • mdb -- MDB
      • d -- DS download fileset (OBS file required)
    • -topcon for Topcon
      • tps -- TPS format
    • -javad for Javad
      • jps -- JPS format
    • -nct for Navcom Technology
      • b -- Navcom binary format
    • -tr for Trimble
      • d -- DAT/ION/EPH/MES download fileset (dat file required)
      • s -- RS-232 RT17 stream format
      • tsip -- TSIP
    • -aoa or -jpl for a TurboRogue/TurboStar or Benchmark receiver
      • cb -- ConanBinary
      • tb -- TurboBinary
    • -cmc for Canadian Marconi Corporation
      • allstar -- Allstar format
    • -ublox for u-blox
      • ubx -- UBX format
    • -motorola for Motorola
      • oncore -- Oncore format
    • -rock for Rockwell
      • z -- Zodiac format
    • -ti for Texas Instruments
      • g -- TI-4100 GESAR and BEPP/CORE formats
      • rom -- TI-4100 ROM format
    For translation to RINEX, the user can specify what type file is of primary interest; if none is specified, RINEX OBS is assumed. For example, using either the receiver argument (i.e. format specification) or appending an o onto the end of format specification means to extract OBS by default, and so on:
    • -tr d or -tr -do: translation of Trimble DAT to RINEX OBS
    • -aoa cbn: translation of ConanBinary to RINEX NAV
    • -ash rm: translation of Ashtech R-file to RINEX MET
    Suppose, for example, that the file fbar.bin contains the the Trimble RT17 for GPS week 866, 11 Aug 1996 - 17 Aug 1996 from a Trimble SSE receiver. Then, execute
      teqc -tr s -week 866 +nav fbar2240.96n fbar.bin > fbar2240.96o
    Let's dissect the command line. First the -tr option flag tells teqc that the target file(s) are from a Trimble receiver. The argument to -tr is s (equivalent to just so), which tells teqc that the native format is the RS-232 RT17 data stream and that you want to send translated RINEX OBS to stdout. But the RT17 file fbar.bin, in general, is allowed to contain both record types for both GPS observations and ephemerides. The command line option +nav fbar224.96n tells teqc to dump any ephemeris information in fbar.bin to the RINEX NAV file fbar2240.96n; if there were no ephemeris records in fbar.bin, then fbar2240.96n will be empty after execution is complete.

    If you had had a Trimble *.dat file, fbar.dat, the analogous command line would have been:
      teqc -tr d -week 866 +nav fbar2240.96n fbar.dat > fbar2240.96o
    Now, what about the option -week 866 (or using an alternative format of -week 96:224)? By doing this, you are explicitly telling teqc that the observation data starts in GPS week 866; it may run on into GPS week 867 (or later), but teqc will track this. If you had executed the shorter command
      teqc -tr s +nav fbar2240.96n fbar.bin > fbar2240.96o
    during the week of 11 Aug 1996 - 17 Aug 1996, and your CPU system time had been set corrected, then teqc would have computed the GPS week and used that (after issuing a warning to stderr: recall executing just
      teqc
    is one way for you to find out what GPS week teqc thinks it is).

    Why must the GPS week be specified? It turns out that there is no information in the Trimble RS-232 GPS observation records (and some other native formats) to indicate which GPS week it is from; this is ancillary information that must be recorded external to the contents of the observation records. (There is GPS week information in the Trimble ephemeris records, but there is no guarantee that there will be any ephemeris records in an arbitrary RT17 data segment, let alone an ephemeris record in advance of all observation records. A similar argument applies for Trimble *.dat files: there is no GPS week information in Trimble's DAT observation records--though the GPS week appears in other records which are usually in a *.dat file. Additionally, when using teqc with DAT files as target files--not stdin--teqc will attempt to find a name-matching MES file to help resolve the GPS week problem. But, again, there is no guarantee that a matching MES file is present.)

    Incidentally, the GPS week can be supplied by several formats when using the -week option:
      -week WEEK (WEEK = GPS week, e.g. -week 866)
      -week [YY]YY:DOY (YY = year, DOY = day of year, e.g. -week 96:228 or -week 1996:228)
      -week [YY]YY:MM:DD (YY = year, MM = month, DD = day, e.g. -week 96:8:15 or -week 1996:8:15)
    You can also use a / (slash) as the delimiter instead of a : (colon). Remember: you are specifying the GPS week when the data begins.

    All or part of the RINEX header field PGM / RUN BY / DATE is filled in automatically by teqc during translation. The program field is filled in with the name of the executable (teqc in this case) and its current version number.

    The date is filled in by a query of the system time, and we are assuming that the system time is set correctly. On UNIX systems, this date is UTC, which is then written to the RINEX file. On Microsoft systems, this date may or may not be UTC. For Microsoft Windows 95/98/NT systems, the date should be set according to a specific time zone, or with a known offset between local time and UTC. For these cases, the date obtained should correctly be UTC.

    For Microsoft DOS or Windows (or Windows 95/98/NT/2000/XP, in case teqc cannot determine the OS), teqc will query for the environment variable $UTC_MIN_OFFSET, which if set, should contain the numerical value of minutes that should be added to the system time to yield UTC. The switches between Daylight Saving Time and Standard Time will have to be done manually. If this environment variable is not set, the system time will be queried and put into the date field as "Lcl" = Local time.

    Now examine the command line:
      teqc -tr sn -week 866 +obs fbar2240.96o fbar.bin > fbar2240.96n
    Here the argument to the -tr option flag is sn, i.e. your main interest is the ephemeris information in fbar.bin, which is dumped to stdout as a RINEX NAV file (and here redirected to the file fbar2240.96n). The +obs fbar2240.96o option instructs teqc that if any observation records are encountered in the target fbar.bin, they are to be decoded and written as a RINEX OBS file fbar2240.96o. Again, the option -week 866 is needed to determine the epochs of the observation data, not the ephemeris data.

    Again, the analogous command line for a Trimble *.dat file would be:
      teqc -tr dn -week 866 +obs fbar2240.96o fbar.dat > fbar2240.96n
    If you execute the above commands for the RS-232 file fbar.bin and do not have the environment variables $teqc_OPT or $teqc_CONFIG set (or if you do have them set but they do not contain any -O.* or -N.* header modification options), then you will find that most of the RINEX header fields in fbar2240.96o and fbar2240.96n are blank. Why? Like the GPS week in RS-232 observation records, there are no fields in the Trimble RS-232 data records to hold the type of information that would occupy these RINEX fields. About the only fields that are filled automatically by teqc are those for the initial RINEX VERSION / TYPE record (which are implied), the default WAVELENGTH FACT L1/2 record (implied by the receiver type, in this case), and the # / TYPES OF OBSERV record. However, you can override these blank values by specifying your own -O.* and/or -N.* options using the command line, $teqc_OPT, $teqc_CONFIG, or other configuration files. This is using teqc simultaneously in edit and translate modes.

    The above translation procedure can also be windowed. Currently, though, fast search algorithms have not been written for any binary format, so you must use an explicit windowing (windowing options (6), (7), or (8)) or specify the window delta time from the start (windowing option (2)).

    The translation procedure can also be qc-ed. Here let's assume that you have a Trimble *.dat file called fbar.dat. For the normal type of qc operation, try something like:
      teqc +qc -week 866 [-st 960811000000] +dh 24 -tr d \
                +obs fbar2240.96o +nav fbar2240.96n fbar.dat | more
    where now, stdout will contain what you now expect from a qc-mode execution, but the RINEX OBS file is still being output to the file fbar2240.96o using the option flag +obs. The -st option is optional, indicated by the square brackets. You use the explicit windowing (in this example, windowing option (7) using both the -st option and the +d* option).

    If translating to RINEX OBS, an auto-identification feature of teqc may eliminate the need to specify the input format. The auto-identification feature has been developed for all the above formats except the Ashtech U-file (which always requires -ash u). To make sure that teqc is able to identify a particular file, use the +mdf option. Thus:
      teqc +mdf fbar.dat
    should return
      probable format of fbar.dat: Trimble download
      teqc: ... exiting
    The assumed stdout for any translation is always RINEX OBS. Therefore with the auto-identification:
      teqc -tr d trimble.dat > RINEX_OBS
    can be reduced to:
      teqc trimble.dat > RINEX_OBS
    The auto-identification will work most of the time but is not guaranteed! This is because the auto-identification is based on reading only a small number of bytes (usually only 1-4 bytes) at the beginning of the file. This is probably most useful if you are testing files manually on the command line. For use of teqc in scripts, use explicit receiver/format options.

    To review, there are a few things to remember when using binary data:
    1. You may need to specify the record type of primary interest, e.g. using the -tr option for Trimble data, with a d argument for download (*.dat) format or s for RT17 stream format. If not doing a qc mode, the RINEX file type that corresponds to this record type is dumped to stdout, e.g. if -tr do is used, RINEX OBS file information is dumped to stdout. (For most cases when doing qc mode, qc information is dumped to stdout.)
    2. You should specify the GPS week during which the binary stream starts, or you accept your computer system version of the local time from which the GPS week is computed. For most formats, you might first try leaving off the -week option, though occasionally the record containing the initial GPS week is corrupted, bogus, or missing, and (depending on the situation) teqc might try to use the system time for the GPS week. Additionally, some Trimble MES files have been found that contain strange years like "19116"!.
    3. If doing a qc mode, you must supply some information about the length of the time window of interest, using either the +d* flag, or one of the explicit window options (6) - (8). If doing the former, the time of the first data observation becomes the start time of the window. The partial argument format for the -st and/or -e options also work.
    4. If doing a qc mode, stdout is used to dump a copy of the short report segment. In order to capture the RINEX file type that would have gone to stdout if not doing a qc mode, specify the RINEX file name by using a +obs, +nav, or +met option.
    Specific details, known limitations, etc. (for any problems, contact teqc technical contact for help):

    Special Translator Considerations and Options
    Section 16.



    There are some translator options which are not specific to a particular native binary format. There are
      -L2 to indicate an L1-only (no L2 tracking) receiver
      -P to indicate a P-codeless receiver
    Using these options when needed helps set the default set of RINEX OBS observables. For receivers that are both L1-only and P-codeless, use both -L2 and -P.

    Two useful options that can be used anytime, but are sometimes very helpful prior to translating, are the metadata extractions options +meta and +mds--which also work with RINEX as the target files. For example,
      teqc +meta trimble.dat
    should return a 19-line metadata summary about the Trimble DAT file trimble.dat (assuming that the auto-identify function works correctly). Executing
      teqc +mds trimble.dat
    returns "metadata short"--a shorthand for just the start and end times of the file, plus the file size in bytes. If either of these terminate in a line like:
      week: ####
    this is an indication that you should use the -week option to set the starting GPS week to the indicated value, e.g.
      teqc -week #### +meta trimble.dat
    There are several translator options which are specific to a particular native binary format.

  • Trimble *.dat or RT17 Data Formats
    • There is a set of options to remove half-wavelength phase data (squaring mode) from the translated RINEX OBS file. These are -L1_2 or -L2_2 to remove squared L1 or squared L2, respectively. Of the types of binary data that teqc currently handles, the only types where these flags may be of use is with the Trimble *.dat or RT17 data stream formats.

    Also, when translating *.dat from P-codeless receivers (e.g. SD, STD, SST), you probably will have to use the -P option. This informs teqc that the data has no P-codes, and it performs bit-cleaning on certains flags. Without this bit-cleaning, you are likely to only get the L2 observable.

    When using the newest generation of receivers (e.g. SSE, SSi, 4700, 5700), a few epochs of squared L2 data for a particular SV may be reported. Normally, these epochs are translated with the appropriate bit-1 of the LLI flags added to the RINEX OBS file with the (squared) L2 data (see teqc's handling of wavelength factors for more information). These L2 observables can be entirely removed during translation by using the option -L2_2, i.e. no squared L2 data is passed to the RINEX OBS file.

    When using a Trimble DAT file as a target file (and not stdin), teqc attempts to find a Trimble MES file with the same path and name prefix. The name matching uses: 
      *dat	->   looks for *mes
*DAT	->   looks for *MES
    If a matching MES file is found, it is read to obtain the starting GPS week and certain metadata (though there is no guarantee that this information is correct).

  • ConanBinary:
    • Teqc should not be used to translate ConanBinary from the early Rogue receivers. The data in this type of ConanBinary is SV-ordered, rather than time-ordered, and teqc will only translate the first SV PRN number of data. (Use JPL translators for this type of ConanBinary.) For ConanBinary from the TurboRogue/TurboStar and Benchmark receivers, teqc will work correctly.

  • TurboBinary
    • TurboBinary data can include normal-rate data (record 0x68), 1-sec rate data (record 0x1a), up to 50 Hz-high-rate data (records 0xdb and 0xdc, plus using information in record 0x1a), and the so-called "30-1 second" format which is a mix of normal-rate data (record 0x68) and 1-sec LC data (record 0xde). The default translation is to do all these record types. However, you can tailor your translation with these options:
      -TBhr
      leave out high-rate data
      -TB1s
      leave out 1-sec data (this also deletes the high-rate data)
      -TBnr
      leave out the normal-rate data
      -TBLC
      leave out the LC data records
    The result of various option combinations is:
       
      (no options = default) translate all records
      -TB1s
      translate only normal-rate data
      -TB1s -TBhr
      (same as -TB1s) translate only normal-rate data
      -TBnr
      translate 1-sec and high-rate data or LC data (whatever is left)
      -TBhr
      translate 1-sec and normal-rate data
      -TBhr -TBnr
      translate only 1-sec data
      -TBLC
      leave out the LC data records, leaving the normal-rate
      -TB1s -TBnr
      translate no observation data (oops!)
      -TBLC -TBnr
      translate no observation data (oops!)
    For TurboBinary data collected with firmware dated before about 1 Dec 92 (version 2.5 or earlier), it is necessary to apply a correction to obtain valid pseudoranges. To activate this correction, use the option +TB_ca_fix.

    For TurboBinary data collected with a Benchmark ACT receiver, you may want to try the -aoa tbY option to generate the RINEX OBS file. This will use the C/A-derived L1-phase value for the RINEX L1, rather than the noisier Y1-codeless derived L1-phase value.

  • Ashtech Data Formats:
    • For all Ashtech formats except the U-file "data mode 7", the internal "smoothing" corrections to the pseudoranges are not applied by default; specify the option +smooth to turn this on. (The pseudorange smoothing appears to be done by default in the Berne ASRINEXO translator and the Ashtech ASHTORIN translator.) For the U-file data mode 7, the pseudoranges are either stored with or without the smoothing corrections applied; there is no way to change this during the translation.

    Also, the RINEX L1 observable from teqc may be noted to vary slightly (by up to 1 cm or so) from the L1 observable reported by other translators. This results from the use of the L1-phase value reported in the P1-code data block, rather than the L1-phase value reported in the C/A-code data block. Preliminary testing at MIT suggests that the L1-phase value in the P1-code data block results in a slightly lower RMS. For the time being, teqc will continue to report this L1-phase value, though you can switch to the L1(C/A) by using the +CA_L1 option.

    For Ashtech download file sets, teqc may only work correctly for "Version: 3" type downloads. For example, the older "Version: 1" and "Version: 2" type downloads will not translate correctly at the present time, and the Berne ASRINEXO or the Ashtech ASH2RIN translators should be used, or try the Ashtech convert.exe program to change the B-file to a Version 3 B-file.

    A bug in the some earlier firmware for the Z-XII resulted in the millisecond clock resets being applied an epoch too late. If you notice periodic millisecond slips (occurring just prior to the reported clock reset times), try using the option +Ashtech_old_clk_reset during translation. This should remove this receiver firmware artifact from the data.

    Wavelength Factors: What teqc Does With Them
    Section 17.



    Wavelength factors, i.e. specifying whether L1 or L2 is being recording in a full-wavelength or half-wavelength (squaring mode), can be done in various ways in RINEX. In short, 1) there is a required RINEX header record WAVELENGTH FACT L1/2 specifying the default wavelength factors for L1 and L2 for all SVs, 2) there can be other WAVELENGTH FACT L1/2 records specifying the a different set of wavelength factors for specific SVs, and 3) there can be the use of bit-1 in the LLI flag of the L1 or L2 observations to indicate the opposite state of wavelength factor from the last WAVELENGTH FACT L1/2 record for a specific SV. The possible set of values for any WAVELENGTH FACT L1/2 record is "1 0", "1 1", "1 2", "2 0", "2 1", and "2 2". Setting bit-1 of the LLI flag indicates a full-wavelength mode if the last WAVELENGTH FACT L1/2 record for that frequency and that SV--somewhere earlier in file--was set at "2" (half-wavelength). Likewise, setting bit-1 of the LLI flag indicates a half-wavelength mode if the last WAVELENGTH FACT L1/2 record for that frequency and that SV--somewhere earlier in the file--was set at "1" (full-wavelength).

    The methodology used by teqc is a simple specific subset of all of the possibilities for RINEX, but still retains all the same information. On output (either when translating from native binary formats to RINEX or RINEX to RINEX), only the default WAVELENGTH FACT L1/2 header record will appear and only the L1/L2 states of "1 1" or "1 0" are used. In other words, the default setting reported in the RINEX file header is always full wavelength for L1 and L2 (if present), even for squaring receivers. Specific half-wavelength observations are indicated by setting the appropriate bit-1 of the LLI flag on the L1 or L2 observations. Period.

    During translation, you have the option of excluding all half-wavelength observations. To do this, include either -L1_2 or -L2_2 to exclude squared L1 or L2, respectively. This works either when translating native binary formats to RINEX or during any RINEX to RINEX operations. The default settings of teqc for wavelength factors are +L1_2 and +L2_2, i.e. include all half-wavelength observations.

    Basic Commands: A Review
    Section 18.



    The following examples assume that the shell environment variables $teqc_OPT and $teqc_CONFIG are unset or empty:
    teqc
    forces all initialization and reports the current GPS week based on the system time
    teqc +id
    identification of the teqc version you have, plus other information like your computer system time, sent to stderr
    teqc -help or teqc +help
    complete option list is spewed to stderr
    teqc +err my_help_file +help
    complete option list is spewed to file my_help_file instead of stderr; +err option redirects all stderr to specified file
    teqc ++config
    dumps the current configuration to stdout
    teqc +qc ++config
    dumps current configuration and default qc settings/values to stdout
    teqc +v RINEX_file
    reads the RINEX file RINEX_file and verifies its format; nothing is sent to stdout, though a verification message is sent to stderr
    teqc ++config RINEX_OBS_file
    dumps current configuration and OBS header settings/values of RINEX_OBS_file to stdout (can use RINEX NAV or MET file also)
    teqc RINEX_file
    reads and spews RINEX_file (with possibly some slight formatting improvements) back out to stdout
    teqc +dh 6 RINEX_OBS_file
    reads and spews header and first 6 hours of observations of RINEX_OBS_file back out to stdout
    teqc RINEX_file_1 RINEX_file_2
    reads and splices the two RINEX files RINEX_file_1 and RINEX_file_2 back out to stdout as a single RINEX file; target RINEX files should be of the same type and in time order
    teqc -O.mo foobar RINEX_OBS_file
    read RINEX_OBS_file and change monument name to "foobar"; edited RINEX OBS file is spewed to stdout
    teqc +qc RINEX_OBS_file
    qc of RINEX_OBS_file; automatically searches for name-matching RINEX NAV file; qc short report segment is spewed to stdout; full qc report and qc plot files written to file system
    teqc ++sym
    symbol hierarchy of symbol codes and associated meanings for qc ASCII time plot are spewed to stdout
    teqc -tr do +nav RINEX_NAV_file trimble.dat
    translate Trimble dat file trimble.dat; RINEX OBS file spewed to stdout; RINEX NAV file written to RINEX_NAV_file
    teqc -warn {rest of command}
    shut off warnings going to stderr; other functionality remains

    Using teqc in Scripts: Substitution for Batch Mode
    Section 19.



    Because teqc is 100% non-interactive, it is very well suited to be used in scripts and to be run in background. In fact, this is precisely the reason it is designed to be 100% non-interactive. Let's look at a simple script to translate Trimble *.dat files to RINEX and then qc the resulting RINEX files: 
    #!/bin/ksh
for file in $*
	do
		echo $file
		teqc -O.int 30 -tr d +nav ${file%dat}97n $file > ${file%dat}97o
		teqc +qc -set_mask 15 -plot ${file%dat}97o > ${file%dat}qc
	done
#end of script
    Make sure the script is executable, i.e. execute (in UNIX)