Software Help with Software Data Processing Data Management Visualization Geodetic Utilities

TEQC 29 Feb 2000 Release Notes

Select your favorite build of teqc in the usual way, but be sure to save your current version in case any new bugs show up. Other information on these and other minor bug fixes and enhancements can be found at 2000 Feb 29 bug fixes and at 2000 Feb 29 release log, plus any notices since the last release you have:

If you are unfamiliar with teqc, please also see the teqc homepage. Indexes for this release are:

Recall that all teqc email traffic will now be handled via a teqc on-line email forum, teqcunavco.org, to which users can subscribe/unsubscribe. This will continue to be an unmoderated email forum.

--Lou Estey

RINEX 2.10 compliance:

In addition to the RINEX 2.10 enhancements that teqc has able to handle in the last (19 July 1999) release, i.e.

  • fractional RINEX version number
  • zero-padding of two-digits year values (for 2000-2009)
  • recognition of two-digits years "00"-"79" as 2000-2079
  • increase of second resolution in TIME OF FIRST OBS header line in RINEX OBS
  • non-integer values in INTERVAL header line in RINEX OBS
  • comments after event flags 2-5 in RINEX OBS files
  • default wavelength factor header line in RINEX OBS
  • recognition of RINEX OBS observables S1 and/or S2
  • curve fit interval value in GPS RINEX NAV
  • adjustment of transmission time of message (ToW value) in GPS RINEX NAV
  • recognition of RINEX MET observables ZD and/or ZT

the 29 Feb 2000 release should be fully 2.10 compliant with the additional:

  • ability to recognize the RINEX OBS header line RCV CLOCK OFFS APPL
  • inclusion of extra GPS SV health information in GPS RINEX NAV (upon translation from native format to RINEX) for all formats that contain the extra GPS SV health information
  • 2.10 enhancements for reading and writing RINEX with GPS-like ranging from geostationary satellites and coresponding navigation information

Important note: I think I have the code written correctly for the extraction of the GPS SV health, but this needs to be tested with some data files which include an unhealthy GPS satellite. There are currently four cases in the teqc code:

  • Ashtech SNV stream record and Ashtech E-file
  • Trimble 0x55 stream record and Trimble record 21
  • Trimble 0x58 TSIP record
  • everything else (except Leica formats)

If you find a problem with any of these cases, please contact teqcunavco.org. (The Leica download file dsXXXX.eph and the LB2 record 0x88, ephemeris data block, do not contain the extra health bits and will continue to just report a value of 1 for the health state of an unhealthy SV.)

Dropped builds:

For various reasons, teqc will no longer be compiled for the following operating systems:

  • SunOS 4.1.1 through 4.1.3
  • HP-UX 9.03
  • SGI IRIX 5.3

The Solaris build of teqc will now be done on a Solaris 2.7 machine, and this executable had been tested on Solaris 2.3 and higher with no problems.

The HP-UX 10.20 build of teqc will continue to be available.

If you need a teqc for SGI IRIX, you should contact contact teqcunavco.org and be prepared to host the development site. (Use of secure shell ssh, secure copy scp, and Korn shell ksh is preferred.)

Splicing fixes:

The last known splicing problem, i.e. the splicing of RINEX OBS files were the 41st character of the RINEX VERSION / TYPE line was whitespace (instead of the now preferred "G", for a GPS-only RINEX OBS file), has been corrected. Hopefully, all slicing problems have been resolved. If you feel that teqc is still not splicing RINEX properly on your system, please contact teqcunavco.org.

Translation to RINEX MET:

Teqc should now be able to read and translate into RINEX MET data from:

  • Ashtech D-file
  • Ashtech RS-232 stream data (NEMA $GPXDR records)
  • Trimble DAT records 9 and 20 (binary)
  • Trimble DAT record 16.254 (NEMA-like ASCII)
  • Leica dsXXXX.met file

and other formats (like the Trimble RS-232 stream format, record 0x57, record type 3, MET3) should be able to be added quickly as example files become available. The extraction of RINEX MET can be done by one of two ways, here using the Ashtech download fileset as an example. Assuming a D-file exists in the same directory as the B-file, use

  • teqc -ash d +met RINEX.met B-filename > RINEX.obs
  • teqc -ash dm B-filename > RINEX.met

and similiar sorts of command line constructs.

Certain formats (e.g. Ashtech RS-232 stream data) may require the use of the new option -M.int to correctly specify the MET sample interval in cases where the MET sample interval is less than the GPS/GLONASS sample interval (since these formats do not provide a unique MET time tag for the time of MET observation).

Decimation of the MET data is achieved by using -M.dec, analogous to the -O.dec option.

New options in teqc:

As usual, there are always new options being added. Some of the more notable are:

  • +mdf: "metadata: format"; reports the probable or possible format of a given file; this option shows what the default translation behaviour of teqc will try to use to read the input file.
  • -M.int and -M.dec: see MET above
  • +Ashtech_B_file_adjust: attempts to reads certain kinds of corrupted Ashtech B-files by using the 4-char ID as a file positioner; has helped read certain corrupted B-files (don't use this option unless you suspect your B-file really is corrupted!)
  • +eepx: in qc mode, an epoch-by-epoch calculation of the gross pseudorange point position in WGS84 ellipsoidal Cartesian XYZ coordinates (in meters)
  • +eepg: in qc mode, an epoch-by-epoch calculation of the gross pseudorange point position in WGS84 ellipsoidal geographic coordinates (lat, lon, height)
  • -NaN_obs: to eliminate, on an epoch-by-epoch basis, any SV which has certain observables which are "not-a-number" (the only know cases where data equal to "not-a-number" has been found is in some recent TurboBinary data; see 2000 Jan 27 in the teqc log for more information); this option has only been tested on Solaris, DEC Alpha, and Linux executables
  • -S and +S: filtering analogous to the SV filtering options with G and R, except S is for geostationary signal payload SVs
  • +pl: in qc mode, calculation of a new linear combination "pseudorange - phase", in meters, for L1 and L2 if possible; a prototype for a single-frequency qc; currently, only produces the extra plot files *.pl1 (for L1) and *.pl2 (for L2); see 2000 Feb 8 in the teqc log for more information.

Changed options in teqc:

The option +help outputs the same stuff as the old teqc help, except that it now is output to stdout instead of stderr (since the old behaviour was causing bouts of insanity in some UNIX csh users).

The only significant change in options is the meaning of the +v option when used with a RINEX file, e.g.

  • teqc +v RINEX.obs

where, if teqc was able to successfully parse through the file RINEX.obs, you will get a stderr message something like:

  • teqc: RINEX.obs readable as RINEX V.2.00 format

At this point, you have to understand a little of what teqc is trying to do. By default and if possible, teqc would try to convert the input file(s) into the latest RINEX standard, which is now 2.10. (Using the +v option suppresses the output as RINEX.) In most all cases, there is no forward compatibility problem with RINEX, i.e. files of version 1 or 2 (or 2.01) are easily convertable to RINEX 2.10.

There is one situation where there is a problem, and that is with the WAVELENGTH FACT L1/2 header line(s). Like RINEX 2.10, teqc requires that there be a default WAVELENGTH FACT L1/2 header line, preceding any optional SV specific WAVELENGTH FACT L1/2 header lines. Some translators do not produce RINEX OBS files with the now required default WAVELENGTH FACT L1/2 header line, which makes these files fail with the +v option. The only solution is to edit the file and insert the required default WAVELENGTH FACT L1/2 header line before any of the SV specific WAVELENGTH FACT L1/2 header lines.

Ashtech translation issues:

Still for Ashtech stream translation with MBEN/PBEN records: the current design of teqc assumes that a PBEN ($PASHR,PBN,) record will follow each set of MBEN records for each epoch. If the PBEN record is absent, teqc will not function correctly.

CMC Allstar binary translation issues:

We have discovered that even when using both records 21 and 23, there is still a small clock drift (on the order of 1e-9) that is not removed from the time tags and pseudorange measurements by teqc. Consequently, there is a disconnect between the phase and pseudorange measurements that grows on the order of 1e-9 sec/sec. We have not determined any reliable numerical means to remove this drift from the translation process.

Rockwell Zodiac translation issues:

(Major Ooops.) It was pointed out by John Galvin that I was really screwing up the interpretation of unsigned 6-byte integers in record 1102, which was causing teqc to output totally bogus values for the L1 phase and C/A pseudorange. This has now been completely corrected. (Many thanks to John for pointing this out in laborous detail!)

IGS Receiver and Antenna Designations:

Starting with any release on or after 26 Feb 2000, the receiver and antenna (with or without radome) designations supplied with the -O.rt and -O.at options are tested against the current (27 Oct 1999) IGS designations (in the ASCII file rcvr_ant.tab). To obtain a complete listing of the new IGS ASCII codes, execute

  • teqc ++igs

W1K (22.0 Aug 1999), Y2K (2000 A.D.), Leap Day 2000 (29 Feb 2000):

The first GPS week rollover (W1K) on 22.0 Aug 1999 and the transition to 2000 A.D. (Y2K) presented no problems for teqc. There also should be no problems for the once-every-400-year leap day on 29 Feb 2000. (Now there should be nothing to worry about until the second GPS week rollover, W2K, on 7.0 Apr 2019!)

Statically-linked DEC Alpha build for Linux:

Now, both a dynamically- and statically-linked build on the DEC ALpha is available, both compiled under UNIX OSF1. The statically-linked build has been minimally (though successfully, so far) tested on the DEC Alpha running Linux. You are welcome to give it a try.

The 64-bit Bug:

The bug involving the sizes of C/C++ data types on 64-bit processors (e.g. DEC Alpha) has been basically solved. There might be a few lingering latent problems, so if you find a different functionality on a 64-bit processor than what is observed on a 32-bit processor, please contact teqcunavco.org.

Documentation changes:

Unfortunately, I was still not able to complete the update of teqc documentation pages (e.g. FAQs, tutorial), so there is still a growing disconnect between the original documentation and the current capabilities of teqc. You will have to continue to pay attention to these release pages, plus keeping up-to-date by looking at:

I hope to have the documentation updated some time in 2000.

 

Last modified: 2019-12-24  02:29:43  America/Denver