Signal Strength for C1 and L1

My completely uneducated guess about the "1"s in the L1 signal-strength columns is that if the signals were really that marginal (1 is supposed to represent minimum possible value) there would be a lot more cycle slips in the data so maybe it is nothing to worry about. See what comes out of your other receiver, that would be interesting and possibly informative.

As far as your first data file goes, I deleted the data before 1930 hrs (about when it had a good solid 6 satellites, rounded to the half hour) and obtained a solution that shows what I believe to be good sadistics [sic].

                             NGS OPUS SOLUTION REPORT
                              ========================

All computed coordinate accuracies are listed as peak-to-peak values.
For additional information:  http://www.ngs.noaa.gov/OPUS/about.html#accuracy 

      USER: Howard_Inoe                             DATE: October 04, 2011
RINEX FILE: biga274t.11o                            TIME: 16:25:22 UTC


  SOFTWARE: page5  1108.09 master40.pl 060711      START: 2011/10/01  19:30:00
 EPHEMERIS: igr16556.eph [rapid]                    STOP: 2011/10/01  23:58:00
  NAV FILE: brdc2740.11n                        OBS USED:  7221 /  7619   :  95%
  ANT NAME: TRM22020.00+GP  NONE             # FIXED AMB:    39 /    46   :  85%
ARP HEIGHT: 1.0                              OVERALL RMS: 0.013(m)


 REF FRAME: NAD_83(CORS96)(EPOCH:2002.0000)            ITRF00 (EPOCH:2011.7504)
      
         X:      1348632.961(m)   0.010(m)           1348632.178(m)   0.010(m)
         Y:     -4539264.423(m)   0.025(m)          -4539262.999(m)   0.025(m)
         Z:      4258796.096(m)   0.001(m)           4258796.025(m)   0.001(m)

       LAT:   42  9 29.91635      0.015(m)        42  9 29.94919      0.015(m)
     E LON:  286 32 48.79499      0.014(m)       286 32 48.77996      0.014(m)
     W LON:   73 27 11.20501      0.014(m)        73 27 11.22004      0.014(m)
    EL HGT:          209.892(m)   0.017(m)               208.667(m)   0.017(m)
 ORTHO HGT:          240.324(m)   0.031(m) [NAVD88 (Computed using GEOID09)]

I just entered a nominal 1-meter ARP height, you will probably want to use the correct value.

GB

For what it's worth- I rinexed some of my 4000ssi .dat files and they all had "1" in the same columns as yours

Thanks, Glenn and John. It seems that my worrying is misplaced. But, I'll check my other receiver some time to be sure that the RINEX file that it produces also has the columns of 1's.

And, Glenn's solution looks to be acceptable, or at least much closer to acceptable than the results I've yet been able to achieve (peak to peak residuals in the vicinity of a decimeter).

As far as I can tell, the primary difference between what Glenn has done and what I and others have done, is the degree to which he has removed data of questionable integrity.

I was thinking that the OPUS process would do this on its own, but maybe not. Is it fair to say that most users of the OPUS system go through some sort of pre-processing of their RINEX file before submitting? I suppose there are as many ways to do this as there are types of butterflies. What are some of the most popular methods? I'll have to do some additional reading of the TEQC tutorial, but can TEQC be used to automate the filtering of the RINEX file, leaving only those values that are more likely to yield a good solution, and leaving out those values that might detract from this goal?

Using the Trimble Convert to Rinex utility, I discovered that there is an option within that program to write the SNR values into the resulting RINEX file. I suppose this is much the same process that Glenn described in writing the SNR.11o file using the TEQC program. Either way, the bottom line is becoming clear to me, that the S1 and S2 values are nearly equal in magnitude for each satellite, and that the columns of 1's are not worth much more attention. Now, on to editing a RINEX file!

Is it possible that your receiver sat unused for some time (months or years) before you started logging data the other day? Or mayhaps the last time it tracked satellites was hundreds or thousands of miles away?

If either was the case, the receiver would have taken longer than usual to get a good 3D position and track the available satellites.

The almanac generally tells the receiver which satellites it should be seeing from its position at a given time so the receiver can direct its efforts toward locking onto the signals with the pseudorandom-noise (PRN) identifiers associated with those specific satellites. As new satellites are launched, old satellites are retired, and satellites are repositioned in their orbits the almanac information changes. So an old almanac doesn't help much.

It takes about 15 minutes of satellite tracking for a receiver to fully refresh its almanac, about the same time it took your receiver to get up to six satellites. During the time it was only tracking three satellites it did not even have a good 3D position so that did not help either.

Next time you log a session and if time allows, let the receiver run long enough to get a good 3D position and be tracking all satellites in view before you start logging. That will greatly increase your chances of getting a file that will not need any editing. The only downsides to that are 1.) it will be too easy and 2.) you won't learn as much.;-)

Another item semi-related to your two recent OPUS/RINEX threads, yesterday I was searching for information on SNR when I came across a paper entitled Scientific Utility of the Signal-to-Noise Ratio (SNR) Reported by Geodetic GPS Receivers that reports on research by some folks at the University of Colorado.

Apparently this comparison of various receivers was an offshoot of a research project directed toward using GPS multipath to monitor soil moisture. That's a new one for me.

That document says that the older Trimble receivers (up to and including the 4000SSi) used a different method of computing and reporting SNR than that used in the newer receivers (4700 and later). So maybe it is not appropriate to compare the SNR numbers shown by receivers from different eras. That may also offer a bit of a clue as to why the L1 signal-strength indicators in the RINEX files are consistently "1"s?

GB

Good question, Glenn. The DAT file that I originally posted was from an observation session conducted on 10-1-11. The same point was occupied with the same receiver on 9-24-11, so there was neither a great amount of time nor a great amount of distance between the two sessions. However, the one major difference between the two sessions was that the first session was logged to the internal memory of the receiver, while the second session was logged to the memory in a TSC1 controller. Both the receiver and the TSC1 came from Arizona. In any case, I'll see if I can figure out how to tell on the receiver when it is getting a good 3D position, and then begin logging data at that time.

I'll take a look at that paper you referenced. Interesting subject.

Howdy,

FWIW, I converted the first file you uploaded and converted it to RINEX 2.11 using teqc.

The header and extract of some observations should be shown below:

Note the different treatment of S1 and S1 records. The command line to do the translation of the DAT file is:
teqc -tr do "input file" > "output file" with values in quotes (without quotes) the DAT file and file to create. There is no space between the "-" and "tr"

Cheers,

DMM