[teqc] helpful tip of week 1982

Lou Estey lou at unavco.org
Wed Jan 3 13:12:26 MST 2018

This week's tip: thing #3 allowed in RINEX that you should avoid ...

... or at least not count on.

3) RCV CLOCK OFFS APPL set to 1: And yet again, "what's _that_?" you ask.
But first, let me explain what it is _not_.

If you consult the spec for, say, RINEX 2.11, Table A2, in
ftp://igs.org/pub/data/format/rinex211.txt and look at the specification
for the EPOCH/SAT line, you will see that at the end it could have:

  |             | - receiver clock offset (seconds, optional)     |   F12.9    |

In other words, there might be the receiver clock offset, at that epoch,
given to the nearest nanosecond.  This would come from the translation of
the raw data of the receiver.  Some manufacturers' formats give the receiver's
clock offset at each data epoch ... and many do not.  This is why this
field is optional.  (There's no point in making it a required field if
there are many cases were it simply will not be present in what can be read.)
Technically, according to the RINEX specification starting at 2.10, if
this optional receiver clock offset happens to be present, the RINEX header
then also needs to have a RCV CLOCK OFFS APPL line, but it does not mean that
the RCV CLOCK OFFS APPL line should be set to 1:

*|RCV CLOCK OFFS APPL | Epoch, code, and phase are corrected by  |     I6     |*
  |                    | applying the realtime-derived receiver   |            |
  |                    | clock offset: 1=yes, 0=no; default: 0=no |            |
  |                    | Record required if clock offsets are     |            |
  |                    | reported in the EPOCH/SAT records        |            |

(Personally, I've always thought that requiring the RCV CLOCK OFFS APPL to be set to 0
when the receiver clock offset values were present was an unnecessary complication
because: (1) such a requirement is not backwards compatible with the original
RINEX 2 spec ftp://igs.org/pub/data/format/rinex2.txt, (2) such a requirement
means that the RCV CLOCK OFFS APPL isn't really optional, as implied by the '*',
and (3) it's pretty obvious whether the receiver clock offset values are present
or not on each EPOCH/SAT line, so why complicate the issue with a required/optional
header line?)

But now we come to the real rub: what does it mean if RCV CLOCK OFFS APPL is
present and set to 1?  In other words, what does "Epoch, code, and phase are
corrected by applying the realtime-derived receiver clock offset" actually mean?
This is explained elsewhere in the specification:

If the receiver or the converter software adjusts the measurements using
the real-time-derived receiver clock offsets dT(r), the consistency of the
3 quantities phase / pseudo-range / epoch must be maintained, i.e. the
receiver clock correction should be applied to all 3 observables:

   Time(corr)  = Time(r)  -  dT(r)
   PR(corr)    =  PR(r)   -  dT(r)*c
   phase(corr) = phase(r) -  dT(r)*freq

In other words, all epoch times, all pseudorange values, and all phase values
shown need to be numerically adjusted.  But consider all the floating-point details
here, starting with the sign of the offset.  Is dT(r) the value shown at the end of
the EPOCH/SAT line, or is it -dT(r)?  (This is never really defined.)  Another
detail is that whereas the receiver clock offset is given to the nearest nanosecond:

  |             | - receiver clock offset (seconds, optional)     |   F12.9    |

... the epoch time is only given to the nearest 100 nanoseconds:

  | EPOCH/SAT   | - Epoch :                                       |            |
  |     or      |   - year (2 digits, padded with 0 if necessary) |  1X,I2.2,  |
  | EVENT FLAG  |   - month,day,hour,min,                         |  4(1X,I2), |
  |             |   - sec                                         |   F11.7,   |

(So from an adjusted epoch time, how can one unambiguously recover the original,
unadjusted epoch time?  You can't -- unless you make some heuristic assumptions.)

Also, one would have to be very careful, numerically, with all the pseudorange and
phase adjustments.

Frankly, ever since Werner Gurtner introduced the "optional" RCV CLOCK OFFS APPL
line (starting at 2.10, I think), I've seen plenty of incorrect cases of converters
generating RINEX with a RCV CLOCK OFFS APPL line and set to 1 where the only
extra thing done is to show the receiver clock offset value at the end of each
EPOCH/SAT line with _no_ adjustments to the epoch times, pseudoranges, or phases.
In other words, '0' should have been set on the RCV CLOCK OFFS APPL line, not '1'.
Furthermore, I've never seen a _single_ case where this line was set to 1 and the
epoch times, pseudoranges, and phases _were_ adjusted.

Frankly, in my opinion, the unnecessary introduction of the RCV CLOCK OFFS APPL
header line has caused far more problems than any solution it has provided, and
RCV CLOCK OFFS APPL set to 1 is a disaster.  If you see this line set to 1,
my advise is to run in the other direction ... and if you have such a RINEX 2.xx
file, teqc will simply refuse to read it.

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

"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', '+all' options - http://postal.unavco.org/pipermail/teqc/2016/002130.html
week 1908: getting RINEX doppler and 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
week 1914: splicing together RINEX files - http://postal.unavco.org/pipermail/teqc/2016/002144.html
week 1915: using '-O.int' and '-O.dec' - http://postal.unavco.org/pipermail/teqc/2016/002145.html
week 1916: '+doy' option - http://postal.unavco.org/pipermail/teqc/2016/002146.html
week 1917: '-tbin' and '-ast' options - http://postal.unavco.org/pipermail/teqc/2016/002152.html
week 1918: mp12 RMS before/after Oct 2013 - http://postal.unavco.org/pipermail/teqc/2016/002158.html
week 1919: the global windowing options - http://postal.unavco.org/pipermail/teqc/2016/002159.html
week 1920: '-M.dec' and '-N.dec' options - http://postal.unavco.org/pipermail/teqc/2016/002163.html
week 1921: combining time filtering options - http://postal.unavco.org/pipermail/teqc/2016/002176.html
week 1922: helping me (or someone else on the list) help you - http://postal.unavco.org/pipermail/teqc/2016/002187.html
week 1923: the "build" line - http://postal.unavco.org/pipermail/teqc/2016/002190.html
week 1924: the qc '-w[idth]' option - http://postal.unavco.org/pipermail/teqc/2016/002193.html
week 1925: qc with explicit time windowing - http://postal.unavco.org/pipermail/teqc/2016/002194.html
week 1926: the '+rx_state' option - http://postal.unavco.org/pipermail/teqc/2016/002200.html
week 1927: the '-O.sum' option - http://postal.unavco.org/pipermail/teqc/2016/002204.html
week 1928: the '+meta' and '+mds' options - http://postal.unavco.org/pipermail/teqc/2016/002206.html
week 1930: more on '-O.sum' - http://postal.unavco.org/pipermail/teqc/2017/002207.html
week 1931: the '-O.s[ystem]' option - http://postal.unavco.org/pipermail/teqc/2017/002208.html
week 1932: leap seconds - http://postal.unavco.org/pipermail/teqc/2017/002215.html
week 1936: what you can (and shouldn't) do in a RINEX obs file - http://postal.unavco.org/pipermail/teqc/2017/002229.html
week 1938: the '+psp' option - http://postal.unavco.org/pipermail/teqc/2017/002231.html
week 1939: the '+diag' option - http://postal.unavco.org/pipermail/teqc/2017/002235.html
week 1951: '-n_<system>' and SV filtering options - http://postal.unavco.org/pipermail/teqc/2017/002277.html
week 1953: more with '+diag' option - http://postal.unavco.org/pipermail/teqc/2017/002287.html
week 1954: using '+diag' output to split raw files - http://postal.unavco.org/pipermail/teqc/2017/002290.html
week 1955: current qc notation - http://postal.unavco.org/pipermail/teqc/2017/002302.html
week 1956: the '+qcq' option - http://postal.unavco.org/pipermail/teqc/2017/002304.html
week 1957: using Trimble formats - http://postal.unavco.org/pipermail/teqc/2017/002305.html
week 1958: ToC != ToE messages - http://postal.unavco.org/pipermail/teqc/2017/002310.html
week 1959: receivers vs. formats - http://postal.unavco.org/pipermail/teqc/2017/002311.html
week 1960: when the '-week' option is very wrong to use - https://postal.unavco.org/pipermail/teqc/2017/002314.html
week 1961: "less" is usually best - https://postal.unavco.org/pipermail/teqc/2017/002315.html
week 1962: using GPS L2C with teqc - https://postal.unavco.org/pipermail/teqc/2017/002316.html
week 1964: the '+eds' options - https://postal.unavco.org/pipermail/teqc/2017/002317.html
week 1965: handling RINEX comment lines - https://postal.unavco.org/pipermail/teqc/2017/002324.html
week 1966: the '+dUTC_p' options - https://postal.unavco.org/pipermail/teqc/2017/002331.html
week 1967: the strange position from '+meta' - https://postal.unavco.org/pipermail/teqc/2017/002355.html
week 1972: what shows up as metadata in RINEX headers - https://postal.unavco.org/pipermail/teqc/2017/002362.html
week 1973: GPS L2C navigation messages - https://postal.unavco.org/pipermail/teqc/2017/002363.html
week 1974: the '+ion_p' options - https://postal.unavco.org/pipermail/teqc/2017/002370.html
week 1975: the '+event' options - https://postal.unavco.org/pipermail/teqc/2017/002372.html
week 1976: options '+smtt' (default) vs. '-smtt' - https://postal.unavco.org/pipermail/teqc/2017/002374.html
week 1977: the reported interval with '+meta' for a RINEX obs file - https://postal.unavco.org/pipermail/teqc/2017/002377.html
week 1978: the '-N.dUTC' options - https://postal.unavco.org/pipermail/teqc/2017/002378.html
week 1979: the various qc elevation angles - https://postal.unavco.org/pipermail/teqc/2017/002383.html
week 1980: avoid in RINEX: Transit data - https://postal.unavco.org/pipermail/teqc/2017/002385.html
week 1981: avoid in RINEX: epoch flag = 6 - https://postal.unavco.org/pipermail/teqc/2017/002389.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://postal.unavco.org/pipermail/teqc/attachments/20180103/53d47998/attachment-0001.html>

More information about the teqc mailing list