[teqc] helpful tip of week 1913

Lou Estey lou at unavco.org
Wed Sep 7 09:49:00 MDT 2016


This week's tip: the '++igs' and '+igs' options: say good-bye to them

Last week's tip about living with the '-max_rx_SVs' option mentioned a relationship
to teqc's built-in table of IGS receiver and antenna designations, the current table
at IGS being: ftp://igs.org/pub/station/general/rcvr_ant.tab    For the time being,
the information for some version of this table is available via the '++igs' option:

[5852] teqc +help | grep ++igs
            ++igs                output all IGS receiver/antenna/dome designations to stdout

Believe it or not, this option was added to teqc in May 1999 and has been maintained
fairly faithfully since then.  There were two main ideas for including this in teqc
back in 1999:

The first idea was trying to detect and report receiver and antenna designations in a RINEX
observation file what were "non-standard".  Back in the late 90s, there was just being
to be a slight increase in the number of IGS-used receivers and antennae beyond what had
been the norm up until then and at first (because it had been a while since anyone had
updated the IGS table), there was the expected entropy of various names for the same
piece of equipment.  (I was one of the people pushing for a return to standardization,
but it was Angie Moore at JPL and maybe a few others who took up the challenge of getting
the IGS table back on track.)  So if the receiver or antenna name in a RINEX observation
file was non-standard, having a gentle reminder from teqc was a reasonable way to detect
and report this and perhaps prod users to correct their metadata.

The second idea was to use a receiver name that matched an entry in the IGS table
as a way to know the maximum number of SVs that could be tracked at one time by the
receiver.  So if you were translating, the '-max_rx_SVs' value was set once the
receiver type name was established.  Similarly, if you were doing a qc of the data
from a RINEX observation file, knowing the maximum number of SVs that could be tracked
at one time by the receiver allows some special qc functionality of the data to be done.
(More about this in a future tip of the week.)  Due to the limited number of receiver types
in 1999, and since there was only GPS, GLONASS, and SBAS SVs, building this "max_rx_SVs"
lookup into the code was actually possible in almost all cases, as mentioned last week.

However, now, there really isn't the critical need to get the receiver and antenna type
names for IGS sites normalized via teqc.  The IGS now has better ways of doing all that.

Plus, as mentioned last week, it's essentially meaningless to try to assign a "max_rx_SVs"
number for a modern receiver.  Disabling the "max_rx_SVs" constraint for reading any
format where the individual messages have a checksum or CRC seems like a much better
way on handling modern data, which is what will occur in the next official release.
(Of course there's still the qc issue, but that's a minor thing for most users.)

Worse yet, if reading a RINEX file (or even raw data file) with teqc and the receiver
and/or antenna name is not in the internal table that teqc has, the once "gentle reminder"
(which happens to a "Notice"; see tip of week 1911) becomes some portent of doom for some
users.  (This is usually due to the user using a version of teqc that is too old for
when the receiver or antenna entry was put into the IGS table and into teqc --
but sometimes this has been due to a typographic transcription error when getting the
name into teqc's code, since it is a manual process.  To suppress looking at the
internal table, the '-igs' option was added 13 Jan 2004 along the corresponding mirror
option '+igs', the latter being the default.)

In addition, many of the more recent entries in the IGS table are for receiver and
antenna types which are not used by the IGS or essentially any teqc user.  And constantly
having to include new entries into teqc's code has, quite frankly, become an annoying
chore of highly dubious value.

For all of the current reasons, the next official version of teqc will be the last one
where the options '++igs' or '+igs' do anything.  After that, the '++igs' option will
just tell you to go look at ftp://igs.org/pub/station/general/rcvr_ant.tab and the
'+igs' option won't do anything.  (I'll keep the internal table frozen at that point,
and if the code happens to do anything useful for a legacy receiver, it will continue
to do so.)

So, this week's tip is: enjoy '++igs' and '+igs' now, because they won't be around forever.

Happy teqc-ing!

cheers,
--lou

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
week 1912: the '-max_rx_SVs' option - http://postal.unavco.org/pipermail/teqc/2016/002137.html




More information about the teqc mailing list