[teqc] helpful tip of week 1966

Lou Estey lou at unavco.org
Wed Sep 13 10:25:53 MDT 2017


This week's tip: the '+dUTC_p' options

The '+dUTC_p' options are for outputting any "delta UTC parameters" that might
be in the raw data being read by teqc:

[6743] teqc +help | grep dUTC_p
         +dUTC_p[aram] .      output any delta UTC parameters to stdout
         +dUTC_p[aram] ..     output any delta UTC parameters to stderr
         +dUTC_p[aram] name   output any delta UTC parameters to file 'name'
         ++dUTC_p[aram] name  append any delta UTC parameters to file 'name'
         -dUTC_p[aram]        don't output delta UTC parameters except to RINEX nav header (default)

where the command options above follow the same form as several other options,
such as '+eds', '+rx_state', '+psp', and '+diag', that have been discussed in
earlier tips of the week for outputting other special parameters.

What are "delta UTC parameters"?  These are parameters that are broadcast by the
SVs in each constellation that allow the user, aside from integer leap seconds
(if applicable), to obtain the correction of the constellation's system time to
one of the UTC realizations, which, barring any errors on my part, are:

GPS: UTC(USNO) - US Naval Observatory (Washington D.C, USA)
Galileo: UTC(PTF) - Precise Timing Facility, Galileo Control Centre (Fucino, Italy),
   which is the mean of the UTC of 5 European time labs: Observatoire de Paris (France),
   PTB (Germany), IT (Italy), ROA (Spain) and SP (Sweden)
Beidou: UTC(BSNC) - Beijing Satellite Navigation Center (Beijing, China)
QZSS: UTC(NICT) - National Institute of Information and Communications Technology
   (Koganei/Tokyo, Japan)
GLONASS: UTC(SU) - "Soviet Union" (Moscow, Russia)
IRNSS: UTC(IRNWT) - ISRO Regional Network Timing Centre (India)
SBAS: depends on host agency of the SV

All delta UTC parameter sets have a constant, A0, in seconds, and all but GLONASS
also include a drift parameter, A1, in seconds/second.

Ideally, all SVs in a constellation (except for SBAS) should be sending the same
delta UTC parameters.  Probably for this reason, most formats do not store the
SV id from which any particular set of delta UTC parameters was obtained.

In RINEX 2.11 navigation files, there's a different format for these parameters
depending on the constellation; see https://igscb.jpl.nasa.gov/igscb/data/format/rinex211.txt

for GPS (from Table A3):
*|DELTA-UTC: A0,A1,T,W| Almanac parameters to compute time in UTC| 3X,2D19.12,|*
  |                    | (page 18 of subframe 4)                  |     2I9    |
  |                    | A0,A1: terms of polynomial               |            |
  |                    | T    : reference time for UTC data       |      *)    |
  |                    | W    : UTC reference week number.        |            |
  |                    |        Continuous number, not mod(1024)! |            |

for GLONASS (from Table A10):
*|CORR TO SYSTEM TIME | - Time of reference for system time corr |            |*
  |                    |   (year, month, day)                     |     3I6,   |
  |                    | - Correction to system time scale (sec)  |  3X,D19.12 |
  |                    |   to correct GLONASS system time to      |            |
  |                    |   UTC(SU)                         (-TauC)|      *)    |

for SBAS (from Table A15):
*|D-UTC A0,A1,T,W,S,U | Corrections to transform the system time |            |*
  |                    | to UTC                                   |            |
  |                    | A0,A1 Coefficients of 1-deg polynomial   |  2D19.12,  |
  |                    |        A0 sec, A1 sec/sec                |            |
  |                    |        CORR(s) = A0 + A1*DELTAT          |            |
  |                    | T  Reference time for polynomial         |     I7,    |
  |                    |        (Seconds into GPS week)           |            |
  |                    | W  Reference week number                 |     I5,    |
  |                    |        (GPS week, continuous number)     |            |
  |                    | S  EGNOS, WAAS, or MSAS ...              |   X,A5,X   |
  |                    |    (left-justified)                      |            |
  |                    |    Derived from MT17 service provider.   |            |
  |                    |    If not known: Use Snn with            |            |
  |                    |      nn = PRN-100 of satellite           |            |
  |                    |      broadcasting the MT12               |            |
  |                    | U  UTC Identifier (0 if unknown)         |    I2,2X   |
  |                    |   1=UTC(NIST), 2=UTC(USNO), 3=UTC(SU),   |            |
  |                    |   4=UTC(BIPM), 5=UTC(Europe Lab),        |            |
  |                    |   6=UTC(CRL), >6 = reserved for future   |            |

This is one of the header items that I suggested to Werner Gurtner back in 2007 that
we standardize for all GNSS constellations in RINEX 3.xx, and teqc's '+dUTC_p' output
most closely follows that of SBAS in RINEX 2.11 since SBAS' in 2.11 is the most generalized.

So let's take a look at some actual output using one of the '+dUTC_p' options:

[6750] teqc -javad jps +quiet +dUTC_p .. msu_tre3_v3610_gdld_wn_01.jps > /dev/null
G   6.519258022308D-09 1.509903313490D-14  16384 1935 G      2 D-UTC A0,A1,T,W,S,U
R  -2.328306436539D-09 0.000000000000D+00  48866 1934 R      3 D-UTC A0,A1,T,W,S,U
R10-2.328306436539D-09 0.000000000000D+00  48866 1934 R10    3 D-UTC A0,A1,T,W,S,U
S   4.656612873077D-09 8.801848139228D-13  45056 1934 S      4 D-UTC A0,A1,T,W,S,U
E   2.793967723846D-09 0.000000000000D+00  59648 1934 E      0 D-UTC A0,A1,T,W,S,U
J   1.955777406693D-08 8.881784197001D-16  49152 1935 J      6 D-UTC A0,A1,T,W,S,U
C  -4.656612873077D-09 0.000000000000D+00     14 1934 C      0 D-UTC A0,A1,T,W,S,U
I  -7.625203579664D-09-1.598721155460D-14  59936 1934 I      0 D-UTC A0,A1,T,W,S,U
R02-2.328306436539D-09 0.000000000000D+00  48866 1934 R02    3 D-UTC A0,A1,T,W,S,U
R22-2.328306436539D-09 0.000000000000D+00  48866 1934 R22    3 D-UTC A0,A1,T,W,S,U
R13-2.328306436539D-09 0.000000000000D+00  48866 1934 R13    3 D-UTC A0,A1,T,W,S,U
R12-2.328306436539D-09 0.000000000000D+00  48866 1934 R12    3 D-UTC A0,A1,T,W,S,U
R11-2.328306436539D-09 0.000000000000D+00  48866 1934 R11    3 D-UTC A0,A1,T,W,S,U
...

For '+dUTC_p' output, the first two numbers after the constellation (and SV id, if known)
are A0 and A1.  (If the SV id is unknown, two blank spaces are output in place of the id.)
Next is the time in the GPS week and GPS week that A0 and A1 apply.  Note that this
time stamp is converted into GPS time for all constellations to make for easier
comparisons.  The SV (and id) is then repeated.  The last digit corresponds to the UTC
identifier, which is based on information in the raw data records, so in this example
Galileo, Beidou, and IRNSS show as "0", even though the correct identifier value is
probably 3 for Galileo.

Note that typically the corrections to the UTC realization are on the order of nanoseconds,
though sometimes 10's of nanoseconds.

Using one of the '+dUTC_p' options is then a very clean way of extracting all the delta
UTC parameters from your raw data (assuming, of course, these are being stored in your
raw data).

The idea for this option happened when teqc users and colleagues at the NIST (National
Institute for Standards and Technology) in Boulder, Colorado, wanted to see if they could
identify which GPS SV was responsible for the 13-microsecond UTC error on 26 Jan 2016
from raw data collected on that date.  (It turned out to be from SVN 23.  Unfortunately,
in that case, the records in the raw data that the NIST group collected did not have
the SV id associated with the UTC parameters.)

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

"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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://postal.unavco.org/pipermail/teqc/attachments/20170913/435e9d46/attachment-0001.html>


More information about the teqc mailing list