[teqc] helpful tip of week 1957

Lou Estey lou at unavco.org
Wed Jul 12 08:16:05 MDT 2017

This week's tip: using Trimble formats

This tip is for users of Trimble receivers.  The goal is to maximize your user
experience (and what you are trying to recover from the receiver) and hopefully
minimize your frustration.

With other receiver formats that teqc can read, you collect what you want on
the receiver, or stream it, and then have teqc directly read it (whether relying
of teqc's auto-identification of the format or needing to supply a format option;
see 'tip of week 1898' http://postal.unavco.org/pipermail/teqc/2016/002092.html).
With data in a Trimble format downloaded from a Trimble receiver, it's often not so

Trimble users eventually will run into files labeled as .r00 (e.g. from the early
Series 4000 receivers) and/or the later .t00, .t01, or .t02.  (Here at UNAVCO we
first encountered the .t00 format with the NetRS and .t02 with the NetR9.)  These
are all Trimble proprietary formats and only Trimble software can read these.  There
is no plan whatsoever to have teqc read these formats; UNAVCO has no documentation
on how exactly these formats are structured or written.  To use data from these
with teqc, you first need to convert the data using Trimble's `runpkr00` software,
which, at version 5.40, Trimble makes available for Mac OSX (10.7), Windows (XP to 7),
Linux, and Solaris x86:
(`runpkr00` stands for "R-utility UNPacK R00", although it has been generalized
though the years to deal with all .r00/.t00/.t01/.t02 variants.)

What teqc _can_ read are the resultant files from converting .r00/.t00/.t01/.t02
with Trimble's `runpkr00`.  Unless the .r00/.t00/.t01/.t02 input is corrupted or
damaged in some way, you should be able to always get a .dat file using runpkr00.
If the receiver is modern enough (e.g. NetRS generation or later) and set up
correctly (e.g. on a NetRS with recent firmware make sure to select the
'Use Record Type 27' option for a session), then you should be able to get a .tgd file.
(Note: ".dat" was obviously named for "data"; ".tgd" stands for "Trimble GNSS data".)
Teqc can read both .dat and .tgd, given the documentation and other information
supplied to UNAVCO through an NDA (non-disclosure agreement) with Trimble -- which
at any time might not necessarily be 100% up-to-date with Trimble's absolute most
recent firmware changes.  From teqc's point of view (and you'll see why below),
you can treat .dat and .tgd pretty much the same way and as as being the same thing.
In fact, the teqc format option is '-tr d' ('d' for download) for both .dat and .tgd
if you need to use an option to specify the input format.

The structure of Trimble .dat and .tgd files is similar, but the internal storage
capabilities for GNSS data in .dat and .tgd are different:

    - data in .dat is only in records 17, which can only store, at most, observables
      for two signals on different carrier frequencies for only GPS or SBAS per SV
      per epoch (e.g. for a particular GPS SV in one epoch, record 17 could hold
      observables for L1C/A _or_ L1P(Y) along with those of L2P(Y) _or_ L2C)

    - data in .tgd is only in records 27, which is fully GNSS capable with multi-signal,
      multi-frequency observables (and no limitations that I know of, as in records 17)

    - both .dat and .tgd can contain other records for metadata, navigation messages,
      ionospheric model parameters, UTC offset parameters, etc., although those in
      .dat are limited to just GPS and SBAS

    - besides the GNSS capabilities, another difference between each record 17 in .dat
      and each record 27 in .tgd is that each record 27 contains the GPS week of the data
      in the epoch, plus the time of week of the data, whereas each record 17 contains
      only the time of week of the data -- but not the GPS week

So, for example, if you want GLONASS or Galileo or Beidou or QZSS data, or want
GPS L1P(Y)+L1C/A+L2P(Y)+L2C+L5 data, you will want .tgd.  To get there, you obviously
need the correct modern Trimble receiver, a compatible antenna, the correct firmware,
and correct receiver settings.  Let's suppose you have a NetR9 and do all that and
then collect .t02 files with full GNSS data: you can still completely miss the full GNSS
target by leaving out the key option, i.e. '-g', when running `runpkr00` and end up
producing .dat files (instead of .tgd files) with just a subset of what you expected.

Pointers for using Trimble's `runpkr00`:

    - execute just `runpkr00` (with no options) to see the version and a listing
      of (most of) the options available with that version (note: option '-g',
      below, may be missing from this listing in earlier versions)

    - always use '-g' option and always use it separately from other options: this
      option instructs `runpkr00` to attempt to generate .tgd with records 27 if
      possible, but if it can't, it will generate a .dat with records 17

    - always include '-d' option to get data records (17 or 27)

    - including '-k2048' skips output of engineering records which teqc probably
      does not understand

    - use of '-f' option is suggested by Trimble to attempt a format "fix" when needed
      if it's possible

    - use '-t<fmt>' if required, where <fmt> = r00, t00, t01, or t02

    - use '-c' to ignore checksum errors

    - do _not_ combine any of the above options into one flag, e.g. '-dg' will
      not (or may not) produce .tgd when '-d -g' can produce .tgd (assuming the
      .t00/.t01/.t02 being read has what is needed for a .tdg)

    - a '-m', which can be included with '-d', produces a small file with a '.mes'
      suffix; this is an ASCII "message" file containing some useful metadata

    - our standard useage at UNAVCO: `runpkr00 -dm -f -g -k2048 <filename>`

Ok, now for Trimble's streamed data equivalents: RT17 and RT27.  You will probably
guess by now that RT17 is the stream equivalent of a .dat and RT27 is the stream
equivalent of .tgd -- which is true to the degree that the various .dat/.tgd
records are represented in the streamed versions.  You should be able to read
RT17 and RT27 directly with teqc, using, when needed, the option '-tr s' to
force specify the input format ("Trimble stream") for both.  For completeness,
I'll just mention (and this is a little odd and confusing) that RT17 does not
contain data records 17 like in .dat and RT27 does not contain data records 27
like in .tgd; instead, each epoch of data in RT17 is in one or more 0x57 records,
subtype 0 ("0x57-0" for short) and each epoch of data in RT27 is in one or more
0x57 records, subtype 6 ("0x57-6" for short).  But it turns out that the
"data payload" portion of 0x57-0 and 0x57-6 are similar enough to a record 17
and record 27, respectively, that the same pieces of code in teqc do both:

C function decompose_Trimble_17_57h_0() for reading .dat record 17 and RT17 0x57-0
C function decompose_Trimble_27_57h_6() for reading .tgd record 27 and RT27 0x57-6

... and which is why code changes in teqc made for one format may effect reading
the related format.

Also, the streamed RT17 and RT27 formats do not have the full set of metadata
records that are in the .dat and .tgd formats.  It so happens then that if a
stored file of an RT17 stream only contains data (in RT17 0x57-0 records) and
no other records (like for GPS navigation messages), then one has to rely on
external information to know in which GPS week the data were collected, because
each 0x57-0 record, like each record 17, does not store the GPS week of the epoch --
i.e. you know when in "the GPS week" each epoch of data occurred, but you don't
otherwise know what that GPS week was.  (I'm guessing that, probably, back when
RT17 was first designed, it was only thought of as a format for real-time applications,
and saving files of RT17 for long periods of time was not considered.)  This
problem does not occur with RT27, because 0x57-6, like record 27, contains the
GPS week value for each epoch of data.

Another little detail on Trimble receivers: tracking GPS L1P(Y) is, as far as I
know, only possible if anti-spoofing is off on the GPS SV and otherwise the receiver
defaults to tracking GPS L1C/A.  Which is why you only rarely see RINEX 'P1' data
for GPS from a Trimble receiver.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://postal.unavco.org/pipermail/teqc/attachments/20170712/85b5e25e/attachment-0001.html>

More information about the teqc mailing list