If rfc hadnÛªt already taken the title, it should be Grasshopper Chronicles, as I learn to work with that old Trimble 4000sst (prior thread).
I found a series of steps to download and convert data from the receiver, and to edit the incorrect date. I found WinTeqc to be very helpful in getting started, but things work better if I run Teqc with batch files to supply some options. I havenÛªt really digested the 10-page (!) list of options yet to know if IÛªve done the best job of picking them, but it does work.
I collected a 10.6 hour session on a point in my yard. The planning tool shows a PDOP spike in there but overall pretty decent. ItÛªs a very poor GPS site with the aluminum siding 20 feet north and leafless trees to the east and west, but it is about the best I can do at home where I can run the unit on AC power, and also I have triangulation/resection/leveling data I wanted to compare for that point.
OPUS picked CORS that were 81, 30, and 75 km away (rapid orbits). I then forced it to use one 8 km away (IAMN) that NGS shows had continuous data for days around my observation time. It gave nearly the same location values: 3 mm different horizontal, and 12 mm different vertical. The reports gave the same overall RMS value, 2.2 cm.
The solution using the closer station has some better error statistics:
latitude 0.032 m vs 0.078 m,
height 0.043 vs 0.128,
and ortho 0.073 vs 0.217,
but the longitude degraded to 0.032 vs 0.018.
-->Why would the solution with the closer station give worse longitude error?
-->Why would OPUS not pick the close one?
I extracted a 2-hour (minus one epoch) segment and tried OPUS-RS. It is still giving me the message ÛÏAborted ÛÒ after single baseline analysis fewer than 3 usable reference stations remain.Û I see previous queries about this message that were usually answered, ÛÏwait longer to submitÛ so IÛªll do that, but the observation finished Thursday morning and now itÛªs Sunday evening.
-->But if I have OPUS using 3 reasonably close stations (rapid orbits), why canÛªt OPUS-RS use them?
-->If I get OPUS-RS to work, and send it more than two hours of data, will it abort, just use the first 2 hours, or what?
-->When some satellites show bad QC results or there is a PDOP spike, does OPUS filter that so it doesnÛªt degrade your results, or are you better off to eliminate the unreliable stuff yourself?
-->IÛªve seen some signal to noise numbers up in the 20Ûªs on the receiver display. IÛªm not sure if that is power ratio or decibels. The Teqc report shows nothing close to that ÛÒ barely into the teens, and again IÛªm not sure which measure is reported The documentation says ÛÏreceiver specific unitsÛ. Since 10 log 20 = 13 I wonder if one display is using each measure. Anybody able to clarify?
-->The L2 snr numbers are usually quite a bit lower than the L1 numbers. Is this normal, or is it due to the limitation that was mentioned of the squaring receiver design? What should I expect the L1-L2 difference to be?
-->My goal for this unit was to submit GPS On Bench Mark data to NGS. Assuming I check myself on a HARN station before trying other marks, and pick marks with good sky, at times of low VDOP (or PDOP?), will this unitÛªs data be good enough, considering the L2 squaring issue?
OPUS does not need to use close stations for good results. OPUS may know that the closer station is acting funky. As in the antenna may have actually moved, etc.
L2 is a stronger signal than L1, so the signal can overcome the noise. That is one reason L5 has been developed to essentially be the new L1 with stronger signal.
OPUS uses you L1 and L2 data. OPUS-RS uses L1, L2, C1 or P1 and P2 or C2 which you may have to tell your software to output to RINEX. By using more data observables OPUS-RS can give you a solution with less time. However OPUS-RS is more finicky about the observables and even rejects COS data. OPUS-RS also limits the CORS chosen to be much closer than OPUS allows. Often the CORS data is late and/or requires some cleaning up which takes time. Resubmit to OPUS-RS a day or two after you get such a message. Very likely the problem is with your first few minutes of data, so delete the first 5 minutes and try again. If you look in your RINEX file you may see that initially the C1 or P1 and P2 or C2 has not yet been resolved or output.
As an aside divide your L1 number by the L2 number and you will see close to 1.28333333 the ratio of the L1/L2 frequency or wavelength, can't remember the numbers off the top of my head. The C1 or P1 and P2 or C2 numbers are the distance from the satellite to your antenna in meters the difference being the different wavelengths are affect differently by the atmosphere. When that distance number begins with 19 check your planning and you will see that that satellites is practically straight overhead at that time.
Sometimes it is necessary to use teqc to reduce your RINEX files to only the 4 components that OPUS-RS is looking for. That is an easy pick option in the online WINteqc program.
When OPUS is on it's game it will send a long/short file to the correct format without even telling you.
Over the weekend I got some back from OPUS-RS that I had sent to OPUS.
Paul in PA
If you send OPUS-RS a file with more than 2 hrs. data it recognizes that fact and quits. Emails you a message. If you send OPUS-S less than 2 hrs, same thing.
As Paul says, not all CORS are created equal. For some reason your nearby station is being excluded. I doubt that the reason is any more fundamental than that.
Probably there is some problem with your truncated file. 3 days lag time should be abundant.
That unit should do very well for GPS on Benchmarks. If you want to keep expenses down, invest in a decent Rover Rod and a Hold A Pole to allow you to use a standard tripod to hold the rover rod plumb. There is a Hold A Pole included with each OPUS X90 setup and it seems to work very well. A good SECO Fixed height Tripod is $800 roughly. Another test you could run is to observe on a BM that someone else has already sent in to OPUS DB and compair your results. You will not be dead on the money but it should give you a warm fuzzy feeling about your accuracies.
:stakeout::gammon::plumbbob::totalstation::-D:good::good::good:
On the issue of using squaring L2 receivers for GPS on Bench Mark campaigns, it appears from the official guidelines, NOAA TM NOSNGS-58 (page 5) that dual frequency full wavelength receivers are required. While these specifications were developed for those planning to submit survey projects and not submissions to OPUS, I would question the acceptability of squared L2 receivers for GPS on BM campaigns.
I suggest contacting your nearest NGS state advisor or the NGS Height Modernization program manager for a definitive answer.
The issue is one of how accurately the integer unknowns can be determined. At the 2 to 5 centimeter accuracy standard wrong integers or float solutions (most integer unknowns unresolved) will not provide the quality of data needed.
In closing, I hope you are examining the extended output from the tools. The output provides a very detailed summary of station to SV relationships. The teqc summary file is also quite useful for understanding your receiver's performance.
Good luck,
DMM
