OPUS "quaity"
I know that it didn't accept your native format raw file, but OPUS accepts our Topcon raw files with no problems, so we don't have to convert to Rinex. Strange that it accepts some and not others.
I dunno Steve
I ran it again EXCLUDING jxvl, see below:
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: ldogeo@aol.com DATE: October 27, 2010
RINEX FILE: 0024299r.10o TIME: 18:03:57 UTC
SOFTWARE: page5 1009.28 master50.pl 100910 START: 2010/10/26 17:02:00
EPHEMERIS: igr16072.eph [rapid] STOP: 2010/10/26 19:12:30
NAV FILE: brdc2990.10n OBS USED: 4946 / 5989 : 83%
ANT NAME: SOK_RADIAN_IS NONE # FIXED AMB: 53 / 66 : 80%
ARP HEIGHT: 2.0 OVERALL RMS: 0.019(m)
REF FRAME: NAD_83(CORS96)(EPOCH:2002.0000) ITRF00 (EPOCH:2010.8185)
X: 797049.538(m) 0.036(m) 797048.820(m) 0.036(m)
Y: -5469161.655(m) 0.107(m) -5469160.121(m) 0.107(m)
Z: 3172613.163(m) 0.078(m) 3172612.968(m) 0.078(m)
LAT: 30 1 24.43410 0.051(m) 30 1 24.45497 0.051(m)
E LON: 278 17 29.90797 0.020(m) 278 17 29.88971 0.020(m)
W LON: 81 42 30.09203 0.020(m) 81 42 30.11029 0.020(m)
EL HGT: -23.804(m) 0.133(m) -25.305(m) 0.133(m)
ORTHO HGT: 4.318(m) 0.225(m) [NAVD88 (Computed using GEOID09)]
We are now down to Lat_0.051, Lon_0.020, and EH_0.133 but that still isn't a good solution and we are still seeing only 83% of the observations used.
I decimated the file to 30 seconds and washed out the un-necessary observations using teqc, and the file looks pretty clean to me (no serious cycle slips or other obvious problems).
Out here, I use ONLY PBO (Plate Boundary Observatory) Stations, and they are sited/mounted such that their data (and positions) is/are world-class. The fact that changing CORS sites (excluding jxvl) makes that much difference is somewhat troubling to me. The NGS doesn't really have any control over many of the "old" CORS sites, and some of them are not particularly well sited or mounted.
Loyal
Edit...I just noticed that the last run was using the Rapid ephemeris and not the ultra rapid, that "might" factor into things as well!
I dunno Steve
Thank you for examing this, Loyal.
I'll post a pic tonight showing the viewing conditions: there is a 12' oak about 11' east of the nail (Jxvl is NNE). About 35-40' to the west is a strip bldg with a metal "multi-path?" roof.
"...I just noticed that the last run was using the Rapid ephemeris and not the ultra rapid, that "might" factor into things as well!"
Question: the ephemeris that OPUS uses is based on the observation time?
"We are now down to Lat_0.051, Lon_0.020, and EH_0.133 but that still isn't a good solution and we are still seeing only 83% of the observations used."
Are those figures the residuals?
I'm going to try to find out where to measure to for the HI.
[Again, no one needs to freak out because of my incompetence, just trying to learn] 🙂
Thanks,
Steve
I dunno Steve> No freakin out 🙂
Steve, check out this site to find out the ARP for your station....
http://www.ngs.noaa.gov/cgi-bin/query_cal_antennas.prl?Model=SOK&Antenna=SOK_RADIAN_IS [msg][/msg]
Ephemeris
OPUS uses the BEST "available" ephemeris. I always wait AT LEAST until the Rapid Ephemeris is available (the next day or so), and prefer the Precise (final) ephemeris (but that takes a couple of weeks).
The values that I posted above are the peak-peak variances. In my experiance, they "should" be less than 3 centimeters (like OPUS says), but that is entirely dependent on the current Coordinate Estimates of ALL three CORS involved. When the Multiyear Solution is released, these estimates should be BETTER in most ALL cases, and LOTS better in some cases. But now we are getting into the 60 Day Times Series and other "deeper" issues that can wait for now.
Loyal
Time To Split The RINEX File In Two And Submit To OPUS-RS
I have been very disappointed with my OPUS results as of late and have instead split my OPUS-S files into small enough parts (2 or 3) to get OPUS-RS results. Residuals have been on the order of 25% of OPUS-S and the separate solutions are within millimeters.
There are several ways to reduce files, teqc, your GPS software possibly, "Decimate" a tool you can download from NGS or the simple brute force method using a text editor. I open a RINEX file in "Wordpad" and remove the excess data, then edit my "sTime of first observation" which may actually be uneccessary, then save and rename it. Typically my file would be named for my receiver (Z12
a) with the day of year (295 for Friday 10/22) and a number .(period) year 10 and "o", Z12A2951.10o. When I broke that file up I renamed the 2 parts Z12A295P.10o and Z12A295Q.10o. The P and Q use the typical CORS RINEX file convention for the 24 separate hourly files A-X, for 0-23 UTC time. If you note whatever file name you submit to OPUS OPUS renames it to the A-X convention before solving, seee the 4th line of your OPUS solution report.
OPUS-RS is even pickier than OPUS-S on the amount of data it uses, your file may use 75% or less but it is the results that you want. OPUS-RS had good reason to exclude that data, so don't complain. OPUS-RS uses more than the L1 and L2 observables, it also uses the P1/C1 and P2 data. Without good P1/P2 data OPUS-RS will not even attempt a solution and it is often necessary to weed out the first few minutes before all the ambiguities are resolved and noise ignored. Open your RINEX file and take a look at the first few minutes, if you see very small or no numbers for certain observables remove those epochs, edit until your data rows are full up. If your RINEX file gives headers for D1/D2/S1/S2 data and it is all blanks, that is OK, OPUS does not look for that data.
Paul in PA
Don
Thanks for the link, Don.
We measured the HI with the "Sokkia specially calibrated tape for diagonal measurements", from the station nail to the slot at 115.6mm as shown in the image.
That's correct, isn't it? Is that slot considered as the ARP (Antenna Reference Point)?
Thanks, Steve
Ephemeris
Here is a view of the station. A car was parked just a few feet away.
Would you think that these multi-path conditions may be the likely culprit for:
"2. The Peak-Peak Variance on BOTH the Latitude and Ellipsoid Height is greater than 0.030 meters (0.481 and 0.305)."
Thanks,
Steve
Antenna height
Uh....I think that your measurement should be to the bottom of the antenna mount. Where it says on your diagram the NGS Reference point is.
The way I understand it....OPUS always wants the measurement to be the vertical measurement to the bottom of the antenna mount...it then uses the distance they have on file, from the calibrated antenna, to determine the phase center.
Unless...that that special Sokkia tape does that calculation for you. That I do not know.
YMMV....I could be wrong.
Antenna height
Thanks Tom,
I think the special tape just calcs the adjacent side from the measured hypotenuse.
If I did subtract the 115.6mm (0.38') it would help my peak to peak (I think).
Will try it again tomorrow with the correct ARP, and a better ephemeris.
Thanks,
Steve
Ephemeris
Howdy,
Since you now have the raw file converted to RINEX you might consider using the UNAVCO-developed program: "teqc" (it "Translates", "Edits", and performs "Quality Checks") to assess multipath in your observations. The software is available free at:
There is a "lite" and full mode for the output of teqc. The "lite" version generates a summary file named with the input file name and adding a "S" to the two-digit year file extension. This summary file will quantify the magnitude of the multipath as well as providing an ASCII graphic showing the SVs tracked, receiver clock resets and other useful information.
The full version will generate plot files for use with the QCVIEW32 and a few other packages. Some additional tools are available in Matlab to examine these plot files. The plot files include ionosphere, multipath, signal-to-noise ...
The relevant section of the program tutorial (at: tutorial documentation relevant to QC function ) is copied below:
A large portion of teqc is for quality checking or qc-ing of satellite positioning data, mainly NAVSTAR GPS data, but it will generally work for GLONASS and SBAS, though for these latter systems the qc is "lite" (without orbit determination).
To use teqc in a qc mode, try, for example:
• teqc +qc fbar0010.97o
(assuming for the moment that the RINEX NAV file fbar0010.97o is not in the current directory). First, notice the +qc option: i.e., turn qc on. Next notice that there is only a RINEX OBS file as a target file. What you are doing here is running a qc-lite mode, i.e., devoid of any satellite positioning information.
Executing the above should produce something if fbar0010.97o is a valid and complete RINEX OBS file.
Cheers,
DMM
Antenna height> Steve
I believe that you have it Steve..
I have the Sokkia 2700 and it has the same slot. Do the triangle reduction then subtract your Difference, the 115.6mm?
Antenna height
How you measure (determine) your HI (Right or wrong) has NOTHING to do with your Peak-Peak Variance(s).
OPUS Computes THREE "positions" (one from each CORS), and the peak-peak variance is the DIFFERENCE between the highest ellipsoid height and the lowest ellipsoid height of the three solutions (or the "spread" between the North(s), East(s), & H values).
If you have ANY doubt about exactly what the "magic tape" is returning (when you measure to the "notch"), then you really need to figure out EXACTLY what it IS telling you (vertical to notch, vertical to PC, whatever). The easiest way to do this, would be to put your antenna on a 2.00 meter rod, and see what your "magic tape" SAYS. The DIFFERENCE between 2.00 and the tape, is what you need to subtract from the tape reading(s).
Like Mike said above, download TEQC, and get to know it. It's the GPS Surveyor's best friend!
Loyal
Antenna height> Steve
That's what I'm thinking, Don.
Thank you.
-Steve
Antenna height
How you measure (determine) your HI (Right or wrong) has NOTHING to do with your Peak-Peak Variance(s).
Thanks for clarifying that for, Loyal.
OPUS Computes THREE "positions" (one from each CORS), and the peak-peak variance is the DIFFERENCE between the highest ellipsoid height and the lowest ellipsoid height of the three solutions (or the "spread" between the North(s), East(s), & H values).
If you have ANY doubt about exactly what the "magic tape" is returning (when you measure to the "notch"), then you really need to figure out EXACTLY what it IS telling you (vertical to notch, vertical to PC, whatever). The easiest way to do this, would be to put your antenna on a 2.00 meter rod, and see what your "magic tape" SAYS. The DIFFERENCE between 2.00 and the tape, is what you need to subtract from the tape reading(s).
The magic tape is just to measure the hypotenuse (notch to mark) and it reads as if you measured vertically. Good advice to verify what I beleive to be correct.
Like Mike said above, download TEQC, and get to know it. It's the GPS Surveyor's best friend!
It looks very cryptic, but will do.
Thanks,
Steve
Ephemeris
Thank Mike for the direction and the tips. I will wade into it.
-Steve
Gee Paul, your post is 14 years old ... it sounds like you might have used the Sokkia Radian IS(?).
I'm retired, but getting into drone aerials. Bought an old Sokkia Radian IS to get GCP coordinates ... I lived through one rollover, almost forgot we had another rollover.
Obviously the Sokkia *.pcf are not download ready for OPUS, and I haven't looked at the included Sokkia software(it's late now), but forgot what needs to be done with the RINEX file, to make OPUS recognize it ...
John "SURV69"
