[teqc] helpful tip of week 1912
lou at unavco.org
Wed Aug 31 07:59:50 MDT 2016
This week's tip: living with the '-max_rx_SVs' option
Last week finishing up the tip on notices, warnings, errors, and potential errors,
the last being those messages that start with "? Error ?" (that is, maybe what's
being pointed out is an actual problem ... or maybe not), I gave the example:
 teqc +quiet my_file > /dev/null
? Error ? 'my_file' rejection due to SV count @ 2016 Jun 14 15:03:00.000 appears wrong: total= 30 max= 22 (use option '-max_rx_SVs 30'?)
? Error ? 'my_file' rejection due to SV count @ 2016 Jun 14 15:03:03.000 appears wrong: total= 31 max= 22 (use option '-max_rx_SVs 31'?)
? Error ? 'my_file' rejection due to SV count @ 2016 Jun 14 15:03:28.000 appears wrong: total= 32 max= 22 (use option '-max_rx_SVs 32'?)
This is perhaps one of the most frustrating situations when reading raw data formats
nowadays. What is teqc talking about? Why is this important? If you are translating
and making a RINEX observation file, the RINEX file will probably be significantly
incomplete. But, at least, if you get this type of message, you should just re-try
using the last '-max_rx_SVs ...' suggested by teqc and probably all will be well.
First, this option and the value specified means, as explained in `teqc +help`:
 teqc +help | grep max_rx_SVs
-max_rx_SVs # set maximum # of SVs trackable (per OBS epoch) based on receiver type
... the maximum number of SVs capable of being tracked _per_ _observation_ _epoch_.
(I.e it is not the number of SVs tracked in all the epochs in the whole dang file.)
Why is this needed? All binary formats at some point contain the actual number of
SVs being tracked for observables in an epoch ... or some other piece of information that
is equivalent to that. Again, we are talking about a binary file. All one has to go
on is a string of 1's and 0's that you hope makes some sense in the end. There is
always the finite possibility that the number being identified in the binary file for
a given epoch is so much binary rubbish -- and interpreting such rubbish as reality can
lead to quite a mess. Knowing the actual maximum number of SVs that can be tracked
by the receiver, and therefore the maximum number of SVs that should be in an epoch
of observations from the receiver, provides a type of sanity check that can be applied
while parsing the binary file for each epoch.
If you are a long-time user of teqc, you might correctly think that such things did not
occur (or at least not too often) back in ancient and olden times -- like the mid- to
late-90s. Why not? Well, back then there were simply far fewer receivers and most of
them only tracked the L1 and L2 legacy signals of the GPS SVs, although a few also were
capable of tracking L1C/A of SBAS and/or the G1 and G2 legacy signals of GLONASS.
AOA Rogue SNR-8* receivers could track a maximum of 8 GPS SVs
AOA Rogue SNR-12* receivers could track a maximum of 12 GPS SVs
Trimble 4000 receivers could track a maximum of 12 GPS SVs
Ashtech Z-12 receivers could track a maximum of 12 GPS SVs
Ashtech Z-18 receivers could track a maximum of 12 GPS SVs and 6 GLONASS SVs
... and so on.
Life was reasonably simple and good. It was actually possible to known the maximum
tracking characteristics by SV count given the receiver designation, e.g. the IGS
designation suggested for use in RINEX observation headers. These maximum SV limits
were actually coded into teqc.
Nowadays, modern receivers tend to have a specified maximum number of "channels",
where typically a channel means a specific signal on a specific carrier frequency (cf)
for a specific SV. The result is that the number of SVs that can be tracked can be
quite different for the same receiver depending on which signal/cf combinations and
which constellations are specified (or even allowed) to be tracked by the user.
The result is that it is essentially impossible to know the true tracking SV limit
of an arbitrary modern receiver from the IGS designation table:
My advice is to know your receiver, given the way it is configured and where it is located,
and then when using teqc either include '-max_rx_SVs ...' with the correct number ...
or be ready to detect the '? Error ?' messages from teqc and be ready to respond.
All of this leads to next week's tip and discussion about the built-in table of
IGS receiver and antenna designations.
Another point, which is perhaps up for discussion, is that the need for having this
sanity check came about because of data formats (some of which are still in wide use)
that did not have a checksum or CRC for each epoch's worth of data. Most modern formats
contain this type of sanity check on the records/messages contained within the format
and having such checksums or CRCs essentially reduces the need for the max_rx_SVs check
for each epoch to zero. So I would be willing to consider eliminating this check on
those formats which have their own checksum/CRC for the records/messages within the
data format. Examples of such formats that could be given a free pass would be
Ashtech U- and R-file and the MBEN stream, Javad JPS, Leica MDB and LB2, Septentrio
Binary Format (SBF), Topcon TPS, Trimble RT17 and RT27 streams and, of course, BINEX.
BTW, what is the current maximum for the '-max_rx_SVs' option allowed in teqc?
It is 64 -- thus allowing 64 simultaneous SVs to be tracked (which I think will be
just fine anywhere on the planet for quite a while) -- but if the day ever comes
when this number is too small, it can be increased in teqc's code by increments
of 32 by merely changing one configuration number and recompiling.
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
Past helpful tips:
week 1894: using teqc config files - http://postal.unavco.org/pipermail/teqc/2016/002067.html
week 1895: qc of high-rate data - http://postal.unavco.org/pipermail/teqc/2016/002071.html
week 1896: UNIX/Linux shells for Windows - http://postal.unavco.org/pipermail/teqc/2016/002072.html
week 1897: '-' vs. '+' teqc options - http://postal.unavco.org/pipermail/teqc/2016/002076.html
week 1898: auto-identification of formats - http://postal.unavco.org/pipermail/teqc/2016/002092.html
week 1899: auto-identification vs. format flags - http://postal.unavco.org/pipermail/teqc/2016/002096.html
week 1900: square brackets in options - http://postal.unavco.org/pipermail/teqc/2016/002105.html
week 1901: using option '+mds' - http://postal.unavco.org/pipermail/teqc/2016/002108.html
week 1902: qc results w/ problematic nav messages - http://postal.unavco.org/pipermail/teqc/2016/002113.html
week 1903: '-no_orb[it]' and '-no_pos[ition]' options - http://postal.unavco.org/pipermail/teqc/2016/002115.html
week 1904: '-week' option - http://postal.unavco.org/pipermail/teqc/2016/002117.html
week 1905: using '+bcf' for XYZ/geodetic conversion - http://postal.unavco.org/pipermail/teqc/2016/002126.html
week 1906: the '+v[erify]' option - http://postal.unavco.org/pipermail/teqc/2016/002128.html
week 1907: '+C2', '+L5', "+L6', '+L7', '+L8', and '+all' options - http://postal.unavco.org/pipermail/teqc/2016/002130.html
week 1908: no doppler shortcut; RINEX L2 - http://postal.unavco.org/pipermail/teqc/2016/002131.html
week 1909: using paths w/ file names - http://postal.unavco.org/pipermail/teqc/2016/002132.html
week 1910: the (un)importance of file names - http://postal.unavco.org/pipermail/teqc/2016/002133.html
week 1911: notices, warnings, and errors -- http://postal.unavco.org/pipermail/teqc/2016/002134.html
More information about the teqc