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. There are a number of significant issues relating to this release of teqc, indexed below. Other information on these and other minor bug fixes and enhancements can be found at 1998 July 1 bug fixes and at 1998 July 1 release log.
The following items are being actively worked on, and hopefully will make it in the next release:
The following items are seriously being considered:
In addition, all teqc email traffic will now be handled via an on-line email forum, teqcunavco.org, to which users can subscribe/unsubscribe. This will become a moderated email forum (moderated by yours truly) if advertisements, commercials, jokes, etc. start being sent to teqcunavco.org — which will then only annoy me, but not anyone else.
Finally, the teqc homepage, and the main teqc documentation, have not yet been updated to reflect all of the current teqc additions. So please be patient.
--Lou Estey
An important bug fix for translation to RINEX NAV for ConanBinary, TurboBinary, Canadian Marconi binary, and TI-4100 GESAR Record 9 for builds on big-endian processors (e.g. Solaris Sparc, HP-UX PA-RISC, IRIX, DEC Alpha): Prior to 26 Jan 1998, a bit-error was present which caused the af0 (SV clock bias), URA (SV accuracy), and the "codes on L2 channel" values in the RINEX NAV file to be wrong.
A bug prior to 26 Jan 1998 caused a missed epoch of data and cycle slips to occur at each join of multiple ConanBinary files using the following syntax:
teqc -aoa cb {options} *.cbThis was noticed when processing 24 hourly files combined into a single daily file.
The TurboBinary interpreter for 0x68 records has been modified to read non-standard "long" 0x68 records, which contain two additional floats for D1 and D1/dt. A pseudo-D2 is computed (from D1) if requested.
ConanBinary and TurboBinary now use the same algorithms for determing SNRs. This will have no effect on the RINEX observables S1 and S2, which have and will continue to show volts of signal per volts of noise. The algorithm change will only have a small effect on the RINEX snr 0-9 values shown for TurboBinary L1 and L2.
Several translators (notably, Leica SKI for Leica 300 DS format) occasionally produce values of "60.0000000" seconds in the RINEX time tag slot. Teqc will now read these values and not complain. Even better, if you use teqc as a RINEX-to-RINEX filter, the filtered RINEX will have these values reduced to "0.0000000" with the appropriate changes to the minute, hour, day, month, and/or year values as needed. (A strange artifact of the improved algorithm is that the seconds need not be bounded by [0., 60.], assuming that the values for minutes, etc. are appropriately correct. Try hand-editing a time tag of "30 30.0000000" (30 minutes, 30 seconds) to "29 90.0000000" (29 minutes, 90 seconds) and running this through the new teqc. It will be converted back to "30 30.0000000".)
An indexing bug (--I forgot in one spot that C indexes start at zero, rather than one--) caused the qc-mode of data containing GPS SV 32 to die or do an inaccurate ion slip count. Fortunately, data for SV 32 should only occur between 11 Dec 1992 and 28 Jan 1993 (as of June 1998). But this is also why this qc bug took so long to discover!
Herb Dragert (dragertpgc.nrcan.gc.ca) discovered that the new AOA Benchmark ACT receiver produces TurboBinary that, if translated in the conventional way, uses the Y1-codeless derived L1-phase value that is 50% noiser than the C/A-derived L1-phase value. Consequently, teqc has been modified to accept the following
teqc -aoa tb {rest of command}for conventional (TurboRogue/TurboStar) TurboBinary translation, or
teqc -aoa tbY {rest of command}to translate Y*-codeless TurboBinary from the Benchmark ACT, using the C/A-derived L1-phase value for the L1 RINEX observable.
Various bugs related specifically to translation of Ashtech download files have been fixed:
Some users have noticed that the RINEX L1 values reported by teqc from Ashtech downloads are slightly different than the RINEX L1 values reported by Berne's ASRINEXO or by Ashtech's ASHTORIN. This has been traced to teqc extracting the L1-phase value from the P1-code data block, whereas the others extract the L1-phase value from the C/A-code data block. Preliminary high-precision solutions done by Simon McClusky at MIT (simoneverest.mit.edu) suggests that the L1-phase in the P1-code block produces a lower RMS. So, for the time being, teqc will continue to extract the L1-phase value from the P1-code block.
The original teqc Ashtech download translation was specifically tailored for the Z-XII receiver. However, teqc should now work for the LM-XII receiver, which is P-codeless and has L2-squared. For a B-file from the LM-XII, use:
teqc -ash d -P {other options} BfilenameThis should be considered in a beta test mode.
The original teqc Ashtech stream translation was specifically tailored for the Z-XII receiver. However, teqc should now work for the G-XII receiver, which is L1-only and P-codeless. For a stream-file from the G-XII, use:
teqc -ash s -P -L2 {other options} stream_filenameThis should be considered in an alpha test mode.
Note: One test file from a G-XII with a sampling interval of 1 second had a large number of MBN and PBN records which had an invalid checksum, though the data seemed to be OK when the checksum requirement was ignored. For this release of teqc, the checksum requirement is in place. If you notice few or no epochs are translated by teqc, this may be the problem.
Teqc will now translate Leica LB2 format, used for example in the Leica MC1000, CRS1000, and CRS1500 receivers, into RINEX OBS and NAV (no MET yet). Currently, the translation uses information only in records 0x01, 0x02, 0x03, 0x09, 0x85, and 0x88. (Other records are identified and skipped.) Like data from some other formats, there may be a GPS week ambiguity, so use of the -week option is encouraged. The general formats for translation to RINEX is:
teqc -leica lb2 {other options} lb2_filename > RINEX_OBS teqc -leica lb2 {other options} +nav RINEX_NAV lb2_filename > RINEX_OBS teqc -leica lb2n {other options} lb2_filename > RINEX_NAV teqc -leica lb2n {other options} +obs RINEX_OBS lb2_filename > RINEX_NAVand so on. This should be considered in a beta test mode.
Teqc will now translate ARGO format files into RINEX. Assuming the presense of an ARGO .dat file and a .orb file, try:
teqc -argo {other options} argo.dat > RINEX_OBS teqc -argo {other options} +nav RINEX_NAV argo.dat > RINEX_OBS(Note: -argo is used instead of +argo because the input, not the output, is in ARGO format.) The current set of possible RINEX observables are L1, L2, P1, P2, S1, S2. This should be considered in a beta test mode.
If you use teqc with filenames (i.e. not stdin), you may want to try a new auto-identification feature that, in most cases, eliminates the need to specify the receiver/format option. The assumed stdout is always RINEX OBS. Therefore:
teqc -tr d trimble.dat > RINEX_OBScan be reduced to:
teqc trimble.dat > RINEX_OBSAuto-identification has been developed for:
Note: The auto-detection for Leica 300 DS format, Motorola Oncore format, and Trimble TSIP format is in place, but the translation code in teqc is not yet complete.
The auto-identification will work most of the time but is not guaranteed! This is because the auto-identification is based on reading only a small number of bytes (usually only 1-4 bytes) at the beginning of the file. This is probably most useful if you are testing files manually on the command line. For use of teqc in scripts, please continue to use explicit receiver/format options.
The -P option has increased in status from a qc-mode only option to a generalized option for P-codeless receivers. -P (i.e. "no P-codes") should be used for P-codeless receivers, for example:
A new -L2 option has been added to indicate an L1-only receiver. -L2 (i.e. "no L2-data") should be used for all L1-only receivers, for example:
If the receiver is both L1-only and P-codeless, use both -L2 and -P options (which is the case for all of the OEM receivers listed above).
The RINEX header field editing options
now work for RINEX-to-RINEX editing, as well as the usual raw-to-RINEX translation/editing.
In addition, the +O.c[omment] option has now been completely generalized, especially for config files, to allow:
There are two metacharacters for the +O.c option: " and \. The double-quote " is a metacharacter since it is used to demark the bounds of the comment string. To insert a " character in the string, the backslash metacharacter must precede it, i.e. \". The insert a \ character in the string, another backslash metacharacter must precede it, i.e. \\.
When using +config or ++config, any occurrences of " or \ in comments are automatically preceded with an extra \, so that the resulting output can be used as a valid teqc config file.
The following time-windowing ±st, ±e, and/or ±dX option combinations should now work to extract time-windowed data:
EXCEPT the following for all input types but RINEX:
(If you are uncertain as to what these option combinations mean, see Section 13 of the teqc tutorial.) The latter three option combinations will probably never be implemented with raw data since there is no reliable way of determining the end time of a raw data file without reading the entire file forward (i.e. raw data formats are not designed to read the file backwards). Note that you can use with all formats:
In addition, if time-windowing options are used to output RINEX, the time-windowing specifications are now automatically added to the RINEX OBS file as comments.
There is a metadata summary extraction option, +meta, which might prove useful to users. The usual syntax would be something like
teqc +meta {other options} filenamewhere the file could be any type that teqc understands. In this case, stdout in not a RINEX file, but is the metadata summary which includes the start and end time of the data. If auto-identification does not work, then use the usual receiver/format option override (e.g. -tr d or whatever is appropriate). (This option is the same as the original +ar_raw option, which is still available but will vanish with the next official release of teqc.)
Note: Currently, the time-windowing options are intentionally ignored for the metadata summary extraction, so that the start and end times of the data are for the entire file, regardless of any time-windowing options specified. This characteristic may change in the future.
This is the option that has been used with teqc at the UNAVCO Archive for over one year to extract metadata about submitted data files.
Any of the executables that run on Windows 95 should run on Windows 98, though this has not been tested at UNAVCO since we don't have a Windows 98 system yet. My only reservation is whether teqc will detect the system time correctly. If you execute the DOS command ver in a DOS-emulation window on Windows 98, and the first printing characters are "Windows 98" or "Memphis", all should be well.
To subscribe to the teqc email forum, email:
address-- To: teqc-requestunavco.org message-- subscribeThen to send a message to the teqc email forum:
address-- To: teqcunavco.org subject-- Subject: <optional, but helps maintain threads> message-- <body of message; comments, bug reports, questions, conundrums about teqc>
Access the teqc email archive where you can search the teqc emails, or list the teqc emails either by date or by thread (email subject).
To unsubscribe, email:
address-- To: teqc-requestunavco.org message-- unsubscribe
Last modified: 2019-12-24 02:29:42 America/Denver