[teqc] helpful tip of week 2019

Lou Estey lou at unavco.org
Wed Sep 19 07:42:37 MDT 2018


This week's tip: qc: the ASCII time plot

The qc ASCII time plot is the first part of the qc report (after the version
information of teqc), which at this point hopefully you've examined at least
a few times.  In my opinion, the ASCII time plot is your best at-a-glance tool
for understanding a dataset -- which is best viewed using a non-proportional
font like Courier (which is hopefully how you are seeing the examples in this
tip).  A typical example for GPS-only data might look something like:

  SV+|--------|--------|--------|--------|--------|--------|--------|--------+ SV
   1|    L+sssssssssssLL_          _LLssssssssss+LL                          |  1
   2|                                          L+oooooooooooooooooooLL       |  2
   3|        LLLssssssssssssssLL             LL+ssss++L                      |  3
   5|                         LL+++++L_              LLeeeeeeeeeeeeeee+++    |  5
   6|               _L+LLL_                LLssssssssssssssssIL              |  6
   7|                  L++eeeeeeeeeeeeeeeeeee+L                              |  7
   8|ssssssILL            L+sssssssssssss++L                             LL+I|  8
   9|               LLLssssssssssssssssLL                L++LLL              |  9
  10|ssssssssssss+LL                                               _L+sssssss| 10
  11|  _LLoooooooo+L_          _L+ooooooooooooLL+                            | 11
  12|    _L+++++L_                            _L+eeeeeeeeeeeeeee+L_          | 12
  13|                              L+ooooooooooI+_           LLIoooooooooo+LL| 13
  14|ooooooooooooooooooo+LL                                                L+| 14
  15|ee++                              LL+eeee++L_            _L+eeeeeeeeeeee| 15
  16|            L+oooooooooooooo+LL                             LLLooooo+L_ | 16
  17|                               LIeeeeeeeeeeeeeeeeee+LL                  | 17
  18| L+oooooooooooo+L_           L++oooooooo+L                              | 18
  19|                                  LLooooooooooooooooooI+L               | 19
  20|ooooooooo+L                                                L+ooooooooooo| 20
  21|ooooo+L                                                _LIoooooooooooooo| 21
  22|     LLooooooooooooooooLL              LL++LLLL                         | 22
  23|          _LLoooooooooooooooooo+L                                       | 23
  24|ssssss+L                              _LIsssssssssssLL_          _L+ssss| 24
  25|     LL+sssssss+L                              LLsssssssssssss+LL       | 25
  26|         LLssssssssssssssLL                              L+sssssssM+L   | 26
  27|sssssIL_           L+sssssssssss++L                             _L+sssss| 27
  28|                         _LooooooooooooooooooooLLL                      | 28
  29|                _L++L_                            L+eeeeeeeeeeeeeeeee+L | 29
  30|                      _L+ssssssssssssssssss+L                           | 30
  31|  LL+eeeeeeeeeeeeeeee++                             L+L+L__             | 31
  32|ssssssssssssssss+LL                                                LLsss| 32
-dn|   ++++++++++++ ++++++ +++++ ++++ ++  ++++++++++++  ++  ++ +++++++++++++|-dn
+dn|                                          1                             |+dn
+10|999abcaaaabbcbbb9988999999889989baaabaacca9a888878898777678999a999999989|+10
Pos| ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo|Pos
Clk|                                                                        |Clk
    +|--------|--------|--------|--------|--------|--------|--------|--------+
00:00:00.000                                                        23:59:45.000
2018 Aug 25                                                          2018 Aug 25

Ignoring (today) the 5 lines '-dn' to 'Clk' towards the bottom, this is showing in one
clean picture the "goodness" and type of data being collected for this receiver, which
had GPS L2C and L5 tracking enabled.  Using the output of executing `teqc ++sym`, we can
quickly see:

- 'o' showing which SVs have only the legacy GPS L1 and L2 signals
       (mnemonic: "Oh, nice data!"),
- 'e' showing which SVs have L2C capability, plus the legacy L1 and L2 signals
       (mnemonic: "extended" signal set over just the legacy signals),
- 's' showing which SVs have L5 (and L2C) capability, plus the legacy L1 and L2 signals
       (mnemonic: the 's' character is close to being a short '5'),

and also see that:

- there are very few slips above the 10 degree cutoff angle,
- '+' showing quite a bit of tracking of at least the legacy L1 and L2 signals below
   10 degrees,
- 'L' showing where the receiver is showing a loss-of-lock, but these are concentrated
   when the SV is first rising or when it is setting.

In short, the above shows great data.  Once you become accustomed to this pictorial
representation, you can tell at a glance the general status of GNSS data without trying
to interpret any numerical values of percentage of expected observations, observations
per slip, multipath rms, or signal-to-noise.

Besides developing, enhancing, and maintaining teqc here at UNAVCO, another part of
my job is to diagnose GNSS data problems.  It became very clear to me early on that
the representation of GPS data and problems in this ASCII time plot was pure genius
(and further kudos to the original qc authors!) even though the original representation
was for GPS-only data and only slips.  Often I did not have the luxury of having a long
time history of data at a site to diagnose a problem; in other words I'd get: "We think
there's a problem at this site.  Here's a data file, kid.  What's wrong?"  In order to
quickly spot problems, over time I've greatly enhanced the ASCII time plot symbol set
for GNSS SVs, added symbols for SV orbit or position uncertainties, loss-of-lock, etc.
and fine-tuned the hierarchy of these symbols.

As another example, let's return to the CEDA site in the Basin and Range, which
went belly-up in early July 2018, as mentioned in tip of the week 2016:
https://postal.unavco.org/pipermail/teqc/2018/002526.html  Looking at observations
per slip (as shown in that tip), there's clearly a problem by 10 July.  But what
about 9 July?  Here's a link to the full qc report of CEDA for 9 July 2018:
ftp://data-out.unavco.org/pub/rinex/qc/2018/190/ceda1900.18S
Things were very normal -- and very good -- right up to about 21:00 on the 9th ...
and then nothing.  (But not quite nothing.  A bit of data continued to be collected
for some Galileo SVs and later for some GLONASS SVs, e.g.:
10 July: ftp://data-out.unavco.org/pub/rinex/qc/2018/191/ceda1910.18S
8 Aug:   ftp://data-out.unavco.org/pub/rinex/qc/2018/220/ceda2200.18S
Apparently, the continuing delivery of this sketchy amount of Galileo and GLONASS
data is enough to fool automated monitoring of data flow that CEDA is perfectly
healthy: http://www.unavco.org/instrumentation/networks/status/pbo/overview/CEDA
and http://www.unavco.org/instrumentation/networks/status/pbo/health/CEDA).

In yet another example, a similar thing occurred with the P688 site on 28 June 2018:
ftp://data-out.unavco.org/pub/rinex/qc/2018/179/p6881790.18S   A little
data continued to dribble in, occasionally with short periods of solid good data.
E.g. see ftp://data-out.unavco.org/pub/rinex/qc/2018/190/p6881900.18S from about
5 hours in the day to about 10+ hours.

A different example would be for point position (PP) problems.  The qc for the SGLG
site on 6 Aug 2017, ftp://data-out.unavco.org/pub/rinex/qc/2017/218/sglg2180.17S,
shows a couple of new features that will be in the next version of teqc.  Note
that this dataset was re-qced with a much more recent D&T version of teqc, 2018Jul23.
The original qc result was flagged as having PP problems that in recent versions of
teqc are now dealt with more successfully.  The PP problem at SGLG for 2017-2018 was
traced to very sketchy data for a few epochs of the file with the PP for those epochs
having unrealistic position solutions -- assuming that each position for SGLG was
supposed to be on the surface of the Earth somewhere, which is a reasonable enough
assumption.  The easiest filter to apply was just to exclude solutions which had
an ellipsoid height significantly away from any ellipsoid height that could be found
on the Earth.  The current default values are -500 meters for the minimum and
+9000 meters for the maximum, although these can be changed via two new teqc options
if desired or needed, i.e. to qc GNSS data from a LEO or other satellite.
The original ASCII time plot and mean PP were:

  SV+------|---------|---------|---------|--------|---------|---------|------+ SV
   2|                                                __-------ccccccooIII---+|  2
  13|-__                                  __---------------__         __-----| 13
  16|---___           _-------ccc-------_                                  ^^| 16
  18|------------ooI^_                                                  _----| 18
  20|----__                                    __               __---cIII--II| 20
  21|------------_                                                  _^-------| 21
  29|---_                                                    __--cccccIII---I| 29
  32|------------ooooooooo+^_                                                | 32
   8|-_----------oo++_         __----cccooooooo-__                           |  8
  24|----------__                                 _-----------cccccc^^_      | 24
  14|-_----------ccccccccccoo+^_                                             | 14
  11|-      _----ccccooooo^^__        __--------------_                      | 11
  22|-       __--cccccccccccccccccc-^_                                       | 22
   3|            __--cccccccccooooo--o+_               ______                |  3
  23|              __^cccccoooooooo--ooI-----_                               | 23
   9|                   ___-ccccccc--cccooooooo+                             |  9
   6|                      ___^^^^__              __----------oooooo++_      |  6
  30|                           _^-----cooooooo------2----_                  | 30
  28|                              _---coooooooI-----2-------^_              | 28
  17|                                    __-------------------c^^_           | 17
  19|                                       __----------------ooooo+^_       | 19
-dn| ----  ----   + +  11++ +++++1113 112222231--- - -------+ +    ++   -- +|-dn
+dn|------------   1  1111111 ++23--3322223434---------------  1 111 -------|+dn
+10|878766667777666566777766655567777766667878866678878887665555566544456666|+10
Pos|            ooo oooooooooOoo     o            ^ ^       ^             ^^|Pos
Clk|^^^^^^^^^^^^                  ^^          ^^^^^^^^^^^^^^^        ^^^^^^^|Clk
    +------|---------|---------|---------|--------|---------|---------|------+
00:51:30.000                                                        23:00:45.000
2017 Aug  6                                                          2017 Aug  6
...
   antenna WGS 84 (xyz)  : -2262461.6097 -4016669.8575 2639144.8022 (m)
   antenna WGS 84 (geo)  : N  29 deg 59' 23.19"  W 119 deg 23' 28.21"
   antenna WGS 84 (geo)  :   29.989776 deg   240.608831 deg (= -119.391169 deg)
           WGS 84 height : -1060822.6661 m

which yields a quite unrealistic height.

Now, with the min/max limit filter on each epoch's PP that is attempted:

  SV+------|---------|---------|---------|--------|---------|---------|------+ SV
   2|                                                __-------ccccccooIII  KK|  2
  13|K__                                  __----   K K-----__         ___   K| 13
  16|K--___           _-------ccc-------_                                  KK| 16
  18|K-----------oo+^_                                                  _  KK| 18
  20|K---__                                                     __---cIII  KK| 20
  21|K-----------_                                                  _^---  KK| 21
  29|K--_                                                    __--cccccIII  KK| 29
  32|------------ooooooooo+^_                                                | 32
   8|-_----------oo++_         __----cccooooooo-                             |  8
  24|----------__                                    ---------cccccc^^_      | 24
  14|-_----------ccccccccccoo+^_                                             | 14
  11|       _----ccccooooo^^__        __--------   K K_                      | 11
  22|        __--cccccccccccccccccc-^_                                       | 22
   3|            __--cccccccccooooo--o+_               ______                |  3
  23|              __^cccccoooooooo--ooI-----_                               | 23
   9|                   ___-ccccccc--cccooooooo+                             |  9
   6|                      ___^^^^__                 K--------oooooo++_      |  6
  30|                           _^-----coooooooo   K K----_                  | 30
  28|                              _---coooooooI   K K-------?_              | 28
  17|                                    __-----   K K--------c^^_           | 17
  19|                                       __--   K K--------ooooo+^_       | 19
-dn|-----6 ----   + +  11++ +++++1113 112222231-------------  +    ++   ----|-dn
+dn|------------   1  1111111 ++23--3322223434---------------  1 111 -------|+dn
+10|8787666677776665667777666555677777666678788     77888766555556654444    |+10
Pos|K    oo    oooooooooooooooooo    o            K K       o             KK|Pos
Clk|^^^^^^^^^^^^                  ^^          ^^^^^^^^^^^^^^^        ^^^^^^^|Clk
    +------|---------|---------|---------|--------|---------|---------|------+
00:51:30.000                                                        23:00:45.000
2017 Aug  6                                                          2017 Aug  6
...
   antenna WGS 84 (xyz)  : -2333422.1562 -4842783.8222 3421322.9442 (m)
   antenna WGS 84 (geo)  : N  32 deg 38' 57.48"  W 115 deg 43' 35.00"
   antenna WGS 84 (geo)  :   32.649300 deg   244.273611 deg (= -115.726389 deg)
           WGS 84 height : 87.8745 m

which now yields a more realistic PP for the dataset (*), especially given the
very poor nature of the data.  Note the 'K' symbols in a few epochs in the ASCII
time plot, which are showing where the point positions for those epochs had solution
problems and, as opposed to the original qc result, are now being excluded in the
final mean point position.  The 'K' symbol is rare enough that if you see any
it's a strong indicator that there are some very suspect data that teqc is finding
and eliminating during the PP of the qc 'full' operation.

Happy teqc-ing!

cheers,
--lou

* The correct position for SGLG is lat = 32.649266, lon = -115.726378, height = 78.3 m.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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 - https://postal.unavco.org/pipermail/teqc/2016/002067.html
week 1895: qc of high-rate data - https://postal.unavco.org/pipermail/teqc/2016/002071.html
week 1896: UNIX/Linux shells for Windows - https://postal.unavco.org/pipermail/teqc/2016/002072.html
week 1897: '-' vs. '+' teqc options - https://postal.unavco.org/pipermail/teqc/2016/002076.html
week 1898: auto-identification of formats - https://postal.unavco.org/pipermail/teqc/2016/002092.html
week 1899: auto-identification vs. format flags - https://postal.unavco.org/pipermail/teqc/2016/002096.html
week 1900: square brackets in options - https://postal.unavco.org/pipermail/teqc/2016/002105.html
week 1901: using option '+mds' - https://postal.unavco.org/pipermail/teqc/2016/002108.html
week 1902: qc results w/ problematic nav messages - https://postal.unavco.org/pipermail/teqc/2016/002113.html
week 1903: '-no_orb[it]' and '-no_pos[ition]' options - https://postal.unavco.org/pipermail/teqc/2016/002115.html
week 1904: '-week' option - https://postal.unavco.org/pipermail/teqc/2016/002117.html
week 1905: using '+bcf' for XYZ/geodetic conversion - https://postal.unavco.org/pipermail/teqc/2016/002126.html
week 1906: the '+v[erify]' option - https://postal.unavco.org/pipermail/teqc/2016/002128.html
week 1907: '+C2', '+L5', "+L6', '+L7', '+L8', '+all' options - https://postal.unavco.org/pipermail/teqc/2016/002130.html
week 1908: getting RINEX doppler and L2 - https://postal.unavco.org/pipermail/teqc/2016/002131.html
week 1909: using paths w/ file names - https://postal.unavco.org/pipermail/teqc/2016/002132.html
week 1910: the (un)importance of file names - https://postal.unavco.org/pipermail/teqc/2016/002133.html
week 1911: notices, warnings, and errors - https://postal.unavco.org/pipermail/teqc/2016/002134.html
week 1912: the '-max_rx_SVs' option - https://postal.unavco.org/pipermail/teqc/2016/002137.html
week 1913: the end of '++igs' and '+igs' - https://postal.unavco.org/pipermail/teqc/2016/002140.html
week 1914: splicing together RINEX files - https://postal.unavco.org/pipermail/teqc/2016/002144.html
week 1915: using '-O.int' and '-O.dec' - https://postal.unavco.org/pipermail/teqc/2016/002145.html
week 1916: '+doy' option - https://postal.unavco.org/pipermail/teqc/2016/002146.html
week 1917: '-tbin' and '-ast' options - https://postal.unavco.org/pipermail/teqc/2016/002152.html
week 1918: mp12 RMS before/after Oct 2013 - https://postal.unavco.org/pipermail/teqc/2016/002158.html
week 1919: the global windowing options - https://postal.unavco.org/pipermail/teqc/2016/002159.html
week 1920: '-M.dec' and '-N.dec' options - https://postal.unavco.org/pipermail/teqc/2016/002163.html
week 1921: combining time filtering options - https://postal.unavco.org/pipermail/teqc/2016/002176.html
week 1922: helping me (or someone else on the list) help you - https://postal.unavco.org/pipermail/teqc/2016/002187.html
week 1923: the "build" line - https://postal.unavco.org/pipermail/teqc/2016/002190.html
week 1924: the qc '-w[idth]' option - https://postal.unavco.org/pipermail/teqc/2016/002193.html
week 1925: qc with explicit time windowing - https://postal.unavco.org/pipermail/teqc/2016/002194.html
week 1926: the '+rx_state' option - https://postal.unavco.org/pipermail/teqc/2016/002200.html
week 1927: the '-O.sum' option - https://postal.unavco.org/pipermail/teqc/2016/002204.html
week 1928: the '+meta' and '+mds' options - https://postal.unavco.org/pipermail/teqc/2016/002206.html
week 1930: more on '-O.sum' - https://postal.unavco.org/pipermail/teqc/2017/002207.html
week 1931: the '-O.s[ystem]' option - https://postal.unavco.org/pipermail/teqc/2017/002208.html
week 1932: leap seconds - https://postal.unavco.org/pipermail/teqc/2017/002215.html
week 1936: what you can (and shouldn't) do in a RINEX obs file - https://postal.unavco.org/pipermail/teqc/2017/002229.html
week 1938: the '+psp' option - https://postal.unavco.org/pipermail/teqc/2017/002231.html
week 1939: the '+diag' option - https://postal.unavco.org/pipermail/teqc/2017/002235.html
week 1951: '-n_<system>' and SV filtering options - https://postal.unavco.org/pipermail/teqc/2017/002277.html
week 1953: more with '+diag' option - https://postal.unavco.org/pipermail/teqc/2017/002287.html
week 1954: using '+diag' output to split raw files - https://postal.unavco.org/pipermail/teqc/2017/002290.html
week 1955: current qc notation - https://postal.unavco.org/pipermail/teqc/2017/002302.html
week 1956: the '+qcq' option - https://postal.unavco.org/pipermail/teqc/2017/002304.html
week 1957: using Trimble formats - https://postal.unavco.org/pipermail/teqc/2017/002305.html
week 1958: ToC != ToE messages - https://postal.unavco.org/pipermail/teqc/2017/002310.html
week 1959: receivers vs. formats - https://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
week 1982: avoid in RINEX: RCV CLOCK OFFS APPL = 1 - https://postal.unavco.org/pipermail/teqc/2018/002392.html
week 1983: don't count on in RINEX: receiver clock offset per epoch - https://postal.unavco.org/pipermail/teqc/2018/002393.html
week 1984: requirements for multiple target files/stdin - https://postal.unavco.org/pipermail/teqc/2018/002410.html
week 1985: default output for various input - https://postal.unavco.org/pipermail/teqc/2018/002412.html
week 1986: the '+latency' options - https://postal.unavco.org/pipermail/teqc/2018/002419.html
week 1987: the 'O.px and 'O.pg' options - https://postal.unavco.org/pipermail/teqc/2018/002422.html
week 1988: the '+relax' option - https://postal.unavco.org/pipermail/teqc/2018/002423.html
week 1992: the '+x_tilt' options - https://postal.unavco.org/pipermail/teqc/2018/002452.html
week 1993: GLONASS: slot and freq. chnl. numbers - https://postal.unavco.org/pipermail/teqc/2018/002453.html
week 1994: GLONASS: slot numbers > 24 - https://postal.unavco.org/pipermail/teqc/2018/002454.html
week 1995: GLONASS: signals - https://postal.unavco.org/pipermail/teqc/2018/002456.html
week 1996: GLONASS: broadcast ephemeris - https://postal.unavco.org/pipermail/teqc/2018/002457.html
week 1997: GLONASS: system time and broadcast time parameters - https://postal.unavco.org/pipermail/teqc/2018/002458.html
week 1998: qc: 'lite' vs. 'full' - https://postal.unavco.org/pipermail/teqc/2018/002470.html
week 1999: qc: the 'full' point-position and the antenna 'height' - https://postal.unavco.org/pipermail/teqc/2018/002474.html
week 2000: qc: what's a "complete observation"? - https://postal.unavco.org/pipermail/teqc/2018/002475.html
week 2001: qc: percentage of actual to expected complete observations - https://postal.unavco.org/pipermail/teqc/2018/002483.html
week 2014: qc: interpreting slips - https://postal.unavco.org/pipermail/teqc/2018/002521.html
week 2015: qc: loss-of-lock - https://postal.unavco.org/pipermail/teqc/2018/002524.html
week 2016: qc: observations per slip - https://postal.unavco.org/pipermail/teqc/2018/002526.html
week 2017: qc: multipath rms - https://postal.unavco.org/pipermail/teqc/2018/002527.html
week 2018: qc: signal-to-noise - https://postal.unavco.org/pipermail/teqc/2018/002532.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://postal.unavco.org/pipermail/teqc/attachments/20180919/7719d7b7/attachment-0001.html>


More information about the teqc mailing list