But the real reason I am posting....
For a good opus report, how long minimum for an observation?
Gettin' kind of personal aren't you? 😀
Kidding aside, I look forward to answers. I would think OPUS-RS would handle the shortest - thus the Rapid Static suffix. Maybe 30 minutes.
I do know there are a couple of NGS guys that lurk here. Perhaps they'll chime in.
I prefer a minimum of 4 hours...6 is BETTER!
Due to our modus operandi, we usually get 8-12 hours on each "base point" (for each day that we use it). So generally speaking...each base point gets HUNDREDS of hours, spread over a month (or a year), or more.
In my experience, after the third solution, you are into the "how many fairies can dance on it[?]" range.
Loyal
Foe OPUS-RS (which I prefer to OPUS), I like a minimum of an hour and if time permits just short of 2 hours. Most of the time we do these we are doing the observation for height so I like the extra time.
I had 10 fairies dance on mine yesterday and it was very satisfying.
Thanks Dave. I held out for one hour. Just needing a quick verification on a reported SPC system which I think is goofed up. My normal observation times are minimum 4 hours and usually all day.
Good opinions here but doing some project planning does not hurt. It use to be mandatory to do back in the day as they say. Obstructions, # of Sats and one should take note of proximity to CORS sites.
here.. using opus RS , one would be ok with a 20 minute session. similar to rapid static times.
OPUS requires 2 hr. for data processing. I like to do longer (15 minutes) to trim files if needed.
For tight elevation work. 4+ hours on two different constellations sessions.
There is very good CORS density here but OPUS-RS will spit back sometimes.
> But the real reason I am posting....
>
> For a good opus report, how long minimum for an observation?
Longer than it would take to just do a SunShot.
LOL
B-)
We gather data in our base any time we use it. Usually we end up with 6 hours or more. If vertical is a concern I split the data into 1 hour segments and process through OPUS RS. There are shorter jobs where we upload a two hour session. This is fine when the spec is one meter absolute.
We cover a large area so these are general procedures. In most cases we also have public domain or passive mark static data to augment our solutions.
In Colorado It Should Be Longer
There is a chance you will not get a good OPUS-RS every time in Colorado. Plan on 2.5 hours and split your file to OPUS-RS.
Paul in PA
In Colorado It Should Be Longer
Why? Inquiring minds want to know.
I like to think in terms of quality over quantity.
Give me thirty minutes of good, clean ... data,
over hours of gobbed up, chew your leg off cycle slips, any day.
🙂
This Is Why Colorado Should Be Longer
OPUS-RS provides precise positions with short observation time.
Precision is possible because twice as much data is used per time increment.
OPUS uses L1 & L2, OPUS-RS uses L1, C1/P1, L2 & C2/P2.
OPUS uses 3 CORS, possibly far away. OPUS-RS uses up to 9 CORS if they are close.
OPUS uses long observations to resolve atmospheric corrections. OPUS-RS uses long CORS observations to resolve the most probable correction in the short OPUS-RS submission. To get the best correction it surrounds the observed point with CORS and interpolates a correction. If the corrections are right and the data is clean OPUS-RS can resolve all ambiguities in as little as 3 epochs, that is 1 minute start to finish. I know it is possible because I did it years ago when I was playing with the OPUS-RS beta RSGPS version and used 5 minute long files then went shorter.
Based on the strengths of OPUS-RS let us look at Colorado.
CO has 29 CORS for 104,000 Sq.Mi. or 1 per 3,600 Sq.Mi.
However 17 CORS are in very mountainous terrain in the central western 1/3 of the state. 10 CORS are strung in a North-South direction along the plains-mountains merge line. Only 2 CORS are in the eastern 1/4 of the state. The 7 states surrounding CO have very few CORS that would contribute to a CO OPUS-RS solution. They are WY-2, UT-3, AZ-1, NM-5, TX-4, OK-1, KS-0 & NE-2 for a total of 18. In the very mountainous areas you will lose satellites and have fewer common observations. That further weakens a solution.
Compare that with Pennsylvania, 28 CORS for 45,000 Sq.Mi. or 1 per 1,600 Sq.Mi.
Those CORS are spread uniformly around the state except for the Erie area. Plus PA is surrounded by 6 states with CORS that regularly contribute to PA OPUS-RS solutions. They are OH-5, WV-3, MD-10, DE-3, NJ-11 & NY-12 for at least 45 additional CORS. I can go practically anywhere and have in PA, MD, NJ & NY and expect an acceptable 30 minute OPUS-RS for good elevations, so I go with a 1 hour minimum.
With preplanning it is possible to get OPUS-RS with useable elevations in about 1/5 of CO if everything else goes right. Were I in CO I would use a 2.5 hour minimum in that limited area, split into 2 or 3 OPUS-RS submissions knowing I could still get an OPUS solution.
Paul in PA
This Is Why Colorado Should Be Longer
Thank you for the explanation.
This Is Why Colorado Should Be Longer
I've tried a few OPUS-RS in rural Utah and got total crappy results. I just wrote it off as even a possibility for usefulness. I'm thinking it's because of the low density of CORS so I'd agree with what you say here but I've not tried to come up with as detailed an explanation. For me it was just I tried a few, it didn't work, end of story.
My solution reflects this problem.
The CORS used are pretty much in a long straight line down the front range along I-25. I'm on the wrong computer to post the results. My position did not fall within the polygon enclosing the reference stations. That probably explains why there are at least three different opinions of the SPC for the point in question.
This Is Why Colorado Should Be Longer
Very good explanation Paul.
I normally run 45 to 60 minute OPUS-RS sessions, but I can get good results in as little as 20.
But in this area we are very lucky. I have 18 CORS sites within 50 miles of me.
