Software Help with Software Data Processing Data Management Visualization Geodetic Utilities

TEQC 7 Jan 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 Jan 7 bug fixes and at 1999 Jan 7 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

Ashtech translation issues:

Translation of Ashtech B/E/S filesets or RS-232 stream data continues to be done as before, including GLONASS data from the Z-18 or GG24 receivers (see general Z-18 and GG24 translation issues), except:

  • GPS SV health code for GPS RINEX NAV now using the correct bit, i.e. 0 = good general health, 1 = unhealthy
  • conformance of GLONASS RINEX NAV to documented and undocumented (personal communication w/ Werner Gurtner) RINEX specifications
  • phase values greater than 5000000000.000 or less than -500000000.000 are adjusted by subtracting out a constant integer number of cycles so that the ASCII phase value fit in the %14.3lf (Fortran F14.3) RINEX observable field (also see +reformat option below)
  • after 30 Sept 1998, all "questionable" carrier phase or code phase values are suppressed during translation if the appropriate bit of the warning flag is set (before 30 Sept 1998, the bit settings of the warning flag were ignored)

Reading misformatted RINEX OBS files:

Due mainly to the Ashtech Z-18 and GG24 firmware which was allowing the magnitude of L1 and L2 phase values to get very large, teqc and several other translators were creating misformatted RINEX OBS files, i.e. the phase values were not fitting in the %14.3lf (Fortran F14.3) field. Hence the ASCII representation of the observable might be %15.3lf or even %16.3lf.

Using the new +reformat option, certain RINEX OBS files can now be read and used with teqc. The requirement is that the observable plus LLI flag plus SN code be of the format %n.3lf%c%c, where n > 3, the LLI flag is ASCII 0-7 or blank, and the SN code is ASCII 0-9 or blank. If the misformatted observable is an L1 or L2 phase value, then a new RINEX file can be output which subtracts out a constant integer number of cycles so that it will fit within the %14.3lf field.

In other words, if you have a RINEX OBS file where the phase values are greater than 9999999999.999 or less than -999999999.999: 

	teqc +v old_RINEX_obs
teqc: { some reported problem }
	teqc +reformat old_RINEX_OBS > new_RINEX_obs
	teqc +v new_RINEX_obs
teqc: new_RINEX_obs matches RINEX V.2 format

SV and Channel editing:

Teqc can now be used to edit out certain SV numbers or channel numbers. For example, if you have a mixed GPS/GPONASS RINEX OBS file, you can create a pure GPS RINEX OBS file: 

	teqc -R mixed_RINEX_OBS > GPS_RINEX_OBS
or create a pure GLONASS RINEX OBS file: 
	teqc -G mixed_RINEX_OBS > GLONASS_RINEX_OBS
(Note: The RINEX headers, for the time being, will show both GPS_RINEX_OBS and GLONASS_RINEX_OBS in the above examples to be of mixed type, as in the original file mixed_RINEX_OBS. Also, the time base will stay in GPS for both.)

Specific SVs can also be edited out. For example, 

	teqc -R10,16 -G2 mixed_RINEX_OBS > new_RINEX_OBS
eliminates only GLONASS #10 and #16 and GPS #2.

If translating from an appropriate binary receiver format, data for specific channels can also be removed, e.g.: 

	teqc -aoa cb -ch1 -G2 foobar.cmp > RINEX_OBS
will remove any data for channel 1 (regardless of which GPS SV) and also will remove any data for GPS #2 (regardless of which channel) of the ConanBinary file foobar.cmp.

Benchmark -> TurboRogue TurboBinary:

An experimental option -aoa bs can be used to translate Benchmark ACT TurboBinary 0x68 records to RINEX in such a way that the observables in RINEX OBS will be commensurate with what would have been collected with a TurboRogue receiver. This effects only the P2 and L2 observable, and is explained in the resulting RINEX OBS header, and causes the C/A-derived phase value to be used as L1 (as is done with the Benchmark translation option -aoa tbY). (The option -aoa tbY need not be set when using -aoa bs, as this part is automatically set when -aoa bs is used.)

This means that there are three 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:   replaces the Y1-codeless-derived phase with the C/A-derived phase for RINEX L1:
    • RINEX L1 = L1(CA)
  • -aoa bs:   uses C/A-derived phase for RINEX L1:
    • RINEX L1 = L1(CA)   (identical to -aoa tbY option)
    plus:
    • RINEX L2 = L2(Y2) + L1(CA) - L1(Y1)
    • RINEX P2 = Y2 + CA - Y1

IGS Receiver and Antenna Designations:

Starting with on 15 July 1998, the receiver and antenna designations supplied with the -O.rt and -O.at options have been tested against the original sanctioned IGS designations (in the ASCII file rcvr_ant.tab). Following the November 1998 IGS Infrastructural meeting, there has been an effort underway to update this list, and was preliminarily released on 24 Dec 1998 and 6 Jan 1999, including older and newer receivers and antennae for AOA, Trimble, Ashtech, and Leica, plus adding designations for JPS, 3SNavigation, and Topcon equipment. Designation tests based on these additions have now been added to teqc when using the above options.

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.

In short, 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. A general method of dealing with this problem has not been found for all formats currently read by teqc and solving this problem will be an ongoing task in the next few months.

 

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