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 1999 July 19 bug fixes and at 1999 July 19 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.
There is one fundamental change to the behaviour of teqc, and that is its operation as a RINEX-to-RINEX filter, i.e.
The change involves only the RINEX header line PGM / RUN BY / DATE.
Previously, this line would be read in the header of old_RINEX and passed through uneffected to the header of new_RINEX. The problem with this is that teqc is often used to correct other RINEX header information, but in the resultant RINEX file new_RINEX there would be no indication that another program (i.e. teqc) had been used to possibly modify the resultant RINEX.
The new behaviour is that the original RINEX header line PGM / RUN BY / DATE is read and converted into a COMMENT. A new PGM / RUN BY / DATE line is constructed with teqc as the listed program, with a new user and date. (Eventually with later teqc versions, there may also be a comment line added which encapsulates the type of operation(s) the user is performing with teqc.) Also, teqc now takes total control over setting over setting of the new program name and date; the options -O.pr[ogram], -O.d[ate], -N.pr[ogram], -N.d[ate], -M.pr[ogram], and -M.d[ate] are being obsoleted and will no longer function. Please remove them from any scripts, teqc configuration files, or other driver software that you may have.
There are numerous enhancements to RINEX in the 2.10 specification. Teqc is not yet compatible with all of the approved items, but the following 2.10 items are recognized in this version of teqc:
The following 2.10 items are not yet recognized in teqc:
There were several errors introduced into the last official version of teqc when using it to splice two or more RINEX files together, e.g.
Hopefully, all of these problems have been resolved. If you feel that teqc is still not splicing RINEX properly on your system, please contact teqcunavco.org.
Keeping a consistent set of options and their default values is a major design goal of teqc. But now and then, changes are deemed necessary for the overall improvement of operation and functionality. This release has the largest set of changes:
As usual, there are always new options being added. Some of the more notable are:
RINEX L1 = L1(CA) RINEX L2 = L2(Y2) RINEX P1 = Y1 RINEX P2 = Y2 + CA - Y1
Also, 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. (Note: The design will probably be changed in the next release, so that PBEN records will not necessarily have to follow each epoch's worth of MBEN records.)
When translating B-files for the GG24, the teqc options -P -L2 +msec_phs_adj -max_rx_ch 24 -max_rx_SVs 24 are now automatically set if the first characters of the receiver code in the B-file matches "GG24" or "G-XXIV". Otherwise, you must continue to include these settings to correctly translate a GG24 B-file.
Various experimental options can be used to translate Benchmark ACT TurboBinary 0x68 records to RINEX. These options effect everything but the P1 observable, and are explained in the resulting RINEX OBS header in COMMENT header lines.
There are four different ways to translate TurboBinary (0x68 records) from a Benchmark with teqc. For all of these, the Y-codeless pseudoranges are labeled as P1 and P2 in the RINEX OBS file, and any subsequent process will respond to these as if P-code tracking had taken place:
During processing of CMC binary files from the Allstar OEM, we discovered that using just the information in record 23 results in the L1 phase values being out of sync from the time tags and C/A pseudoranges. This can now be corrected with teqc by outputting records 21 and 23 at each epoch, in which case the C/A pseudorange and time tag are adjusted to coincide with the sampling of the L1 phase value at each epoch.
For some uses, and for some processing software (e.g. Bernese) the RINEX produced with just record 23 is sufficient.
Translation of Leica DS format using teqc has been mostly available for almost two years, but some final minor translation issues have only recently been been settled on, so this will be the first official release with support for reading/translating the Leica DS fileset format. Please see an example.
Starting with any release on or after 17 May 1998, the receiver and antenna (with or without radome) designations supplied with the -O.rt and -O.at options are tested against the current (8 May 1999) IGS designations (in the ASCII file rcvr_ant.tab.text12). To obtain a complete listing of the new IGS ASCII codes, execute
There have been numerous inquiries about the Y2K compliance of teqc. Simply put, teqc has been designed from the start to handle time from 1 Jan 1980 - 31 Dec 6075. Any dates outside of this range are deemed invalid. (Actually, GPS time has a zero time at 6.0 Jan 1980, but the teqc algorithms "allows" dates back to 1.0 Jan 1980 so that the year 1980 doesn't have to be treated as a special case).
Two-digit years (as in RINEX) are interpreted based on a 100-year window, starting at a "base" year. The default base year is 1980, e.g. the years "80-99" are interpreted by default to be 1980-1999 and the years "00-79" are interpreted by default to be 2000-2079. Starting in 2080, any version of teqc would still be usable by using the -base option and setting the base year to an appropriate value.
Thus, the transition from 1999 to 2000 should not poise any problems.
On 22.0 Aug 1999, the GPS week number becomes 1024. However, the broadcast ephemeris for each GPS satellite only allows 10 bits for the GPS week (i.e. GPS week 0 - 1023). So on 22.0 Aug 1999, the broadcast ephemeris representation for the GPS week gets reset to "0".
The representation of the GPS week in RINEX NAV files, according to the RINEX specification, should be 1024 and should not be reset to 0 on 22.0 Aug 1999. Depending on the format in question, this is either a responsibility of the receiver, the translation software, or some combination of the two. Translation using teqc should work correctly on and after 22 Aug 1999 as long as the -week option is used correctly, and in many cases this option will probably not be needed. A general method of dealing with data before and after the GPS week 1024 rollover will be an ongoing task in the next few months as real data samples are obtained. If you encounter a format that used to work correctly with teqc before 22 Aug 1999, but no longer does so, please be prepared to send one or more sample files to Lou Estey at UNAVCO.
Since May 6, a group in the Swiss Federal Office of Topography (Bundesamt fuer Landestopographie) has been testing a AIX 4.1 build of teqc. This group also hosts the development platform on which this build of teqc is compiled. With this release, teqc will now be officially available as an AIX executable.
The Linux RedHat build for PCs has so far only been available as a dynamically-linked build. This has caused numerous problems for users where there was a library inconsistency between our systems and their system. To help eliminate those problems, the Linux build for PC processors with no also be available in a statically-linked build. If the dynamically-linked Linux build of teqc doesn't work for you, please try the statically-linked one.
Finally, the Big Bug that I knew would occur some day: inconsistency of C/C++ data type sizes. This effects the translation functionality of only DEC Alpha OSF1 build at this time. (The other functionalities of the DEC Alpha OSF1 teqc build are uneffected.) A fix for the Big Bug will hopefully be implimented in the next release.
Unfortunately, I was not able to complete the update of teqc documentation pages (e.g. FAQs, tutorial), so there is a growing disconnect between the original documentation and the current capabilities of teqc. (It was much more important to get this release out in advance of the GPS week 1024 rollover on 22 Aug 1999, than to focus on the documentation for this release.) 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 by the next major release, which will probably be in early 2000.
Last modified: 2019-12-24 02:29:42 America/Denver