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

Lou Estey lou at unavco.org
Fri Dec 14 11:27:06 MST 2018


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.



More information about the teqc mailing list