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.
In addition to the RINEX 2.10 enhancements that teqc has able to handle in the last (19 July 1999) release, i.e.
the 29 Feb 2000 release should be fully 2.10 compliant with the additional:
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:
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.)
For various reasons, teqc will no longer be compiled for the following operating systems:
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.)
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.
Teqc should now be able to read and translate into RINEX MET data from:
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
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.
As usual, there are always new options being added. Some of the more notable are:
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.
where, if teqc was able to successfully parse through the file RINEX.obs, you will get a stderr message something like:
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.
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.
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.
(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!)
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.text18). To obtain a complete listing of the new IGS ASCII codes, execute
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!)
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 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.
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: Saturday, 10-May-2014 23:05:49 UTC