Software Help with Software Data Processing Data Management Visualization Geodetic Utilities

TEQC 19 July 1999 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 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.

--Lou Estey

New teqc behaviour<:

There is one fundamental change to the behaviour of teqc, and that is its operation as a RINEX-to-RINEX filter, i.e.

  • teqc {options} old_RINEX > new_RINEX

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:

  • 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 following 2.10 items are not yet recognized in teqc:

  • RINEX OBS header line RCV CLOCK OFFS APPL
  • extra GPS SV health information in GPS RINEX NAV (upon translation from native format to RINEX)
  • all 2.10 enhancements for GPS-like ranging from geostationary satellites and coresponding navigation information

Splicing fixes<:

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.

  • teqc RINEX_1 RINEX_2 > RINEX_all

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.

Option changes in teqc<:

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:

  • Obsoleted options:
    • -O.pr[ogram]
    • -O.d[ate]
    • -N.pr[ogram]
    • -N.d[ate]
    • -M.pr[ogram]
    • -M.d[ate]
  • Changed options:
    • Ashtech_CA_L1 is now just CA_L1; default is still -CA_L1, i.e. "use L1(P1) if found as RINEX L1, rather than L1(CA)"; to use L1(CA) as RINEX L1, use +CA_L1
    • options TBhr, TB1s, and TBLC now are set off by default (i.e. -TBhr, -TB1s, and -TBLC) rather than on, i.e. only the normal-rate observables in TurboBinary record 0x68 are processed by default now; you must now explicitly use +TBhr, +TB1s, and/or +TBLC to activate reading of the non-standard observable records

New options in teqc<:

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

  • +mds: "metadata short"; like +meta, except this outputs the start and end times, file size in bytes, and file name all on one line (seconds of the times are truncated to integer seconds); very handy (I use it all this time!)
  • -tBX: new special option for translation of Benchmark ACT TurboBinary: 
    			RINEX L1 = L1(CA)
			RINEX L2 = L2(Y2)
			RINEX P1 = Y1
			RINEX P2 = Y2 + CA - Y1
  • ++igs: output latest IGS ASCII designations for receivers, antennae, and radomes; then teqc terminates
  • phc: "post-header comments"; used when splicing RINEX; set to +phc by default (i.e. "include all post-header comments"); using -phc will ignore all comments after the first RINEX header has been read (This was introduced when splicing 96 15-minute RINEX OBS files into a single 24-hour daily RINEX file, where each original 15-minute RINEX OBS file was loaded with the same RINEX COMMENT fields.)
  • TBfe_ff: for translation of TurboBinary files; set to +TBfe_ff by default (i.e. "use TurboBinary header/trailer records 0xff and 0xfe"), which will cause teqc to abort the file when the first occurrance of the trailer record 0xfe is found (this is the original behaviour of teqc); but, if concatenating two or more TurboBinary files into a single TurboBinary file (say, hourly files into one daily files), this is not the desired effect when reading the concatenated file, so set -TBfe_ff (i.e. "ignore TurboBinary header/trailer records 0xff and 0xfe")
  • binex: for inputting and outputting BINEX (see the Web page if you're interested)
  • -ns and -ne: new start and end windowing options, though the mnemonic is "next start" and "next end": Here's how it works. Suppose your file (native, RINEX, or BINEX) starts on 1999 July 19 18:51:03, and you want the 15-minute file that starts at 19:00:00 and goes until 19:14:59.9. With the original teqc time-windowing, you would have to specify -st 19:00:00 -e 19:14:59.9, i.e. a time "mask" out to the hour level. Now you can accomplish the same thing with -ns 00:00 -ne 14:59.9. Additionally, suppose you specified -ns 45:00 -ne 59:59.9. This would internally first calculate the window to be from 19:45:00 to 18:59:59.9, in other words, with the start time after the end time, which isn't too helpful. In this case, since you are using -ns to the minute level, teqc backs up the hour so that the start time comes before the end time. In other words, in this example -ns 45:00 -ne 59:59.9 will give a time window of 18:45:00 to 18:59:59.9, so your resulting time window on the resulting RINEX file would be 18:51:03 to 18:59:59.9 (since the input RINEX file started at 18:51:03).

Ashtech translation<:

(See also Ashtech translation issues and Z-18 and GG24 translation issues.) We might be getting closer to the final answer about the Ashtech "warning flag" byte. Now:

  • use +CA_L1 (rather +Ashtech_CA_L1, which has been obsoleted) to extract L1(CA), instead of L1(P1), as RINEX L1
  • by default, all phase data is accepted as "good", regardless of the value of bit_2 (carrier phase questionable) of the warning flag
  • by default, all pseudorange data is accepted as "good" only when the value of bit_3 (code phase questionable) of the warning flag is zero
  • if you still have problems (don't see any data), set +Ashtech_qd (i.e. "output all Ashtech data values, even if questionable data")

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.

Benchmark ACT TurboBinary translation<:

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:

  • -aoa tb:   this gives the default Y1-codeless and Y2-codeless observables which are equivalent to the observables obtainable from the receiver if using ConanBinary:
    • RINEX L1 = L1(Y1)
    • RINEX L2 = L2(Y2)
    • RINEX P1 = Y1
    • RINEX P2 = Y2
  • -aoa tbY:
    • RINEX L1 = L1(CA)
    • RINEX L2 = L2(Y2)
    • RINEX P1 = Y1
    • RINEX P2 = Y2
  • -aoa bs:
    • RINEX L1 = L1(CA)
    • RINEX L2 = L2(Y2) + L1(CA) - L1(Y1)
    • RINEX P1 = Y1
    • RINEX P2 = Y2 + CA - Y1
  • -aoa TBX:
    • RINEX L1 = L1(CA)
    • RINEX L2 = L2(Y2)
    • RINEX P1 = Y1
    • RINEX P2 = Y2 + CA - Y1

CMC Allstar binary translation<:

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.

Leica DS format translation<:

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.

IGS Receiver and Antenna Designations<:

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

  • teqc ++igs

Y2K (2000 A.D.) Compliance Statement<:

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.

W1K (22.0 Aug 1999) Statement<:

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.

IBM AIX build<:

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.

Statically-linked Linux build<:

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.

The Big Bug<:

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.

Documentation changes<:

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