[teqc] minor bugs in COMPACT files
lou at unavco.org
Fri Feb 4 14:38:07 MST 2005
Yes, this going to be another one of those emails with gory details.
A bug has been found (and now fixed) which resulted in certain lines
of data in the teqc plots files (using Jim Johnson's COMPACT format)
to be zero except for the last value. The case where this was found
was doing a "qc lite" run (RINEX OBS file with no RINEX NAV file):
teqc +qc rinex.obs
and then looking at the first line of data in the .sn1 and .sn2
(SNR values for L1 and L2 tracking). If you do this, note that
all the SNR values for all SV in the first plot data line are zero
except for the SNR of the last SV. This is happening in all the
other plot files (.ion, .iod, .mp1, .mp2) as well, except you don't
notice it because the data in first line of these are defined to
I'm guessing (without testing) that this could also occur with
a "qc full" run (you have a RINEX NAV file and teqc finds the antenna
position) under certain special conditions, e.g. the NAV file lists
only n SVs, but the OBS file has epochs with m SVs > n SVs: at
the first epoch where the SV count goes above n or any latter
epoch where the SV count goes yet higher, I think the plot values
for the first SVs in those lines will get reset to zero.
The 2nd bug: The first epoch of each plot file corresponds to
the second epoch of observations; this is by intentional design
so that all the plot files, including .iod, start at the same time,
and the first epoch of data for .iod can only be determined at
the second epoch of observations. The bug is that the start time
listed in the plot files (in modified Julian days) is for the
raw GPS observations, not the first epoch of plot data.
These bugs have been in existence since the beginning of teqc, so I
doubt they have caused too much trouble, mainly because the plot files
weren't intended for anyone to be digging into in too much detail.
* .ele and .azi aren't produced in "qc lite" -- so no problems there -- but
.mp1 and .mp1 defined to be zero at the start? Yes, because teqc is
cheating. What you need in order to determine the multipath rms is
some estimate of the DC bias of the multipath linear combination, and
you don't know this unless you compute the multipath for all epochs,
remove slips, etc. But teqc is designed as a nominal one-pass filter.
So, as an estimate of DC bias, teqc uses the running mean of the multipath
and computes the rms from this running mean. Thus the rms at the first
epoch is zero. Using the running mean as the DC bias value also means
that if teqc misses any small slip, the rms does not get too far off
because the running mean method is self-correcting in the long run.
Louis H. Estey, Ph.D. office: [+001] 303-381-7456
UNAVCO, 6350 Nautilus Drive FAX: [+001] 303-381-7451
Boulder, CO 80301-5554 e-mail: lou unavco.org
WWW: http://www.unavco.org http://jules.unavco.org
"If the universe is the answer, what is the question?"
-- Leon Lederman
More information about the teqc