Software
Remote PC Software
RedHat Linux
Auxiliary utilities
Downloading & Data Transfer
AOA
Ashtech
Trimble
Other
Pre-Processing
TEQC
Other
Processing
GAMIT/GLOBK
Bernese
GIPSY-OASIS II
Trimble Geomatics (TGO)
|
|
TEQC — "Bug" Report
Contact: UNAVCO teqc guru
Index
Last modified: 9 Dec 2005
Color codes on this page:
- Red: a possibly critical problem for certain applications under investigation (listed first)
- Purple: a possibly annoying behaviour due to the current code design (listed next)
- Teal: a fixed bug (listed last)
bugs & limitations in current teqc release:
-
There is at least one incorrect formatting RINEX problem that teqc +v does
not detect. If there are header lines elements after the header (after END OF HEADER
line in version 2) in a RINEX OBS file without a leading "event flag" with "no. of records to follow" line occurring in-between data epochs, teqc +v will not
detect the missing "event flag" line which should be present, and using teqc
as a null filter also does not detect the missing line and passes the post-header lines
through to the output. If there are header lines elements after the header in any
RINEX NAV or MET file, teqc +v likewise does not report any problems,
though using teqc as a null filter on these files does correctly remove the
post-header lines.
-> no simple obvious fix possible
-
Translation of TurboBinary from the AOA Benchmark ACT receiver to RINEX will not
use bit-2 of the LLI flag to show A/S status for each SV, since this is encoded
in a different (and as yet unknown) way from that in TurboBinary from TurboRogue/TurboStar
receivers. Therefore, in the time-summary plot of the data from a qc analysis, the
normal indicator is "*" for all SVs whether A/S is on or off.
-> cannot get documentation for the Benchmark, so A/S status cannot be determined
-
When using teqc for RINEX-to-RINEX filtering
(e.g. header editing, time-windowing, decimation, file slicing, etc.)
the first occurring TIME OF FIRST OBS field is not automatically
adjusted if it is now different due to the filtering. (The workaround
is to use the -O.st option to correctly set the start time of the
resulting RINEX file, which can be correctly extracted from the
RINEX OBS file using another execution of teqc using the
+meta option for a time to the nearest millisecond, or using the
+mds option for a time to the nearest second.)
-> fixing this may be an intractable problem to
solve given the current design of teqc as a nominal one-pass filter; improvements
were made on 10 Dec 2001 to force the TIME OF FIRST OBS to match the start of a
specified time window, for example using -st without using -O.st (but
this does not help in the case of a new start time using, say, just decimation with
-O.dec); and a check is made when outputting the first observation epoch
to see if this matches what was written into the TIME OF FIRST OBS in the
header
-
There are a number of corrections not performed by the teqc qc mode point-position:
correction for ionosphere dispersion, correction for troposphere (water vapor model), the
Earth's rotation during the signal transit time from the SVs to the antenna, relativisitic
effects (e.g. Sagnac effect), etc. The pseudorange point-position is approximate, with a
accuracy on the order of ~100 m, but good enough to get reasonable metrics on the SV tracking
and to verify that you are generally in the right place.
-> various corrections might be included as time allows,
but these are not a high priority
-
Simultaneous translation and windowing of ConanBinary does not work
correctly if the window starts after the start of the ConanBinary file,
producing mostly bogus observables in the early part of the
RINEX OBS file. (Note: RINEX NAV file will be OK, though.)
The temporary workaround is to translate to RINEX OBS without
windowing, and then window the RINEX OBS file.
(This bug exists in all versions of teqc.)
-> being investigated
-
If splicing RINEX OBS files, and the first file is header-only (i.e. no
epochs of data), and you are windowing the observations using -st in
a `mask' mode (i.e. you have not completely specified the start time by
year, month, day, hour, minute, and second) or you are using a relative
+dX time delta to establish the start time, then teqc
with terminate with the message:
where XXXXXXX is the name of the initial RINEX OBS file.
-> There is no sensible software fix for this.
The workaround is either to eliminate all initial header-only RINEX files
in a splice sequence, i.e. the first file must have at least one epoch of data,
or you have to use a complete -st start time.
-
Older Trimble DAT records are ignored, but reported, by teqc. If you encounter
DAT records or subrecords reported by teqc that are not being read, your best
option is to use the Berne TRRINEXO or Trimble DAT2RIN conversion programs.
-> The only DAT records still unsupported should now be only Records 0, 1, 2, and 7.
-
If filtering out GLONASS or SBAS data from a
RINEX OBS file, see
SV and channel editing.
However, this will not modify the system flag in the RINEX header
(e.g. from M to G or R or S or T as appropriate).
-> use -O.s to edit the header
-
When translating TurboBinary or ConanBinary after GPS week 1023 (from 22 Aug 1999 on),
the RINEX NAV file may be translated with the incorrect week (namely, from
GPS week 0-1023) if an ephemeris record in the input file is encountered before
a complete observation epoch is known to be found. The workaround, if this occurs,
is to use the -week option (specifying either the correct GPS week,
year:day-of-year, or year:month:day).
-> a fix to this was never determined, but it seems to be an
extremely rare situation
-
Translation of Ashtech stream data with teqc requires that a
PBEN record follow each MBEN record group containing an epoch's worth of information.
Without the PBEN, the time of the GPS epoch is only known to modulo 30 seconds.
(Additionally, if the data is from an Ashtech without clock steering,
i.e. it utilizes millisecond clock resets, the PBEN record in also needed
to determine when the millisecond resets occur so that the time tags and
pseudoranges can be corrected for RINEX.)
-> you must configure the Ashtech receiver
so that PBEN records are output
-
For shells (such as the Korn shell) that allow the following use of configuration files:
the actions taken will differ from the command
if the configuration file (teqc.config, in this example) contains a null string argument, such
as in the configuration file:
which contains a null string argument for the monument name (argument of -O.mo).
In this case, using the cat command will result in setting the monument name to:
The simple workaround is to not include any null string arguments, i.e. changing the
the sample configuration file to:
allows both styles of the above teqc commands to work as expected.
-> this problem is due to the shell parsing, not teqc,
though the outputting of teqc config options was modified (21 Apr 99) to change any null string argument into a single whitespace argument
-
When using the qc mode with GLONASS navigation messages, teqc will
ignore all the GLONASS navigation information except the slot number/frequency
number pairing, i.e. orbits for GLONASS are not computed.
-> this will probably remain the procedure, since
each GLONASS navigation message only contain r, v, and a vectors at a time epoch,
and the computed orbital extrapolation is only good for ±15 minutes from
the time epoch.
-
When using a spliced RINEX OBS file, teqc will
incorrectly report a possible change in sample interval or a possible data gap
at the splice point(s) even when the data are continuous.
-> not harmful in any way, just annoying; please
ignore for the time being
-
Even though the option -N.dec exists, it currently doesn't do anything.
(It is acting as a place holder in the code for when this feature might be implemented.)
-> ignore for the time being
-
Using the +meta option with a RINEX OBS file will result in
a blank "sample rate:" entry if -O.int is not being used and the
optional INTERVAL header record is not present in the RINEX OBS
file header.
-> currently the way the +meta option
is implemented for reading RINEX OBS, as reading large ASCII files is
time consuming: the RINEX header is read, then the time of the first epoch,
then the file is advanced to the end of the file and read backwards to find
the time of the last epoch; the intervals between epochs are never found
-
Using the +diag option on streamed input (stdin) results in
a nonsense value for the file position (since there is no file).
-> probably the current behaviour will remain
-
When decimating, including the -O.int option may not result in the
effect anticipated. For example, suppose that old_RINEX_OBS in a RINEX OBS
file with 1-second sampling, starting 11 seconds after the first minute.
The user wants a 30-second sampled file, with time tags nominally at 00 and 30
seconds of each minute. If the user tries:
then the time tags will nominally occur at 11 and 41 seconds of each minute
in new_RINEX_OBS. The correct command is just:
where the time tags will nominally occur at 00 and 30 seconds of each minute,
as usually desired, in new_RINEX_OBS.
-> implementation will remain as is for the time being,
since there may be some cases where the former decimation result may be desired
-
Normal stdout and RINEX output directed to stdout are handled by two
distinct file pointers. Thus, for example, when switching from
to explicit file handling using teqc (rather than the shell), the command
will not put RINEX in the specified file as one might expect. Instead use
-> use of +obs option is analogous to using
+nav for the RINEX NAV file and +met for the RINEX MET file
-
Using any of the Windows executables and translating to BINEX or creating
any other binary output (e.g. decimating CMC binary) by redirecting stdout to
a file will not work. This is due to DOS and has nothing to due with the teqc.
DOS will prepend a 0x0d in front of every isolated 0x0a, and append a 0x0a after every
isolated 0x0d (which generally really screws up a binary file).
-> instead of redirecting stdout using the DOS shell,
use the teqc +out, +obs, +nav, and/or +met options to specify
filename(s) in place of stdout
-
28 Nov 2001 beta(2) release update: A few windowing combinations,
when doing raw-to-RINEX or RINEX-to-RINEX filtering
in combination with decimation or using data with millisecond clock
resets, may result in either the first or the last expected epoch to
be missing. All known windowing combinations are OK, and the behaviour
of when the initial or last expected epochs are missing results from
the windowing operation being applied first, and then decimation on
that window.
-> current behaviour will remain
-
28 Nov 2001 beta(2) release update: The option +GPS_t (to keep
the time base in GPS time rather than receiver time) only works when
translating from a native format (including BINEX) to RINEX,
or BINEX-to-BINEX, assuming that the input file(s) are
in GPS time. Trying -GPS_t or +GPS_t with RINEX-to-RINEX
or BINEX-to-BINEX conversion, for example, where the input file(s) are
in receiver time has no effect on the output time tags or pseudorange observables.
-> no changes are planned
-
28 Nov 2001 beta(2) release update: Using the option -O.rv
(with any agruments) with the dynamically-linked DEC OSF1 build may cause
certain observables in the RINEX OBS file to be degraded in
precision. The only recorded case of this has been in translation
of TurboBinary to RINEX, but other cases may exist.
(The temporary workaround is to use the statically-linked DEC build,
i.e. the same as for DEC Linux.)
-> an explanation for this totally bizarre
behaviour was never found, the current build (9 Jan 2002) does not
exhibit this behaviour, and no source code changes made between 28 Nov
and 9 Jan should have effected anything like this; in short, a near
complete mystery
-
Translation of TurboBinary "30-1" data does not translate correctly.
-> use an earlier version for now
-
Starting 11 Feb 2002, using teqc with the -phc works,
but incorrectly labels comment blobs in any single RINEX file
as a splice point.
-> not harmful in any way, though the
embedded comment is misleading
-
Using +meta or +mds with a RINEX NAV file does not
return the correct start time.
-> these options were only meant to be used on
raw data files or a RINEX OBS file, so that they return the correct
end time for a RINEX NAV file is an accident
-
Using +relax and the editing option for a missing non-optional RINEX
header line will not result in a repaired RINEX header with the missing
non-optional header elment appended.
-> current behaviour will remain
-
Broken since probably 27 Sept 2004, translation of BINEX 0x7f-02 (e.g. from Trimble 4700)
with the +smtt option will not put the millisecond receiver clock jumps at resets into the
phase observables in RINEX, resulting in clock slips during processing.
-> fixed (15 Dec 2005) for the next release
-
If reading a Javad JPS/Topcon TPS file that starts with a message record that teqc does
not recognize, there is a possibility of a crash on certain platforms.
-> hopefully fixed (9 Dec 2005) for the next release
-
During a qc full, a poor solution convergence might tend to destablize convergence thereafter.
-> fixed (5 Dec 2005) for the next release
-
Previously when decimating data where the original sample interval was 1 sec or less, it
was highly suggested to specify the original sample interval with -O.int. Now this
doesn't need to be done for most datasets unless the original sample interval is 0.002 sec
or less (500 Hz data or higher rate).
-> changed (28 Nov 2005) for the next release
-
If time windowing a RINEX OBS file and an epoch flag of 2, 3, 4, or 5 occurs
immediately at the start of the window and there was a previous data epoch with satellites
listed, then teqc will crash.
-> fixed (4 Nov 2005) for the next release
-
The reading of a ConanBinary EPH record with the 64-bit build for Solaris will cause
a bus error or segmentation fault (depending on the system).
-> fixed (2 Nov 2005) for the next release
-
The reading of string in teqc config options allows for non-printable ASCII characters
which (according to the given option) get passed to the RINEX headers.
-> fixed (28 Oct, 1 Nov 2005) for the next release
-
Trying to do a qc of a RINEX OBS file with zero or one epoch will result
in a crash of the executable.
-> fixed (1,3 Oct 2005) for the next release
-
Translation of the Leica System LB2 0x0d message (measurement data, 32-bit integer
optimized format) leads to a segmentation fault or memory error.
-> fixed (16 Sept 2005) for the next release
-
When using -config on DOS or DOS emulation, switching to the root path
on the current drive (e.g. "\<path>\<configfile>") or switching to a different
drive (e.g. "d:<path>\<configfile>") leads to an informed search string for
the config file.
-> fixed (31 Aug 2005) for the next release
-
The order for reading east (E) and north (N) antenna topocentric offsets in BINEX
metadata in certain cases is incorrectly reversed.
-> fixed (3 June 2005) for the next release
-
The reading of Ashtech DBEN records in previous versions of teqc is flat-out wrong,
because wrong assumptions were made about the layout of records in the file.
-> fixed (6 May 2005) for the next release
-
The reading of L2 phase data from certain older Ashtech receivers like the LM-X112 may not be correct,
i.e. assuming the data is L2-squared instead of full phase. This was fixed for a known
case involving LM-XII2 data with firmware 6F, but other cases may arise.
-> fixed (28 Apr 2005) for the next release
-
The decimation of data with a sample interval of less than 1 second may not be correct
in certian cases.
-> fixed (12 Apr 2005) for the next release
-
The reading of CMC binary may lead to a buffer overflow if a data record is corrupted.
-> fixed (17 Feb 2005) for the next release
-
The plot data in the first epoch of plot files is sometimes zeroed out, e.g. the first
epoch when doing a "qc lite" run (i.e. no navigation messages).
-> fixed (4 Feb 2005) for the next release
-
Doing a +qc -width 255 (which is the maximum allowed width) results in a infinite loop.
-> fixed (27 Jan 2005) for the next release
-
The auto-identify function (which tries to identify the type of file being read) is not
looking for the correct file when a path prefix precedes the filename.
-> fixed (13 Jan 2005) for the next release
-
RINEX translation of data from a Trimble NetRS may contain epochs with zero
SVs; this is what the receiver is reporting. These epochs should be skipped.
-> fixed (5 Jan 2005) for the next release
-
Reading of multiple input files — Leica MDB being the notable case — may
not read the data after the first file correctly.
-> fixed (3 Dec 2004) for the next release
-
MET string lines with multiple XDR fragments are attempted to be read from the first
XDR fragment, but the correct data is often in the last fragment.
-> fixed (25 Oct 2004) for the next release
-
Splicing or merging of multiple RINEX OBS or MET files may not be correct if
the order of observables is different in the various files.
-> fixed (16 Sept 2004) for the next release
-
Trimble data (.dat or RT17) collected with a NetRS with clock steering enabled
results in an overflow in the L1 phase in the RINEX translation.
-> fixed (16 Apr 2004) for the next release
-
Translation of Javad JPS/Topcon TPS data on a little-endian processor (thus
all Windows builds, Linux x86 build, Solaris x86 build) can result in NaN
observables for target files after the first.
-> fixed (5 Apr 2004) for the next release
-
Translation of Javad JPS/Topcon TPS data with [rc] messages are not correct.
-> fixed (12 Mar 2004) for the next release
-
Translation of Ashtech stream with SNV messages results in GLONASS #1 being
incorrectly converted to GLONASS #33.
-> fixed (19 Feb 2004) for the next release
-
Translation of Leica MDB messege 19 (compacted data) results in a bogus A/S flag.
-> fixed (11 Feb 2004) for the next release
-
Translation of Javad JPS/Topcon TPS without RINEX C1 (C/A pseudorange) when
data contains messages [RC] or [rc] are not correct.
-> fixed (31 Dec 2003) for the next release
-
Trying to do a qc and producing plot files sometimes results in a memory fault on
Windows builds; the plot filenames being printed to the screeen look corrupted.
using -set_hor.
-> fixed, hopefully (27,30 June 2003) for the next release
-
If one is qc-ing data where the receiver is capable of starting to track an SV near or
below the "horizon" elevation (default of 0° in teqc), false multipath
or IOD slips may be reported at or near the beginning of the SV track (in first several
epochs) if there is prior data on the SV track where the SV has already set.
The workaround is to do the qc by setting the horizon elevation to a slightly lower value
using -set_hor.
-> fixed, hopefully (25-27 June 2003) for the next release
-
Borland build does not correctly create long supplementary filenames when doing a qc.
Not tested, but the same problem may occur with WatCom build.
-> fixed, hopefully (27 May 2003) for the next release
-
Translation of DAT format, RT-17 format, or BINEX of Trimble receivers after series 4000
does not use a dBHz mapping to create the RINEX 0-9 snr flag values.
-> fixed (19 May 2003) for the next release,
as long as the receiver type is found to be TRIMBLE 4400, TRIMBLE 4600,
TRIMBLE 4700, TRIMBLE 4800, TRIMBLE 5700 or TRIMBLE 7400
-
If the last line of a RINEX file does not end in a proper ASCII line
termination (e.g. newline or \n for UNIX/Linux), then teqc will incorrectly
report that the (ASCII) line length exceeds 80 characters.
-> fixed (12 May 2003) for the next release
-
broken sometime since July 2000, creation of the BINEX header using:
command-line construction.
-> fixed (6 May 2003) for the next release
-
Translation of Ashtech micro-Z B/E/S fileset or MBEN stream format or BINEX
does not use a dBHz mapping to create the RINEX 0-9 snr flag values.
-> fixed (29 Apr 2003, 15 May 2003) for the next release,
as long as the receiver type is found to be either ASHTECH UZ-12 or
ASHTECH MICROZ
-
Decimation to interval less than 1 sec may not work correctly, even if
-O.int is used to specify the original sampling interval.
-> possibly fixed (21 Apr 2003) for the next release
- (possibly broken since July 1999): The RINEX SNR 0-9 flags of
translated Ashtech MBEN streaming format are wrong.
-> fixed (31 Mar 2003) for the next release
-
The 14 Mar 2002 release will not allow you to edit a RINEX OBS file
with a sampling INTERNAL value of 0 in the header, i.e.:
(where # is a positive number) will not work correctly; it will abort when
it encounters the zero value in the input INTERNAL line. (Behaviour prior to the
14 Mar 2002 release has not been investigated.)
-> fixed (6 Feb 2003) for the next release
-
The fix on 3 Dec 2002 somehow introduced a bug in the GPS week in the
RINEX NAV, so that the GPS week would be the actual week modulo 1024.
-> fixed (5 Dec 2002) for the next release
-
Simultaneous translation while also attempting decimation and/or windowing of
ConanBinary does not work correctly, producing mostly bogus observables in the
early epochs.
The temporary workaround is to translate to RINEX without decimation or
windowing, and then decimate and/or window the RINEX OBS file. (This
bug exists in all versions of teqc prior to 3 Dec 2002, as the fix for
decimation of ConanBinary on 18 Mar 2002 was not generalized for all cases.)
-> fixed (3 Dec 2002) for the next release
-
A NEMA XDR MET string with a zero-character sensor ID field is not
recognized and results in any following observables in the NEMA string
to be rejected.
Temporary workaround is to have at least one character of blank space in the sensor ID field.
-> fixed (3 Dec 2002) for the next release, at least for
some builds (since the code fix might not be generally portable)
-
Teqc may not be able to decimate if the first epoch of the input
has a time tag with seconds being exactly 59.999.
Temporary workaround is window out the first epoch.
-> fixed (7 Nov 2002) for the next release
-
Extraction of the operation information from an Ashtech U-file YREC-record
is buggy, and may clobber the monument number (e.g. RINEX MARKER NUMBER).
Temporary workaround is to use -O.o to set the operator field.
-> fixed (24 Oct 2002) for the next release
-
(since 18Mar2002): Metadata extraction (e.g. options +meta, +mds),
especially end time, is not performed correctly on ConanBinary.
-> fixed (9 July 2002) for the next release
-
(version 14Mar2002): During a RINEX-to-RINEX filter of a MET file,
header lines SENSOR MOD/TYPE/ACC or SENSOR POS XYZ/H after the first
one get blocked and don't show up in the resultant output.
-> fixed (13 May 2002) for the next release
-
Teqc may not extract the site ID (= RINEX MARKER NAME)
from a Leica LB2 0x85 record.
-> fixed (8 May 2002) for the next release
-
(any recent version) If reading a RINEX OBS file, teqc
will skip over any cycle slip data epoch (event flag = 6) is the time
stamp of its epoch matches the previous data epoch (as in the RINEX
example file Table A7: GPS Observation Data File).
-> fixed (7 May 2002) for the next release
-
(versions prior to 1998Sep29:) Using the -O.mov 1 option results
in an illegally formed EPOCH/SAT line for the first epoch, since the
event flag = 2 is used and a satellite list of the first epoch followed
by the data for that satellite list is output.
(versions 1998Sep29 - 2001Nov28:) Using the -O.mov 1 option results
in the data for the first epoch being lost on output.
(version 2002Mar14:) Using the -O.mov 1 option results in the insertion
of the kinematic line in the RINEX OBS right after the header, but it is
not terminated with a newline as it should be.
-> fixed (6 May 2002) for the next release
-
Since there is no check on the value of observables in a RINEX OBS file,
corrupt IEEE 754 floating point values (directly or indirectly) from raw data files
may cause a segmentation fault or other memory error in trying to format the corresponding
data line for the output file because of overflow in the "F14.3" formatting.
-> fixed (29 Apr 2002) for the next release
-
(sometime between beta(2) 28 Nov 2001 and 14 Mar 2002): RINEX editing option
-O.s[system] doesn't work unless also splicing files.
-> fixed (22 Apr 2002) for the next release
-
Translation of CMC binary record 23 where the first epoch has a GPS
predicted time close to the end of the week (e.g. 604799.999999 seconds)
cause an incorrect increment of the GPS week, even though the first epoch
is really at the of the specified GPS week.
-> fixed (15 Apr 2002) for the next release
-
Translation of MET data from XDR records in Ashtech stream format may
lead to a core dump or memory fault due to a possible division by zero
in determining the probable XDR interval. A possible workaround (which
works for some cases) is to specify the MET interval in seconds using
-M.int.
-> fixed (20 Mar 2002) for the next release
-
Simultaneous translation and decimation of ConanBinary does not work
correctly, producing mostly bogus observables. The temporary workaround
is to translate to RINEX without decimation, and then decimate
the RINEX OBS file. (This bug exists in all versions of
teqc prior to 18 Mar 2002.)
-> fixed (18 Mar 2002) for the next release
-
During the translation of Leica LB2 format, the output of one or more
(or in some circumstances even all) RINEX GPS NAV messages may
be suppressed depending on where in the data 0x85 messages are
encountered relative to 0x88, 0x01, 0x02, 0x03, and/or 0x0c messages.
-> fixed (15 Mar 2002) for the next release
2002 Mar 14
-
The +relax option won't get past a blank line in a pseudo-RINEX
header. (What happens here is variable: Borland and WatCom executables
may core dump, Solaris Sparc appears to just stop doing anything even
though the program is still running, etc.)
-> fixed (5 Mar 2002) for the next release
-
28 Nov 2001 beta(2) release update: When splicing RINEX NAV files
where one of the later files contains the optional header lines for
ION ALPHA, ION BETA, DELTA-UTC: A0,A1,T,W and/or
LEAP SECONDS, then teqc will incorrectly put this in
the middle of the resulting output RINEX NAV file, which does
not conform to current RINEX specifications. (Same problem
if splicing RINEX MET files an optional MARKER NUMBER
header lines.) There is no workaround, except to add the extra header
lines to the first NAV (or MET) file.
-> fixed (27 Feb 2002) for the next release
-
If qc-ing data with a sample interval of 1 second or less, and
having millisecond resets in the time tags, and a millisecond
reset occurs on the second epoch, and there no indication of
the sample interval (either using -O.int option or, if
qc-ing a RINEX OBS file, there is no INTERVAL header
line), then teqc will not correctly compute the number of
receiver clock millisecond resets, the receiver clock drift rate, and so on.
The current workaround is to supply the correct nominal interval with the
-O.int option.
-> fixed (26 Feb 2002) for the next release
for sampling intervals down to 5 milliseconds (200 Hz)
-
28 Nov 2001 beta(2) release update: When windowing and splicing RINEX files,
teqc will incorrectly output a line with several spaces followed by the
ASCII character "0" for each RINEX file that has data after the end of
the specified time window to the resulting output RINEX file.
-> fixed (19 Feb 2002) for the next release
-
There is some slightly messed-up formatting of a few lines of the +qc
report if negative horizon or mask elevations are used.
-> fixed (13 Feb 2002) for the next release
-
The +qc calculation of "Poss. # of obs epochs" (possible number of observation
epochs) could be one less than the actual number for one direction of receiver clock drift
when millisecond clock resets or other drift effects are present in the epoch time tags.
-> fixed (13 Feb 2002) for the next release
-
28 Nov 2001 beta(2) release update: The -phc option
eliminates RINEX comments in the header as well as RINEX comments
after the header.
-> fixed (11 Feb 2002) for the next release
-
28 Nov 2001 beta(2) release update: The fix for trying to sort
out mislabeled UTC model parameters A0 and A1 is faulty. A
better algorithm has now been implemented, but will still fail
if A0 = 0 and fabs(A1) >= 2^-30 (though this is probably
an uncommon situation).
-> fixed (8 Feb 2002) for the next release
-
(bug that's been around for a while) Outputting RINEX NAV file
that contains the CORR TO SYSTEM TIME header line outputs the
system correction formatted using the standard C %19.12le, rather
than appearing as the specified Fortran formatting of D19.12.
-> fixed (14 Jan 2002) for the next release
-
28 Nov 2001 beta(2) release update: Doing a qc with the Linux x86
build of teqc sometimes results in a memory fault after the
qc has completed during the final memory cleanup of allocated memory.
-> hopefully fixed (10 Jan 2002), though
the root cause was never found; the code workaround being tried is to
skip the final memory deallocation in the Linux x86 build
-
(bug that's been around for a while) When doing a qc of L1-data, the
"qc full" (i.e. with navigation information) long report will show an
invalid "S/N L2 summary (per elevation bin)". The same type of bogus
result for "S/N L1 summary (per elevation bin)" in the long report
could occur if doing a "qc full" on data that has no L1 observable.
(The temporary workaround is to ignore the bogus stats!)
-> fixed (4 Jan 2002) for the next release
-
28 Nov 2001 beta(2) release update: Converting mixed RINEX file types to
BINEX, e.g.:
does not work. (The temporary workaround is to do each file type separately,
and then UNIX-cat the BINEX files together.)
-> fixed (14 Dec 2001) for the next release
-
28 Nov 2001 beta(2) release update: Converting RINEX NAV to BINEX, e.g.:
does not work. (No temporary workaround.)
-> fixed (14 Dec 2001) for the next release
-
28 Nov 2001 beta(2) release update: In the reading of Ashtech U-file
Y-records and VH-records, the "BOOT" portion of the firmware is extracted
as the receiver firmware version.
-> fixed (10 Dec 2001), with extraction of
the "NAV" portion of the firmware
-
28 Nov 2001 beta(2) release update: Reading of RINEX OBS or MET files
with more than 9 observables in not allowed with the current teqc.
The writing of RINEX OBS files with more that 9 observables does not
produce the # / TYPES OF OBSERV header lines in compliance with the
RINEX version 2 specification. (Currently the writing of RINEX
MET files with more than 9 observables is not possible because the number of
defined MET observables is less than 10.)
-> fixed (7 Dec 2001) for the next release
-
28 Nov 2001 beta(2) release update: Splicing of RINEX OBS or MET files
which have a change in number and/or types of observables does not occur correctly
and results in the observables after the splice point to be in the wrong order.
(The temporary workaround is to re-order the files using the -O.obs or
-M.obs options on each individual file before splicing to make
the observable lists of each file match the others.)
-> fixed (6 Dec 2001) for the next release
-
28 Nov 2001 beta(2) release update: Detection of the same observables
but in a different order when splicing of RINEX OBS or MET files
does not occur correctly and results in a incorrect # / TYPES OF OBSERV
header line at the splice point in the resulting RINEX OBS file
(no effect on resulting RINEX MET file).
(The temporary workaround is to re-order the files using the -O.obs or
-M.obs options on each individual file before splicing to make
the observable lists on each file match the others.)
-> fixed (6 Dec 2001) for the next release
-
28 Nov 2001 beta(2) release update: Splicing of RINEX OBS files
with the LEAP SECONDS header field does not work correcly.
There is no workaround.
-> fixed (6 Dec 2001) for the next release
-
The translation of Leica System 500 LB2 0x0c records results in occasional
millisecond (and sometime even ionospheric) slips due to leaving out a
millisecond time offset term from the L1 and L2 phase calculations.
-> fixed (4 Dec 2001) for the next release
-
Since 27 Aug 2001, RINEX-to-RINEX filtering when doing
decimation (-O.dec) or time-windowing (±st, ±e, and/or
±dX) in combination with certain other editing
options (especially if reducing the number of observables with
-O.obs, eliminating GLONASS with -R, and similiar operations)
may result in a memory fault or core dump, especially on
x86 builds (e.g. Linux x86, MS Windows x86, Solaris x86).
(Workaround: do the editing in two or more steps.)
-> fixed (21 Nov 2001) for the next release
-
When using any of the ±st, ±e, ±dX options for time
windowing, if the time tag string ends with a decimal point ".", teqc will terminate
teqc will terminate. (Workaround: remove the decimal point, or append a "0"
after the decimal point.)
-> fixed (12,14 Nov 2001) for the next release
-
Splicing of RINEX files since code changes on 12 June 2001 may not be
done correctly.
-> fixed (12 Nov 2001) for the next release
-
The Trimble DAT translation of record 15 reversed A0 and A1 in the RINEX NAV file.
-> fixed (16 Oct 2001) for the next release
-
The -NaN_obs option will not eliminate SVs if the data matches a
+Inf or -Inf IEEE 754-1985 data values. (It just eliminates the SVs with
+NaN and -NaN data values.)
-> fixed, hopefully, (14 June 2001) for the next release
-
When translating Leica LB2, the ToW in one or more RINEX NAV messages may be
too small if the data set contains 0x85 records.
-> fixed (7 June 2001) for the next release
-
Converting RINEX MET to BINEX, e.g.:
does not work, and (worse yet) incorrectly outputs the SENSOR
header lines from the input RINEX file to stdout.
-> fixed (6 June 2001) for the next release
-
The options -O.rename_obs and -M.rename_obs do not work.
-> fixed (4 June 2001) for the next release, though
these options are still dangerous and should not be used unless you know what
you are doing
-
Setting L2 to a squaring mode with -O.def_wf is incorrectly detected
as an error condition and teqc exits.
-> fixed (1 June 2001) for the next release
-
Spurious "flag" characters can occur in the qc compact plot files (character
immediately following the data value for the SV) when the total number of SVs
increases.
-> fixed (30 May 2001) for the next release
-
The sign of the Doppler observables translated from certain Ashtech B-files may be
reversed. (This may be early firmware; the field for the firmware and receiver
type in the B-file = "UNKNOWN" for one example of this problem.)
-> the new option +rds can be used to reverse the sign
of the Doppler from input to output (29 May 2001) for the next release
-
When doing a qc point-position, the location solution may numerically blow up
if the pseudoranges are much larger than the normal 20-32 Mm, say, on the order
of 100 Mm, especially on the Linux x86 build. (For this to be true, the receiver
must have a larger-than-normal clock error, say, on the order of several tenths
of a second.)
-> fixed (17 May 2001) for the next release
-
Translation of Ashtech stream data may not extract the Doppler values correctly.
-> fixed (14 May 2001) for the next release
-
Translation of Leica LB2 with record 0x03 will not work if Doppler data is present
(code was based on Leica MC1000 RTK GPS Receiver Technical Reference Manual
Rev. F, July 1997 which did not allow for Doppler data)
-> fixed (14 May 2001) for the next release
-
Translation of an Ashtech B-file or R-file will not show the A/S bit-2 in the
RINEX "LLI" flag for any of the pseudoranges observables.
-> fixed (1 May 2001) for the next release
-
If attempting to qc stdin, e.g.
teqc appears to do the qc mode but does not send anything to stdout
or produce a report file (in this case named lukl3220.95S)
-> fixed (10 Apr 2001) for the next release
-
If translating a corrupted Ashtech R-file format file,
teqc may core dump (segmentation fault).
-> improved or completely fixed (5 Apr 2001) for the next release
-
If translating an Ashtech stream format which does not begin cleanly
with an Ashtech stream preamble string (e.g. $PASHR,),
teqc may not correctly parse the rest of the file/stream.
-> improved or completely fixed (16 Mar 2001) for the next release
-
Doing a qc mode on a set of data with only 5 SVs will not produce
the plot files (even though by default the minimum number of SVs
is set at 5), though the rest of the QC process (including a location)
is performed. The temporary workaround is to use the additional option -min_SVs 4.
For a set of data with only 4 SVs, there is no temporary workaround: the plot files
will not be computed even with -min_SVs 4, though the rest of the
QC will be performed.
-> fixed (16 Jan 2001) for the next release
-
Teqc will reject lines in RINEX OBS with invalid time stamps
on event flags 2-5, e.g., introduced by the program clockprep:
and then terminate. The temporary workaround is to edit file and replace each "0"
with a space:
-> fixed (4 Dec 2000) for the next release,
for dealing with the (invalid) all-zero time tag
-
The change to the function turbobinary_snr_0to9_map() made on
15 Sept 2000 results in a RINEX SNR flag value of 10 is the TurboBinary
volts signal/volts noise is maxed out, resulting in a premature
termination during TurboBinary to RINEX translation.
-> possibly fixed (29 Nov 2000) for the next release
-
If decimating where the original sample interval is less than 1 second,
and the first epoch is such that mod(epoch, decimation interval) != 0
(e.g. the original sample interval is 0.5 second, and the first epoch
occurs at 33.5 seconds), then it may take teqc several decimation intervals
to get into sync correctly, resulting in a few incorrect extra epochs or
perhaps some missing epochs which should have been present at the new
decimation interval.
-> possibly fixed (20 Nov 2000) for the next release
-
Ashtech R-files with mixed GPS (record 23) and MET (record 6) data may not
translate correctly at the week boundary, due to a peculiar labeling of the
GPS week and seconds into the week for the MET data by the firmware.
-> possibly fixed (16 Nov 2000) for the next release
-
Leica LB2 record 0x10 MET data is skipped.
-> fixed (9 Nov 2000) for the next release
-
When reading Trimble data in DAT (record 17) or RT17 (57h) format,
teqc will not output valid pseudoranges (e.g. C/A, P1, and/or P2)
if the phase data (L1 and/or L2) are not valid.
This differs, for example, from the RINEX output of Trimble's dat2rin
program, due to differences in bit flag evalution in the native format records and
design criteria. This effects only a very small percentage of the total number
of possible pseudorange values.
-> fixed (31 Oct 2000) for the next release
-
The option BINEX translation option +rbew does not completely
work for switching endian-ness on output of BINEX (native-mode endian-ness
is OK, though). (Changed to +r on 31 Oct 2000.)
-> fixed (26 Oct 2000) for the next release
-
Doing a QC (i.e. +qc option) on GLONASS data requires knowledge of the
slot vs. frequency number for each SV. This can be supplied either with a
GLONASS RINEX NAV file or a slot vs. frequency number file specified
with the -glonass_n option (see GPS/GLONASS QC
for more information about the latter).
If neither of these are available, teqc +qc with GLONASS data terminates with the cryptic message:
-> fixed (17 Oct 2000) for the next release, to
remind the user to supply the GLONASS RINEX NAV file or a slot vs.
frequency number file
-
Translating a Trimble DAT file (record 17) or a Trimble RT17 file (record 57h)
and requesting the P2 observable without the C1 observable (SV with A/S on) or the
P1 observable (SV with A/S off) will result in just the P2-C1 value or no value,
respectively, for the two file types. The temporary workaround is to request the C1 and P1
observables in addition to P2 using -O.obs p2+ca+p1.
-> fixed (16 Oct 2000) for the next release
-
During RINEX-to-RINEX editing, all RINEX header
editing options require the record to be edited to exist in the input
RINEX header in order to be edited (i.e. edit the information
if it is in the input header, otherwise ignore). Certain options,
e.g.:
-O.mn RINEX OBS monument number -O.int RINEX OBS observation interval -O.leap RINEX OBS leap seconds since 6.0 Jan 1980 -N.a RINEX NAV ionosphere alpha model parameters -N.b RINEX NAV ionosphere beta model parameters -N.UTC RINEX NAV UTC time model parameters -N.corr RINEX NAV correction to system time -N.leap RINEX NAV leap seconds since 6.0 Jan 1980 -M.mn RINEX MET monument number
which are optional in RINEX headers, are not automatically inserted if
the associated input header record is missing, i.e. if it is not in the input
RINEX file, it will not show up in the edited output RINEX file.
-> fixed (11-16 Oct 2000) for the next release
-
A TurboBinary "hurl" file (memory dump) from a Benchmark ACT receiver may
terminate in repeated 0xff bytes. Teqc will report copious errors
but will probably eventually get through the file.
-> fixed (10 Oct 2000) for the next release
-
If a BINEX file doen't start exactly at a valid BINEX record,
teqc will probably terminate due to some debugging code that has not
been turned off, even if the -binex option is used to specify that
the input is in BINEX format.
-> fixed (2 Oct 2000) for the next release
-
A translation of Trimble RT17 57h data in concise format (rather than expanded
format) will not include an extraction of the observables S1 and/or S2,
even if requested.
-> fixed (29 Sept 2000) for the next release
-
The curve fit interval in hours for the GPS navigation messages in
RINEX 2.10 NAV files is missing if translated from most native formats.
-> fixed (28-29 Sept 2000) for the next release,
given the following caveat:
- The curve fit interval in hours depends on knowing the 1-bit fit interval
flag in subframe 1, the IODC from subframe 1, and knowing whether the
SV in question is Block I or Block II. For the Trimble DAT record 21 and
RT17 record 55h/ephemeris, the 3-bit "SV configuration" from page 25
subframe 4 is available and is used to determine the SV Block. For
most other formats, something else has to used. Short of using a
lookup table (SV Block history vs. PRNs), an attempt will be made
to make use of the orbital inclination, which is readily available
in all formats with broadcast navigation records:
- Block I: nominal inclination of 63°
- Block II: nominal inclination of 55°
For this test, inclinations of less than 1.03 radians (~59°) are
assumed to be Block II; otherwise, Block I.
Note: The issue of distinguishing Block I from Block II only applies
to older data, since all of the current GPS constellation is Block II,
and the curve fit interval should be 4 hours for almost all cases
anyway.
-
The decimation algorithm may not work correctly if the initial
epoch has a millisecond offset. For example, if you are trying
to decimate a RINEX OBS file which has an initial time epoch
of 2000 Sept 25 00:00:00.001 (00 9 25 0 0 0.0010000):
the file RINEX_dec.obs may terminate early (at the next millisecond
offset) or have gaps at certain later millisecond offsets.
The temporary workaround, if starting with a RINEX file, is to hand edit
it to include one or more prior fake epochs with no SVs and no data,
e.g.:
and then procede as usual with the decimation.
-> fixed (25 Sept 2000), hopefully, for the next release
-
Using more than one TurboBinary file as target files may not have
the desired result, e.g. a translation to RINEX may terminate
earlier than expected, even if the -TBfe_ff option ("ignore TurboBinary 0xff and 0xfe file boundary records") is used, such as in trying to translate hourly TurboBinary files into a single daily RINEX file:
For this case, the UNIX workaround would be:
or
(-aoa tb is probably optional).
-> fixed (20 Sept 2000) for the next release
-
Since 29 June 1998 and translating either ConanBinary or TurboBinary,
the RINEX 0-9 flag indicating signal strength has not matched
the comment:
The 0-9 value has been higher than it should have been, especially for
small SNR values.
-> fixed (15 Sept 2000) for the next release
-
The latest code for -O.st probably won't work, for various reasons.
No known temporary workarounds, other than using an older teqc, or hand-editing
the file.
-> fixed (22 Aug 2000) for the next release
-
When doing qc mode on RINEX OBS involving some other
operation of RINEX OBS filtering (windowing, decimation, header editing),
the qc process will be done correctly but the RINEX OBS filtering will not,
e.g.
results in a zero-length RINEX_new file
The temporary workaround is to do operations like this in two steps, doing the RINEX
filtering first, and then doing the qc, e.g.
-> fixed (17 Aug 2000) for the next release
-
The XDR NEMA string parser (used to decompose NEMA MET data) in
decompose_NEMA_XDR() will cause an illegal memory access
(resulting in a segmentation fault, illegal memory address, etc.)
if the NEMA string is improperly formed. There is no workaround.
-> fixed (26 July 2000) for the next release
2000 July 20
only builds for Solaris Sparc 2.3-2.7, Linux x86, and HP-UX 10.20 released!
-
Certain command line options which require a fixed number of additional arguments will
cause an illegal memory access (resulting in a segmentation fault, etc.)
if less than the required number of arguments are present. An example
is teqc -O.px 1 2, since the option -O.px requires three
values to follow.
-> fixed (20 July 2000) for the next release
-
Teqc does not correctly extract the antenna position from a Leica LB2 0x85
record, possibly leading to bogus APPROX POSITION XYZ values in a RINEX
OBS header, or a bogus value for when using the +meta option.
-> fixed (5 July 2000) for the next release
-
When translating Canadian Marconi Corp. (CMC) binary, teqc may incorrectly
parse the messages if the data contain one or more message IDs "0" with less than
10 total bytes, possibly resulting in missed epochs.
-> fixed (20 June 2000) for the next release
-
When translating high-rate (up to 50-Hz) TurboBinary (record 0x1a, 0xdb, and/or 0xdc),
code modifications on 16 Feb 2000 can result in numerous problems.
No temporary workaround, except perhaps to go back to an earlier teqc release.
-> fixed (13 June 2000) for the next release
-
When translating 1-Hz LC TurboBinary (record 0xde), a code modification on 16 Feb 2000
results in a repeated epoch at 16 and 46 seconds, the first of which contains incorrect
observables.
No temporary workaround, except perhaps to go back to an earlier teqc release.
-> fixed (12 June 2000) for the next release
-
The ionospheric model parameters in RINEX NAV file headers translated from
the following formats:
- ConanBinary
- TurboBinary
- CMC Allstar
- TI-4100 GESAR
are probably bogus (except perhaps for early TI-4100 data). The values should
be ignored.
-> fixed (31 May 2000) for the next release: alpha and beta
ionospheric model parameters have been deleted from the header for these formats
-
Translation of Trimble DAT files to RINEX may not work correctly if doing decimation
at the same time. The temporary workaround is to translate to RINEX OBS using the native
sampling interval (default), and then decimate that RINEX OBS file to
another with the desired sampling interval.
-> fixed (4 May 2000) for the next release
-
RINEX files with different RINEX versions (e.g. 2.00 and 2.10)
cannot be spliced together. The temporary workaround is to "null filter" any RINEX
file which is not the latest version, and then splice the resulting files:
-> fixed (7 Mar 2000) for the next release
-
Bad MET observables (due to faulty transducers or other problems) will cause a
RINEX MET format overflow if greater than 99999.9 or less than -9999.9.
-> fixed (3 Mar 2000) for the next release
2000 Feb 29
-
In order to extract LC, or normalized L1 or L2, from TurboBinary "30-1" format
data, the options +TBLC +TB1s must be used instead of the expected
+TBLC only (to use data from LC record 0xde).
-> fixed (15 Feb 2000) for the next release
-
Using teqc with the options +qc +plot -mp (qc mode, plot files,
and suppressing multipath calculation) causes it to crash.
-> fixed (8 Feb 2000) for the next release
-
The decomposition of the 6-byte integers in Rockwell Zodiac record 1102 are being
done incorrectly, resulting in incorrect phase and pseudorange values.
-> fixed (4,7 Feb 2000) for the next release
-
The comment in the RINEX OBS file for Rockwell Zodiac data describing
the RINEX snr 0-9 flag is wrong; the correct mapping is:
-> fixed (7 Feb 2000) for the next release
-
Some formats, like ConanBinary, will not translate correctly with the DEC Alpha OSF1
build, due to the use of an 8-byte "long" integer by the compiler.
-> fixed (8 July 1999) for RINEX OBS phase translation from ConanBinary
and (5 Jan 2000) for other RINEX (OBS, NAV, and MET) translation from other formats
for the next release, though this should be regarded as an alpha-release
-
Even though the option -M.dec exists, it currently doesn't do anything.
-> fixed (7 Jan 2000) for the next release, though it
is not quite as generalized as the decimation algorithm used by -O.dec
-
If attempting to slice two GPS RINEX OBS files which have a blank for the
satellite system in the initial RINEX VERSION / TYPE header record line
(implying a GPS-only satellite system), then teqc will abort when
the second file is reached. (A temporary workaround until the next release is to
do a null filter with teqc on each file, and then splice the
resulting files, e.g.:
where spliced.obs is then the resulting sliced file.)
-> fixed (3 Jan 2000) for the next release
-
If translating an Ashtech download fileset (B-, E-, and S-files) with an
associated D-file (with MET and/or tilt data), teqc will go into
an infinite loop while trying to read the D-file. (The temporary workaround is to
remove the D-file from the same area as the rest of the fileset.)
-> fixed (27 Dec 1999) for the next release;
plus correct interpretation of the MET data in the D-file for writing to a
RINEX MET file
-
If decimating data which contains sign changes of the millisecond clock offset
(e.g. the receiver clock drifts forward and then backward), using just
the -O.dec option is insufficient to get a complete decimated file
(i.e. teqc will probably end the file when the receiver clock drift
changes sign). The temporary workaround until the next release is to also supply
the original sampling interval using the -O.int option, which should
be specified before the -O.dec option.
-> fixed (16 Dec 1999) for the next release
-
Translation of Rockwell Zodiac record 1000 with teqc contained a
coding error which resulted in erroneous lat/lon/height values to be
shown with +meta or errroneous xyz antenna values in the RINEX OBS header.
-> fixed (18 Oct 1999) for the next release
-
Translation of Trimble *.dat with teqc will crash if a new
receiver type is encountered in Record 5.2 or Record 12, or a new
antenna type in Record 16.27.
(A problem only for the newest Trimble *.dat data from a new Trimble receiver.)
-> fixed (27 Aug 1999) for the next release
-
Translation of TurboBinary data with teqc may not work correctly
if a user data record 0x39 is encountered of less than the now normal length
of 216 bytes. (Mostly a problem for older TurboBinary data.)
-> fixed (24 Aug 1999) for the next release
-
Translation of Leica DS data with teqc may start with epochs before the
receiver has established a correct receiver clock offset determination. This
may cause an application of an incorrectly detected "milllisecond offset" to
be applied to all time tags after the receiver starts outputting valid receiver
clock offsets.
-> fixed (23 Aug 1999) for the next release
-
Translation of ConanBinary data with teqc which encounters a "brief" ConanBinary
record with a GPS SV PRN # of 32 or greater will cause teqc to crash (e.g. segmentation
fault on Solaris).
-> fixed (17 Aug 1999) for the next release; GPS SV PRN # = 32
is allowed, and PRN # > 32 are currently excluded
-
For TurboBinary collected at certain GGN (NASA's Global GPS Network) sites, teqc
will include "PRN #55" with the injected calibration signal as data when read
-> fixed (22 July 1999) for the next release
1999 Jul 19
-
When translating Ashtech native formats, the algorithm used to determine whether
the data is usable or not (using specific bits in the "warning flag" byte) may
be flawed, and result in teqc dropping good data.
-> the user will be able to keep all "questionable" data
by using a new +Ashtech_qd flag (8 Feb 1999), plus a new fix
(12 July 1999) which should be identical to what is used in Ashtech's
ASHTORIN to screen questionable data
-
The -O.dec option was failing to decimate as expected on certain systems using
dynamically-linked libraries, due to a failure of the C library function fmod()
when the second argument was zero. The incorrect behaviour was as follows. Suppose
the input file was 1-second data, with the first epoch at 11 seconds. Using -O.dec 30
resulted in epochs with seconds nominally at 11 and 41 seconds, rather than 00 and 30 seconds
as expected.
-> fixed (14 July 1999) for the next release
-
The high-rate (up to 50 Hz) TurboBinary 0xdc record has the L2-phase value calculated incorrectly.
-> fixed (8 July 1999) by Doug Hunt (dhunt cosmic.ucar.edu) for the next release
-
A strange splicing problem was introduced sometime after 7 Jan 1999:
if attempting to splice RINEX files (OBS, NAV, or MET), where
the second occurance of a file has a comment line equivalent to the
build line of the teqc version being used to do the splice,
the resultant RINEX file has an incorrect event flag = 4 value for
the number of header/comment lines to follow at that point in the splice.
-> fixed (8 July 1999) for the next release,
where the desired behaviour is to remove the extra build lines if equivalent
to an earlier one
-
RINEX OBS lines with an epoch time and an event flag value of 2, 3, 4, or 5,
but no secondary value = no. of header lines to follow (implied value of zero), e.g.
cause teqc to abort with a somewhat cryptic message:
-> fixed (8 July 1999) for the next release, and
now using teqc as a RINEX-to-RINEX filter changes the above RINEX OBS line to
-
Teqc won't window a streamed input (stdin) correctly.
-> fixed (12 June 1999, 13 July 1999) for the next release
-
Piping ConanBinary into teqc as stdin results in a mis-read
of the ConanBinary records, though the stream is parsed correctly.
-> fixed (11 June 1999) for the next release
-
Using option -TBLC with TurboBinary containing records 0xde and 0x68 ("30-1" second format),
or using -TBhr with TurboBinary containing records 0x1a, 0xdb, 0xdc, and 0x68,
or using -TB1s with TurboBinary containing records 0x1a and 0x68,
may not work correctly.
-> fixed (24 May 1999) for the next release
-
Splicing of version 1 RINEX files is not allowed.
-> fixed (4 May 1999) for the next release
-
Using both time-windowing and decimation on an input RINEX file may
not work. E.g.
-> fixed (25 Apr 1999) for the next release
-
Specifying time start and end times with partial times (i.e. masks)
may not work on input RINEX files. E.g.
may not start the resulting output RINEX OBS to 5 minutes 0 seconds.
-> fixed (24 Apr 1999) for the next release
-
Decimation (e.g. -O.dec) may not work if the time tags deviate
by more than a millisecond at the start from integer seconds.
-> fixed (21 Apr 1999) for the next release
-
Using multiple white-space separation (instead of single-space separation)
between a configuration file option flag and its argument will cause teqc
to crash if the argument is double-quoted. For example
will fail, whereas
will work correctly.
-> fixed (15 Apr 1999) for the next release
-
Translating certain corrupted Trimble RS-232 data streams (i.e. -tr s,
for Trimble's "binary cyclic printout mode") will cause teqc to crash.
-> fixed (7 Apr 1999) for the next release
-
The reformatting of Ashtech phase data, or the re-writting of RINEX OBS
with misformatted phase data using the +reformat option, i.e.
the phase value will not fit within the RINEX %14.3lf (Fortran F14.3) field,
may not work correctly.
-> fixed (2 Mar 1999) for the next release
-
The user is collecting MET data from Paroscientific MET pack on a Trimble
receiver with the MET data being stored as DAT Record 16.254. In cases where
the MET data starts late (Saturday) in one GPS week, but the GPS data starts early
(Sunday) in the next week, the following with happen:
the file rinex.obs will be translated correctly (i.e. will have the
correct week), but
or
will probably result in rinex.met and rinex2.obs being translated
incorrectly, i.e. the time stamps will be +1 week from the correct week.
-> fixed (24 Feb 1999, 1 Mar 1999) for the next release, but until then a
temporary workaround for the latter two cases is to do the translation using the -week option,
specifying the week that the MET data starts, rather than the week the
GPS data starts.
-
If trying to performing a RINEX NAV slice, i.e.
teqc will terminate the splice at the beginning of the second file
unless the RINEX NAV header has in the 41st character of the first line either a `G'
for GPS RINEX NAV files or an `R' for GLONASS RINEX NAV files.
-> fixed (9 Feb 1999) for the next release
-
Due to a bug in the 7 Jan 1999 release, if performing a RINEX OBS slice, i.e.
the spliced RINEX file will be incorrectly formatted at the boundary.
-> fixed (6 Feb 1999) for the next release
-
If reading a RINEX OBS file and outputting an edited version where:
- a single first epoch of data (within the specified time window) is
immediately followed by a non-"time tagged" event flag option, e.g. event flag = 4
followed by a few comments, and the file later contains another non-"time tagged" event flag option (within
the specified time window), say another event flag = 4
teqc will die (segmentation fault, memory fault, etc. depending on the
operation system) when the second non-"time tagged" event flag option is encountered.
-> fixed (6 Feb 1999) for the next release
-
Using an incorrectly formatted string argument for an editing option in a config file
may cause teqc to go into an infinite loop. An example:
will cause an infinite loop. The correct meta-syntax should be:
-> fixed (6 Feb 1999) for the next release, with
teqc now terminating and reporting the problem to stderr.
-
If translating and using a binary format flag, e.g. -aoa tbY, in a config file rather
than on the command line, the format flag will be ignored if the target file is
auto-identified by teqc.
-> fixed (3 Feb 1999) for the next release
-
Editing a RINEX OBS file with the -L2_2 flag set (i.e. drop any squared L2 data
or related data):
causes the L2, P2, and/or D2 observable to be dropped if the LLI-flag of that
observable has BIT-2, rather than BIT-1, set.
-> fixed (15 Jan 1999) for the next release
1999 Jan 7
-
Some sort of intermittent bug in the qc mode sometimes causes at least
the .ele, .azi, and .sn1 COMPACT plot files to have wrong values
for small segments of the time series. This bug seems to have been
introduced after the 1 July 1998 release with modifications done to
the qc mode to accommodate GLONASS data.
-> fixed (4 Jan 1999) for the next release
-
If a RINEX file that was created by teqc (either by translation
of a binary file, or by editing an existing RINEX file) is again run
through teqc, the teqc build line, stored as a
RINEX COMMENT, may be duplicated.
-> fixed (30 Dec 1998) for the next release
-
When time windowing a RINEX OBS file using the option ±st, teqc
will prematurely terminate if an epoch is encountered with more than 12 SVs
listed with the following incorrect message:
-> fixed (28 Dec 1998) for the next release
-
When time windowing multiple RINEX OBS files teqc includes
all COMMENT fields read in all the target files before the time window begins
in the new RINEX OBS file.
-> fixed (22 Dec 1998) for the next release
-
When time windowing RINEX OBS files
teqc may drop any COMMENT fields read in the last original header
when the new header is output
-> fixed (18 Dec 1998) for the next release
-
When time windowing RINEX OBS files and selecting a new start time
(e.g. using ±st {start_time} option),
teqc will continue to use the first TIME OF FIRST OBS detected
in the original RINEX unless the -O.st option is used.
-> fixed (17 Dec 1998) for the next release
-
When attempting file splicing and windowing at the same time on multiple RINEX files
(e.g. teqc -st {start_time} -end {end_time} file1 file2 file3 > new_file),
teqc will incorrectly add a line to new_file:
for each file that falls entirely outside of the specified window.
-> fixed (15 Dec 1998) for the next release
-
When attempting file splicing (e.g. teqc file1 file2 file3 > new_file),
teqc will terminate with an incorrect message at the start of file n
if file n-1 ends with header records and/or comments (not a data epoch).
-> fixed (18 Dec 1998) for the next release
-
Due to what might be a firmware bug in the Ashtech Z-18 and GG24 receivers,
the L1 (and L2 for the Z-18) phase value(s) continues to increase or decrease
without limit, i.e. it is not reset for each SV when tracking resumes.
These phase values are translated directly into RINEX, but this is
limited in size (by definition) to %14.3lf (F14.3 in Fortran). Consequently,
when the phase value > 9999999999.999 or < -999999999.999, the
phase value no longer correctly fits in the specified ASCII field and
an invalidly formatted RINEX OBS file results.
-> fixed (16 Nov 1998) for the next release
-
If attempting to read a RINEX OBS file that does not have a default
wavelength factor line (and, technically, such a file does meet the current
definition of RINEX), teqc will abort either when it encounters
the END OF HEADER line, or a WAVELENGTH FACT L1/2 line listing
specific SVs, whichever comes first, even if the option -O.def_wf is
used to define the default wavelength factors.
-> fixed (18 Nov 1998) for the next release, as long as using option -O.def_wf to
define the default wavelength factors; specific SV wavelength factors in the
original RINEX OBS file are then stored in the bit-1 of the L1 or L2 LLI flag
(see TEQC: Section 17. Wavelength Factors: What
teqc Does with Them
-
There is a high probability that the translation of the SV health code for
GPS RINEX NAV messages for all Ashtech formats and the Trimble TSIP format
is in error. The value put into the RINEX NAV file for SV health will
most likely be 0 (= healthy), regardless of the broadcast health value.
-> (probably) fixed (17 Nov 1998) for the next release
-
When translating CMC data, teqc does not correcly account for
the jumps of ±2**20 L1 cycles caused by the rollover in the data.
This will appear as a tracking slip of ±2**20 cycles when processing.
-> fixed (27 Oct 1998) for the next release
1998 Oct 22
-
When translating Ashtech data (especially Z-18 or GG24 data), teqc may
not correctly fixing the carrier phase L1 and L2 observables at millisecond
clock resets.
-> fixed for the next release when including the +msec_phs_adj option
-
When translating an Ashtech data (especially Z-18 data), teqc is not
correctly filtering out the "questionable" carrier phase and code phase values.
-> fixed for the next release
-
When translating an Ashtech Z-18 or GG24 dataset, teqc might crash
due to insufficient space in a buffer for epoch data records. (The
original buffer was optimized for the Z-12 and other 12-channel
receivers and overflows when the Z-18 or GG24 is tracking more
than about 13 satellites.)
-> fixed for the next release
-
In the qc mode of teqc, the auto-detect of GLONASS NAV files ending in ".glo" or ".GLO" to
go with RINEX OBS files ending in ".obs" or ".OBS", respectively, is not working.
-> fixed for the next release
-
It has been reported for some earlier teqc releases that attempting file splicing
(e.g. teqc file1 file2 > new_file) on Windows 95 using the Borland executable
results in an "illegal operation" notice from Windows 95 that shuts down teqc.
-> this problem cannot be reproduced with any recent
version, so it is assumed to be fixed
1998 Sept 29
-
When translating a Trimble RS-232 real-time stream, teqc will try to interprete
57h position records as 57h observation records.
-> fixed for the next release
-
When editing a RINEX OBS file, e.g.
any epoch where the event flag = 1 (power failure between previous and current epoch)
has the satellite list reset to zero SVs and the observables removed for that epoch.
-> fixed for the next release
-
When translating CMC binary or Leica LB2, there may be a premature termination
due to a hidden "trap door" exit involving uncertain rounding of the second time tag.
(This is due to the fact that these formats report the second time tag with the
current receiver clock bias added/subtracted. The clock bias is small due to
the clock steering, typically a few tens of nanoseconds or less. But in the
RINEX OBS file, the second time tag is only reported to the nearest 0.1 microsecond.
Care must be taken to avoid cases like "59.999999979" seconds being recorded as
"60.0000000" seconds in the RINEX OBS file.)
-> fixed for the next release
-
When translating an Ashtech download fileset that rolls from one GPS week
to the next, the RINEX OBS file will be translated offset by +1 GPS week.
-> fixed for the next release
-
The environment variables $teqc_OPT and $teqc_CONFIG are not
processed unless there is a config file specified on the command line.
-> fixed for the next release
-
The following time-windowing options are still not working as planned:
- -st[art_window] with fully qualified date-time stamp
- -st[art_window] with fully qualified date-time stamp and +dX delta
- -e[nd_window] with fully qualified date-time stamp and -dX delta
- -st[art_window] and -e[nd_window] both with fully qualified date-time stamps
All partial start and end times work correctly.
-> fixed for the next release
-
When doing the qc full-mode, due to a bug in the changes in the
time-windowing code, sometimes there is a mismatch between the
ephermeris epochs and the data epochs, causing totally bogus values
for the qc values. The main indication of this is very abnormal
elevation and azimuth values for the SVs.
-> fixed for the next release
-
When doing the qc-mode and generating plot COMPACT-format files, the T_SAMP line
in the plot files sometimes has a bogus sample interval if the INTERVAL
header field is missing from the RINEX OBS file or the -O.int is not used.
Workaround is to use the -O.int option when doing the qc mode.
-> fixed for the next release
1998 July 1
-
Many windowing option combinations, i.e. -st and/or -e possibly with
+d or -d, do not work when translating from binary to RINEX.
-> substantially improved; ready for beta-testing
-
Reading or translationing Ashtech download formats from receivers other than a
Z-XII may not work, e.g. from a LM-XII.
-> ready for beta-testing
-
When translating Ashtech download files to RINEX, teqc-produced "L1" values
may differ from Berne's ASRINEXO- or Ashtech's ASH2RIN-produced "L1"
values by up to 1 cm or more. This is because teqc currently uses the carrier-phase
value in the P1-code data block as "L1", whereas ASRINEXO and ASH2RIN use
the carrier-phase value in the C/A-code data block as "L1".
High-precision solutions are being run at MIT to see which flavor of "L1" works best,
though an initial test suggests that the "L1" phase in P1-code block produces a lower
RMS.
[Contact Simon McClusky (simoneverest.mit.edu) (simoneverest.mit.edu)
for further details.]
-> can switch to using L1 of C/A-code block using +Ashtech_CA_L1 option
-
The times specified with -O.st or -O.e may not be used in the RINEX
header fields TIME OF FIRST OBS or TIME OF LAST OBS (the times are
being overwritten by interval bookkeeping).
-> fixed for the next release
-
If using the -O.dec option when the original minimum sample interval, whether for
the entire data segment or only a portion of it, is less than 1 second, teqc does not
eliminate the first epoch that should have been decimated.
-> fixed for the next release,
though this may require the user to specify
the original minimum sample interval using the -O.int option if the original
minimum sample interval is not indicated elsewhere (e.g. in the RINEX header using
INTERVAL).
-
When translating ConanBinary with multiple filenames, i.e.:
an epoch of data will be lost
at the beginning of each input file starting with the second file. Also,
the phase and pseudorange values starting with the data in the second file
will contain offsets related to this missed epoch. An addition set of offset
is accumulated for each missed epoch. Unfortunately, these offsets are below
the threshold of detection in the qc mode of teqc.
A temporary workaround is to do the following:
which will give the correct translation of the observations.
-> fixed for the next release
-
There is a bit error which may cause the RINEX NAV values af0 (SV clock bias), URA (SV
accuracy), and codes on L2 channel to be wrong on big-endian teqc versions
for some binary formats (probably limited to ConanBinary, TurboBinary, Canadian
Marconi binary, and TI-4100 w/ Record 9).
-> fixed for the next release
-
When translating with any GNU gcc or g++ compiled version of teqc (e.g. Linux
version) and not using the -O.obs for RINEX OBS,
teqc will probably crash (segmentation fault or memory fault)
when trying to assign the default set of observables for ConanBinary, Canadian Marconi
binary, Rockwell Zodiac binary, or ARGO format. (A simple temporary workaround for the current
affected teqc exectables is to use the -O.obs option.)
-> fixed for the next release
-
When translating an Ashtech B-file with more than one 4-character site name changes,
teqc may go into an infinite loop.
-> fixed for the next release
-
RINEX NAV file splicing
(e.g. teqc NAV_file1 NAV_file2 > NAV_new_file) terminates
after dumping the first NAV file to stdout, since RINEX NAV file splicing is
not yet allowed.
-> fixed for the next release
Though this will be possible to do in the next release, you will not get any
in-line header info or comments at the splice points in the new file (as
occurs with teqc when splicing RINEX OBS files) since the RINEX specification
does not allow for in-line header info in RINEX NAV or MET files.
-
Using any option taking a character field argument in a configuration file or environment
variable with quotes and leading and/or trailing whitespace will not work. E.g.:
is invalid in a config file or environment variable. This structure can, however,
be used on the command line to obtain the desired result.
-> fixed for the next release
The new fix allows a config file to contain something as obtuse as:
which will yield (in the RINEX OBS file):
here using the pipe symbol as the string delimiter so you can see that the requested whitespace
is added at the beginning and to the end of the string.
-
Options +config and ++config do not output the necessary metacharacter
backslashes if backslashes or quotes are present in a character field (see above).
-> fixed for the next release
-
When attempting to use any editing option which takes a string argument (e.g.
+O.comment, -O.mn, etc.) in the configuration environment variable
or a configuration file and using double-quotes and trying to enclose only whitespace
in the double-quotes, teqc will go into an infinite loop while trying
to read this configuration option. (Note: This works correctly when the editing
option is on the command line.) Example: use of -O.mn " " in the
configuration environment variable or a configuration file will cause this problem,
whereas it will work as expected in on the command line or if -O.mn "" is used
(no whitespace between the encapsulating double-quotes).
-> fixed for the next release
-
When translating Ashtech download file sets that are not in the current working
directory, teqc will not correctly locate the E- or S-files from the
supplied B-file path/filename.
-> fixed for the next release
-
The metadata editing options -O.pr, -O.r, -N.pr, -N.r -M.pr, -M.r,
-O.mo, -O.mn, -M.mo, -M.mn -O.an, and -O.at, do not
work when editing RINEX-to-RINEX (but do work during translation from binary-to-RINEX).
-> fixed for the next release
-
Translating Trimble or Ashtech download file sets may cause teqc to crash
if there is a large amount of binary garbage in the supposedly ASCII Trimble MES
or Ashtech S-files.
-> fixed for the next release
-
The translator for the Canadian Marconi binary translator has a bug that causes
some epochs to be missed, and occasionally causes teqc to get stuck in
an infinite loop.
-> fixed for the next release
-
There seems to be a bug in the qc mode of teqc if a GPS SV PRN # 32 is
present. This was seen in data files from Jan 1993, causing teqc to either
fail completely or give the wrong qc for the first SV in the epoch list (ion
slips) at each epoch where SV 32 has data.
-> fixed for the next release
-
RINEX time tags with out-of-bounds second values, like second values >= 60 are deemed invalid.
-> fixed for the next release
-
Using the -O.dec option with qc mode works, but the decimation interval is
not reported on the qc report(s).
-> fixed for the next release
1997 Sept 28
-
Option -O.o works, but -O.observer does not (due to conflict with
identifying the -O.obs[_types] option).
-> fixed for the next release,
though the full option is now -O.o[perator],
not -O.o[bserver].
-
If multiple options are present on a single line in a configuration file, or in the
configuration environment variable, only the first option is being evalutated.
-> fixed for the next release
-
The options +obs, +nav, +met, +out, ++out,
+err, and ++err may or may not work if used in a configuration file
(OK on command line) due to assignment of volatile pointers.
-> fixed for the next release
-
For the Ashtech download translator, the warning flags were being ignored which
allowed questionable phase and pseudorange values to be output the the RINEX OBS file.
-> fixed for the next release
-
For the Ashtech download translator, the RINEX S1 (SNR for L1) was being taken
from the P1 data block, rather than the CA data block.
-> fixed for the next release
-
For the Ashtech download translator, the RINEX Doppler D1 and D2
values were not being divided by -10000.
-> fixed for the next release
-
File splicing with command line filenames instead of using shell redirection
(e.g. teqc +obs new_file file1 file2, instead of teqc file1 file2 > new_file)
does not work correctly.
-> fixed for the next release
-
It was discovered that the -O.sl option computed dh+sqrt(s^2 + (d/2)^2), instead
of the correct value of dh+sqrt(s^2 - (d/2)^2) in the Apr 1997 releases.
-> fixed for the next release
-
Numerical spikes are present in the IOD data (*.iod plot file) where ION slips were
detected and removed. The ION data (*.ion plot file) and the ION slip count are correct.
-> fixed for the next release
-
When using the +O.c, +N.c, or +M.c options with RINEX target
files, the resulting stdout does not contain the requested additional RINEX COMMENT
fields. (These options do currently work for translating from binary to RINEX, i.e.,
the resulting stdout and RINEX files from the translation do contain the requested additional
COMMENT fields.)
-> fixed for the next release
-
Using the ++config option under certain conditions returns the incorrect values for
the -st, +dh, and -e options.
-> fixed for the next release
-
The returned system time "year" on Windows 95 seems to be 10 years in the future (i.e.
2007, instead of 1997), yet the GPS week is correct. Run on Windows NT, the correct year
is reported. Execute teqc +id and look at the "system time" field. Bug is known
to exist for at least the Borland compile.
-> fixed for the next release
-
Kinematic flags in Trimble DAT files are currently ignored. (Main priority development of
teqc is still for static surveys, though there are many internal features that are
all ready for kinematic situations.)
-> fixed for the next release
-
Still not allowed to translate/read TurboBinary or TI-4100 formats on platforms with
Intel or Intel-like processors. (Byte-switching functions for all records have not
been completed and tested yet.)
-> fixed for the next release
-
If the observation sampling interval is greater than what you supply (via the -O.int
option), teqc does not report this as a possible problem.
-> fixed for the next release
1997 Apr 9
-
1997 Apr 9: fixed bug to output correct session end for -e and -O.e configuration
options when using ++config option and correct final date & time when using +ar_raw
option with RINEX OBS target file(s) (e.g. teqc ++config OBS_file or teqc +ar_raw OBS_file);
correctly extract lat lon ele from x y z w/ +ar_raw option
-> fixed for the next release
-
1997 Apr 8: added -O.pg option for entering approx antenna position as lat long elevation
(degrees degrees meters); fixed +v option for multiple target files; re-fixed -O.obs
and -M.obs options with RINEX target file(s); eliminated all multiple teqc build comments in
RINEX output and/or config output; added extra characters for config output of -st and
-e options (for human readability only--added extra characters are not required); changed default
set of OBS observables for RINEX translation to be L1 L2 C1 P2 P1 D1 D2 (equivalent to
-O.obs l1+l2+c1+p2+p1+d1+d2), to drop S1 and S2 by default and put P1 in the last
spot on the first line for each SV to minimize overall RINEX OBS size when A/S in on
-> fixed for the next release
-
1997 Apr 7: place teqc build info in all RINEX created, whether by files or stdout; build
for Solaris Intel 2.5
-> fixed for the next release
-
1997 Apr 4: slight rewrite of NAV ToW - obs time to better detect and report GPS week
discrepencies
Last modified Monday, 25-Jun-2007 11:42:11 MDT
|
