[teqc] helpful tip of week 1914

Lou Estey lou at unavco.org
Wed Sep 14 09:44:33 MDT 2016

This week's tip: splicing/merging multiple RINEX files

Putting together multiple data files shouldn't be a chore, but before teqc existed doing
this operation was somewhat of a pain.  Mainly, this is because one can't resort to using
a simple tool like the UNIX/Linux `cat` command ("concatenate and output to stdout")
to put multiple RINEX files together; doing so leads to an illegal structure for RINEX.

Let's say you have two hourly RINEX observations files from the same site with the
same equipment, site257a.16o and site257b.16o, and all epochs in site257a.16o are before
those in site257b.16o, exactly as expected. You absolutely should _never_ do this:

(DON"T DO THiS!)  cat site257a.16o site257b.16o > site2570.16o

... because the file site2570.16o will not be a valid RINEX observation file.  However,
you can do this:

(Do this instead) teqc site257a.16o site257b.16o > site2570.16o

What's the difference?  The `cat` operation blobs the full header of the second file
right into the middle of output -- and this is not a proper structure for RINEX.  The
teqc operation correctly tidies up the splice using a legal structure following the
RINEX specification.  (Actually, teqc is doing a lot more: it is reading the input
to make sure that it is valid RINEX, fixing minor problems, standardizing the output,

But there are a few rules:

1) Only RINEX files of the same RINEX type can be spliced together.  In other words,
RINEX obs to RINEX obs, RINEX met to RINEX met, GPS RINEX nav to GPS RINEX nav, and
so on.  For example, you cannot legally splice a RINEX obs file to a RINEX met file.
(If you try to splice different types together with teqc, teqc should inform you of
the problem and exit.)

2) When splicing RINEX obs files, then the equipment -- the receiver, antenna, and
radome (if any) -- must remain the same for all files.  This extends to not only
the _type_ of equipment, but the actual physical pieces of equipment and, in addition,
the firmware of the receiver.  (This requirement comes from the original definition
of what a RINEX observation file needs to be from Dr. Werner Gurtner.)  However,
the position of the antenna is allowed to move or even be in an entirely different
location; again, this is part of the original definition, which add support for
"roving" surveying situations, e.g. RTK and other applications.  (If you try to
splice RINEX obs files where the equipment changes, teqc should inform you of the
problem and exit.)

Plus the following are additional options/rules when using teqc for splicing files:

3) List the files in increasing time order, because teqc, like for all its operations,
will process the files in the order that you specify them in the command line.  For
example, if in the above example you had listed the two hourly files in the opposite order:

(like above, epochs in 'a' all before those in 'b') teqc site257b.16o site257a.16o > site2570.16o

then the resultant file site2570.16o will essentially be identical to file site257b.16o
because all the epochs of file site257a.16o will be skipped since they are all before
the last epoch of file site257b.16o.

4) When splicing RINEX obs files and you want to minimize the secondary header information
in the resultant RINEX, use the '-phc' option (= "minimize post-header comments").
Note that even with '-phc' you will still get one comment added by teqc at each splice
point, but the format used for this comment should follow the RINEX specification.
(This comment is so that everyone knows that there is a splice point at that location --
so that if there is a problem at the splice, the problem can be tracked back to the
splice operation.)

5) When splicing RINEX obs files and there is an increase in the number of constellations
being tracked in later files, then you will need to use the '-O.s M' option if the first
RINEX obs file is not already specified as 'mixed':

[6993] teqc +help | g "O.s\["
        -O.s[ystem] #            set RINEX OBS header satellite system to # (= G, R, S, T, or M)

Teqc uses the satellite "system" header value from the first RINEX obs file in the list
to begin the resultant merged RINEX, so if that first file is 'mixed', you are fine, but
if it's not, you may need '-O.s M'.

Lastly, you should check to make sure the resultant spliced RINEX file meets the RINEX
specification.  Using teqc with the '+v' option is pretty good for this; see again tip
of week 1906: http://postal.unavco.org/pipermail/teqc/2016/002128.html
(Why do you want to do a check?  Because splicing RINEX files, especially RINEX obs files
in the most general cases, is a nasty process and even teqc has been known to not get
it quite right at times.)

Happy teqc-ing!


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
week 1913: the end of '++igs' and '+igs' - http://postal.unavco.org/pipermail/teqc/2016/002140.html

More information about the teqc mailing list