[teqc] helpful tip of week 1899

Lou Estey lou at unavco.org
Wed Jun 1 07:15:47 MDT 2016


This week's tip: auto-identification vs. format flags: what to use where

This tip is perhaps obvious.  It's combining the tip on using a teqc config file
with the tip on teqc's auto-identification of a format.

Can a teqc config file explicitly contain a format flag?  Yes.  Should a
format flag be in teqc config file for a site, if the config file is used by
one or more scripts?   Sure, as long as you remember that option is in the
configuration file.

When should the auto-identification be used?  That's a judgement call, but
typically it's safe when you are manually doing something with a file and
you don't want to be bothered telling teqc what the format is.  (If teqc
gets the format wrong, you will probably soon know because the result will
not be what you expected.)

Here at UNAVCO, we do _not_ have any format flags set in any of our teqc
config files for any permanent station, but the format _is_ explicitly set for
each station with incoming raw data; we just do this in a slightly different way:
we have another configuration file for all sites, and that file specifies
the current incoming format for each site.  Our reason for this particular
style is that here each teqc config file contains information which is more
analogous to what one might find in a RINEX observation header -- information
pertinent to processing -- and the format from the receiver is not part of
that.  Many of the receivers that we handle are capable of outputting two
or more formats.  This goes back to early receivers like, say, the JPL/AOA
Turborogues which could output the data in Conan binary or Turbobinary.

Upon which hangs a cautionary tale.  Once there was site with a Turborogue
from which we had been receiving the data in Conan binary.  So, when teqc
commands were being put together by our software, they would always use the
'-aoa cb' format option.  Then one day, without our being told, the site
operators of this site switched to using Turbobinary.  Our scripts were suddenly
not able to read any of the incoming data from this site.  This was at first
quite baffling because manually we could easily use teqc with the new files
and get metadata, convert to RINEX, etc. because _manually_ we were relying
on teqc's auto-identification of the format.  It took a while to realize that
all our scripts were still being forced to try to read the now incoming Turbobinary
as Conan binary (which doesn't work at all).

So whatever you do, always try to remember what you are doing and why:
either letting teqc auto-identify the format -- and know how to recognize
when that is failing -- or forcing teqc to read the input with a specific
format option -- and, again, know how to recognize that this is not working.

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




More information about the teqc mailing list