[teqc] helpful tip of week 1962

Lou Estey lou at unavco.org
Thu Aug 17 08:56:06 MDT 2017


This week's tip: using GPS L2C with teqc

This particular issue has come up since L2C first started being operationally broadcast by
GPS Block IIR-14M Navstar 57/SVN53/PRN17 (aka USA 183, GPS 2R-M1, GPS 2R-14M) in Dec 2005 --
although work in teqc for L2C started in Apr 2005 when Trimble kindly provided us some
synthetic data with L2C in .dat and RT17 formats.  As you might know, RINEX 2.11 was never
generalized to allow for a distinction between the phase, signal-to-noise, and doppler of
the L2P(Y) signal vs. the L2C signal, using, respectively, RINEX 'L2', 'S2', and 'D2' for
those observables for either signal.  However, the pseudoranges are distinct in RINEX 2.11,
'P2' for the pseudorange of L2P(Y) and 'C2' for the pseudorange of L2C.

By early 2009, there were seven GPS IIR-M SVs broadcasting L2C.  In August 2009, just before
the launch of the eighth IIR-M SV to broadcast L2C (which would constitute one quarter of the
operational GPS constellation at that point), I was asked to tie the behaviour of RINEX 'C2'
to the phase, signal-to-noise, and doppler observables 'L2', 'S2', and 'D2' in the following way:

- If translating and using the '+C2' option or '-O.obs' with C2, the '+L2C_L2' and '-L2C_L2'
options are ignored; the L2 (and S2, D2) are based on L2C if present, or based on L2P(Y) otherwise.

- If translating and using the '-C2' option (which is the default) and '-O.obs' without C2,
the '+L2C_L2' or '-L2C_L2' option takes effect, allowing pure L2 from L2C or pure L2 from L2P(Y),
respectively; the default would continue to be no RINEX 'C2' and the '-L2C_L2' option set, i.e.
RINEX L2 (and S2, D2) based on L2P(Y).

where, from `teqc +help`, you'll find:

+C2        L2C code pseudorange to be included in default observables (i.e. no use of -O.obs[_types])
-C2        L2C code pseudorange not to be included in default observables (default)

+L2C_L2    use phase/SNR/doppler values in L2C code block (e.g. L2C phase as RINEX L2)
-L2C_L2    use phase/SNR/doppler values in P2 code block (e.g. P2 phase as RINEX L2) (default)

(I refer to this as the "2009 August 3" decision, the main idea of which was that if RINEX C2
were present for any SV -- indicating that SV was broadcasting L2C -- then L2, S2, and D2 for that
SV would automatically be forced to be based on the L2C signal.  Of course, this is only meaningful
for translation, i.e. reading of raw data containing L2C data.  It does not apply if reading
an existing RINEX obs file.)

What some users have noted since then is a difference between what a manufacturer's RINEX 2.11
produces for RINEX L2 vs. what teqc produces.  Let's look at a case.  Below, I've used
`teqc -O.obs l1+l2+l5 -R -E -C -S -J -I ...` to read manufacturer's produced RINEX and
teqc-produced RINEX to get only the GPS phase observables L1, L2, and L5 (so the first column
is L1, the second is L2, and the third is L5), showing just one epoch:

GPS, from manufacturer's RINEX 2.11:
  17  8  7  0  0  0.0000000  0 11G13G26G29G20G21G15G16G10G18G27G04
  119646312.788 7  93230907.372 4
  121235463.355 7  94469200.475 5  90532980.417 7
  117961230.060 7  91917852.576 5
  109729073.670 8  85503176.925 6
  110602819.530 8  86184036.237 7
  115570700.392 8  90055096.306 6
  118540974.992 7  92369571.566 5
  124579990.251 6  97075349.281 4  93030536.296 7
  112501534.048 8  87663541.276 6
  123116723.097 7  95935115.691 4  91937819.626 7
  117189205.883 7  91316270.932 5

GPS, from teqc's RINEX 2.11, where RINEX 'C2' was explicitly requested in the teqc translation:
  17  8  7  0  0  0.0000000  0 11G13G26G29G20G21G15G16G10G18G27G04
  119646312.788 7  93230907.37244
  121235463.355 7  94469218.491 7  90532980.417 7
  117961230.060 7  91917846.557 7
  109729073.670 8  85503176.92546
  110602819.530 8  86184036.23747
  115570700.392 8  90055095.310 7
  118540974.992 7  92369571.56645
  124579990.251 6  97075352.285 6  93030536.296 7
  112501534.048 8  87663541.27646
  123116723.097 7  95935111.699 6  91937819.626 7
  117189205.883 7  91316270.93245

Comparing the two sets, you'll note that different L2 values occur where teqc does not include
a loss-of-lock (LLI) indicator (i.e. it's blank), whereas for the L2 values that are identical
the LLI indicator is '4', which means that L2 phase was collected on a signal with anti-spoofing.
Or, put another way, in the teqc translation:

L2 LLI blank = L2 is from L2C (which does not have anti-spoofing)
L2 LL1 = '4' = L2 is from L2P(Y) (currently all GPS SVs using anti-spoofing on P(Y))

You'll also note that the 0-9 SNR flags are higher on the L2 values from L2C (compared to the same
SV in the manufacturer's translation from L2P(Y)) because L2C is a stronger signal than L2P(Y).
(We would see the same thing if I explicitly show the RINEX 'S2' observable.)

This all goes back to the inclusion of 'C2' in teqc's translation of the raw data due to the above
rules implemented in Aug 2009.  By including 'C2' in teqc's translation, the resulting RINEX L2, S2
and D2 observables for data since L2C started being broadcast will result in a heterogeneous mix
from L2C and L2P(Y), depending on whether the SV is broadcasting L2C or not.

In this case, the manufacturer's translation outputs RINEX L2 only from L2P(Y).  But one can
achieve the same results by not including "C2" in the observation list with a teqc translation
and not using the '+C2' option, e.g.

[5448] teqc +quiet -O.obs l1+l2+l5 -R -E -C -S -J -I raw_data_file
...
  17  8  7  0  0  0.0000000  0 11G13G26G29G20G21G15G16G10G18G27G04
  119646312.788 7  93230907.37244
  121235463.355 7  94469200.47545  90532980.417 7
  117961230.060 7  91917852.57645
  109729073.670 8  85503176.92546
  110602819.530 8  86184036.23747
  115570700.392 8  90055096.30646
  118540974.992 7  92369571.56645
  124579990.251 6  97075349.28144  93030536.296 7
  112501534.048 8  87663541.27646
  123116723.097 7  95935115.69144  91937819.626 7
  117189205.883 7  91316270.93245

Note that all the LLI flags on L2 are '4', indicating they are from L2P(Y).

Likewise, you can insist to see only RINEX L2 from L2C using the '+L2C_L2' option (and, again,
not including "C2" in the observation list and not using the '+C2' option), understanding that
even today only a subset of the GPS SVs broadcast the L2C signal:

[5449] teqc +quiet +L2C_L2 -O.obs l1+l2+l5 -R -E -C -S -J -I raw_data_file
...
  17  8  7  0  0  0.0000000  0 11G13G26G29G20G21G15G16G10G18G27G04
  119646312.788 7
  121235463.355 7  94469218.491 7  90532980.417 7
  117961230.060 7  91917846.557 7
  109729073.670 8
  110602819.530 8
  115570700.392 8  90055095.310 7
  118540974.992 7
  124579990.251 6  97075352.285 6  93030536.296 7
  112501534.048 8
  123116723.097 7  95935111.699 6  91937819.626 7
  117189205.883 7

Note that the L2 values here match what we found in the teqc translation when the observation list
included "C2" (or, equivalently, the '+C2' option was used).

So to get the same GPS L2 phase values from teqc-produced RINEX as from a manufacturer-produced
RINEX which are showing L2 from L2P(Y), you have to give up outputting "C2" when using teqc.

Currently, the formats that teqc can read that might contain L2C data (assuming the receiver
is set up to track L2C):

	o Ashtech B-file
	o BINEX 0x7f-03 and 0x7f-05
	o Javad JPS [3*], [*3] and [rM] messages
	o Leica MDB records 0x77 (119) and 0x78 (120)
	o Septentrio Binary Format (SBF) messages 4027 and 5944
	o Topcon TPS [3*], [*3] and [rM] messages
	o Trimble .dat record 17, .tgd record 27, RT17 0x57-0, and RT 0x57-6

Caveat: What I'm describing in this tip is the way things are supposed to work -- and they
do for most cases.  However, it's entirely possible that you may find an exception, in which
case please report it to me, following suggestions in tip of week 1922:
https://postal.unavco.org/pipermail/teqc/2016/002187.html

Happy teqc-ing!

cheers,
--lou

p.s. Sarah is back, thankfully correcting my grammar and syntax. :)

p.p.s. There may not be a 'tip of week' next week, GPS week 1963, since I'll be in Wyoming
hopefully (and carefully) observing the 2017 total solar eclipse of Saros 145.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://postal.unavco.org/pipermail/teqc/attachments/20170817/0f7f7d0f/attachment-0001.html>


More information about the teqc mailing list