[teqc] Unexpected behavior when using -tbin with multi-day Trimble 5700 or R7 data

Glen Mattioli mattioli at unavco.org
Fri Dec 14 13:00:00 MST 2018


Bravo 👏 Lou!

Sent from my iPhone

Glen S. Mattioli, PhD
Director of Geodetic Infrastructure 
UNAVCO, Inc.
Adjunct Prof. of Earth & Env. Sciences
University of Texas at Arlington

> On Dec 14, 2018, at 1:38 PM, Neville Palmer <N.Palmer at gns.cri.nz> wrote:
> 
> Wow. Great explanation Lou. Thanks very much.
> 
> The only reason I noticed these differences was that my colleague and I had both RINEXed the same data independently. With and without -tbin.
> 
> We wanted to confirm I wasn't introducing any unexpected problems or differences by using -tbin.
> 
> Your thorough explanations are very much appreciated.
> 
> Thanks again
> Neville
> 
> Neville Palmer | Geodetic Surveyor
> GNS Science | Te Pu Ao
> Sent from my phone
> Mob +64 27 221 8845 | DDI +64 4 570 4714
> 
>  
> From: Lou Estey <lou at unavco.org>
> Sent: Saturday, December 15, 2018 7:27:06 AM
> To: Neville Palmer
> Cc: teqc at unavco.org
> Subject: Re: [teqc] Unexpected behavior when using -tbin with multi-day Trimble 5700 or R7 data
>  
> There is a quote -- often attributed to Otto von Bismarck, but probably originating with John Godfrey Saxe,
> Univ. of Michigan in 1869 -- that laws and sausages are two things that one should never watch being made.
> Following that thought, I would also include RINEX files.
> 
> More disturbing yet, Neville, you are dissecting two sausages, and now asking why one has this bit of fat
> and grizzle whereas the other has a different bit of fat and grizzle -- all the while ignoring the fact that
> there is something telling you that both should be delicious after being grilled.
> 
> So here's part of the sausage making:
> 
> First one has to review tip of week 1976 https://postal.unavco.org/pipermail/teqc/2017/002374.html which gets
> into the two styles of recording RINEX observations:
> 
> 1) the time tags of the epochs have jumps at each receiver clock reset, and phase and pseudorange observables
> remain "smooth" (i.e. no corresponding jumps from the receiver clock resets)
> 
> or
> 
> 2) the time tags of the epochs are "smooth" (no corresponding jumps from the receiver clock resets), but now
> the phase and pseudorange observables contain an offset at each receiver clock reset, in units of cycles
> in phase and in units of meters for pseudorange.
> 
> Style (1), originally used in the RINEX translators of Dr. Werner Gurtner (and, I'm sure, a man who would have
> appreciated a good sausage), was generally abandoned circa 2003 in favor of style (2).  That is, teqc has
> been creating style (2) RINEX obs for the last decade and a half.
> 
> The crux of the differences in the data from your Trimble 5700 and R7 is that they do not have clock steering,
> or it's not turned on.  Therefore the receivers' clocks drift.  For this generation of receivers, I'd expect
> this to be about 5-10 milliseconds per hour, or in the range of 1/8 - 1/4 second per day.  So if you have a
> single file logging for 57 days, a single file could accumulate something like 7 - 14 seconds of drift by the end.
> 
> So what happens with long stretches of data with receiver clock resets?  Well, if the RINEX had been in
> style (1), then by the end of the file the data epochs would have been perhaps as much as 14 seconds out of
> sync with normal GPS time.  (Just imagine the confusion if one were to time window that file and try to
> use the last part without knowing all of this.)  But, with the RINEX in style (2), the time tags of the
> epochs are readily understandable, but now the phase and pseudorange observables -- as represented in
> RINEX -- are absorbing all of those millisecond resets.  Keep in mind that each 1-millisecond clock reset
> would be a positive or negative jump of almost 300,000 meters in each pseudorange observable and the
> corresponding number of carrier frequency wavelengths for each phase observable.  Over many days, these
> can easily add up to where the representation of either the phase or pseudorange observables no longer fit
> (ASCII-wise) in the %18.12lf field allowed for each observable (see any RINEX specification since the
> beginning of sausage making).
> 
> To avoid RINEX formatting problems, teqc tracks how the observables are growing (positively or negatively)
> and, yes, introduces a single large reset of its own when appropriate -- thus explaining the L1 and L2 changes
> that you noted in the 35th day of your long data log.  (This happens on a per observable basis.)  Doing so
> results in a single phase cycle jump for that particular phase value and that particular SV, so it's not
> a problem during processing.
> 
> Next, are the L1 and L2 observables in the two RINEX files really different?  Not really.  Let's take
> at look at the values for the first SV, G06:
> 
> file 1:
> -265042946.332  -205252780.551  @ 00m30s
> -265008452.043  -205225901.887  @ 01m00s
> 
> file 2:
>    -6674066.332    -3926380.551  @ 00m30s
>    -6639572.043    -3899501.887  @ 01m00s
> 
> Here's the epiphany: Representation of phase values in RINEX is not unique.  In other words, one
> can add a constant NsubL1 to all L1 phase observables to a given SV and a constant NsubL2 to all
> L2 phase observables to the same SV, and do that for each SV (with different N's) -- and not change
> processing results.
> 
> So in the above for G06, in file 1 we can add, say, 265042940.000 cycles to L1 and 205252700.000 cycles
> to L2, and then in file 2 add 6674060.000 cycles to L1 and 3926300.000 cycles to L2, and then end up, for
> _both_ files (assuming I did the addition correctly):
> 
>          -6.332         -80.551  @ 00m30s
>       34487.957       26798.113  @ 01m00s
> 
>  From a processing point of view, all of these representations of the phase observables are identical.
> 
> Now why did the phase values end up so differently using '-tbin 1d' (thus daily RINEX obs files) vs.
> a full bore translation into one huge RINEX obs file?  Well, there are certain resets that occur when
> using '-tbin' when switching to a new file.  (More sausage making.)
> 
> I hope that explains all of this well enough for everyone, or at least gets it into a somewhat more
> digestible state. :)
> 
> cheers,
> --lou
> 
> p.s. Now it's time for lunch!
> 
> On 13-Dec-18 08:58 PM, Lou Estey wrote:
> > dear Neville,
> > 
> > The short answer is: There is no problem and therefore both files, either using -tbin or not, are correct.
> > Go ahead and use which ever one you want.
> > 
> > Tomorrow I will attempt to explain, but basically this comes down to your 5700 and R7 not having
> > clock steering, thus millisecond receiver clock resets are taking place, which build up over time,
> > have to be accounted for in RINEX, etc.  All that and the fact that there is no unique way to
> > represent phase values.
> > 
> > cheers,
> > --lou
> > 
> > On 13  Dec  2018 6:46 PM, Neville Palmer wrote:
> >> I have recently noticed that when using the -tbin option to convert Trimble 5700 or R7 dat files to RINEX I am seeing different observable 
> >> values in the resulting file(s) when compared with an equivalent RINEX file created without the -tbin option.
> >>
> >> I have not seen this with any Trimble NetR9, NetRS or Septentrio data files. These produce identical files with either method described 
> >> below.
> >>
> >> The raw data files I am converting are 24 hour (daily) files covering multiple consecutive days. I am converting these to 24 hour (daily) 
> >> RINEX files using -tbin in order to simplify file handling, file naming, etc.
> >>
> >> The following is an example of a -tbin command I am using;
> >>
> >>                  teqc -tbin 1d XXXX +obs + *.dat
> >>
> >> I am comparing the RINEX output from this with the output from a simple day by day conversion similar to this;
> >>
> >>                  teqc XXXXddd?.dat > XXXXddd0.18o
> >>
> >> where “ddd” is the day number.
> >>
> >> If I compare the first day of the -tbin output with the corresponding day-by-day output, the results are identical, as expected.
> >>
> >> For every subsequent day, the -tbin output appears to keep incrementing the L1 & L2 observables from one day to the next, whereas the 
> >> day-by-day output starts with new baseline values for each day/file.
> >>
> >> These continually incrementing -tbin generated files appear to produce valid results if processed and teqc qc does not report any issues. 
> >> The RINEX just looks unusual when viewed in a text editor.
> >>
> >> I have found the unexpected output when using data from the following receivers;
> >>
> >> Trimble 5700 firmware versions 2.32 or 1.20
> >>
> >> Trimble R7 firmware version 2.32
> >>
> >> I have also used the -tbin option with data from the following receivers and not encountered the unusual output. The results are 
> >> effectively identical with RINEXing files day by day;
> >>
> >>                  Trimble NetR9
> >>
> >>                  Trimble NetRS
> >>
> >>                  Septentrio PolaRx5
> >>
> >> I have one example where a 5700 receiver was logging continuously for 57 days. If I run the daily -tbin option on all these files then the 
> >> L1 & L2 observables continue to increase until reaching values of around 4.99e9 after 35 days. On this day, as each SV reaches this value 
> >> it appears to ‘roll over’ and start counting again from a value on the order of 1e6. I have not attempted to process this file yet, but 
> >> teqc qc does not report any issues with the file.
> >>
> >> I have tested this with versions 2018Dec12 and 2018Mar15 on Windows and Linux with the same result. I am not aware of any issues caused by 
> >> the resulting files so far, but thought it worth raising.
> >>
> >> The examples below show output from the two methods for exactly the same data.
> >>
> >> I am happy to provide example raw or RINEX files if that would be useful.
> >>
> >> Example using -tbin;
> >>
> >> This is the first epoch on the 3^rd day.
> >>
> >> ==================================================================
> >>
> >>    2018     1    31     0     0   30.0000000     GPS         TIME OF FIRST OBS
> >>
> >>                                                              END OF HEADER
> >>
> >> 18  1 31  0  0 30.0000000  0  6G06G02G17G12G19G24
> >>
> >> -265042946.33258-205252780.55157  19965958.3914                   19965957.5784
> >>
> >>          52.0004         42.7504
> >>
> >> -264318709.69158-205136702.92256  21287641.7504                   21287636.7974
> >>
> >>          49.2504         36.5004
> >>
> >> -242632276.93857-188935855.59854  21476697.0234                   21476693.5594
> >>
> >>          46.7504         28.7504
> >>
> >> -261460722.21157-203631684.75854  22254935.5394                   22254932.4144
> >>
> >>          47.7504         29.5004
> >>
> >> -251829505.80957-195772771.53155  20869876.0314                   20869871.4344
> >>
> >>          47.0004         35.2504
> >>
> >> -252921611.22755-197109399.84053  22377847.7504                   22377848.8244
> >>
> >>          35.0004         19.2504
> >>
> >> 18  1 31  0  1  0.0000000  0  6G06G02G17G12G19G24
> >>
> >> -265008452.04348-205225901.88747  19972522.1334                   19972522.2034
> >>
> >> =====================================================================
> >>
> >> Example using basic teqc command for a single raw file/day.
> >>
> >> Exactly the same epoch as above.
> >>
> >> =====================================================================
> >>
> >>    2018     1    31     0     0   30.0000000     GPS         TIME OF FIRST OBS
> >>
> >>                                                              END OF HEADER
> >>
> >> 18  1 31  0  0 30.0000000  0  6G06G02G17G12G19G24
> >>
> >>    -6674066.33258  -3926380.55157  19965958.3914                   19965957.5784
> >>
> >>          52.0004         42.7504
> >>
> >>    -5949829.69158  -3810302.92256  21287641.7504                   21287636.7974
> >>
> >>          49.2504         36.5004
> >>
> >>    15736603.06357  12390544.40254  21476697.0234                   21476693.5594
> >>
> >>          46.7504         28.7504
> >>
> >>    -3091842.21157  -2305284.75854  22254935.5394                   22254932.4144
> >>
> >>          47.7504         29.5004
> >>
> >>     6539374.19157   5553628.46955  20869876.0314                   20869871.4344
> >>
> >>          47.0004         35.2504
> >>
> >>     5447268.77355   4217000.16053  22377847.7504                   22377848.8244
> >>
> >>          35.0004         19.2504
> >>
> >> 18  1 31  0  1  0.0000000  0  6G06G02G17G12G19G24
> >>
> >>    -6639572.04348  -3899501.88747  19972522.1334                   19972522.2034
> >>
> >> Regards
> >>
> >> Neville Palmer
> >>
> >> Notice: This email and any attachments are confidential and may not be used, published or redistributed without the prior written consent 
> >> of the Institute of Geological and Nuclear Sciences Limited (GNS Science). If received in error please destroy and immediately notify GNS 
> >> Science. Do not copy or disclose the contents.
> Notice: This email and any attachments are confidential and may not be used, published or redistributed without the prior written consent of the Institute of Geological and Nuclear Sciences Limited (GNS Science). If received in error please destroy and immediately notify GNS Science. Do not copy or disclose the contents.
> _______________________________________________
> teqc mailing list
> teqc at postal.unavco.org
> https://postal.unavco.org/mailman/listinfo/teqc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://postal.unavco.org/pipermail/teqc/attachments/20181214/b4f215f4/attachment-0003.html>


More information about the teqc mailing list