Action setup for OPUS
- Thread starter Aaron S
- Start date
Nate The Surveyor
Well-Known Member
There are lots of ways to do hings, with Javad. (This seems to be a theme in Javad philosophy).
ONE way, would be to set up the ROVER only, with raw data on, and then use DPOS, to perform CORS processing, on on the 15 minute-2hr observation time.
Another way, would be to set up the BASE, start it normal, using a "HERE" or autonomous base position. Do all your data collection, and then dpos that base file, and it will shift things a few feet, and you now have your SPC coord for your base.
So, depending on your needs, there is more than one way to go at things.
IF there is any kind of SPC already in the area you work, you can also use REVERSE SHIFT.
Anyway, It all depends on WHAT you have, and WHAT you need.
N
ONE way, would be to set up the ROVER only, with raw data on, and then use DPOS, to perform CORS processing, on on the 15 minute-2hr observation time.
Another way, would be to set up the BASE, start it normal, using a "HERE" or autonomous base position. Do all your data collection, and then dpos that base file, and it will shift things a few feet, and you now have your SPC coord for your base.
So, depending on your needs, there is more than one way to go at things.
IF there is any kind of SPC already in the area you work, you can also use REVERSE SHIFT.
Anyway, It all depends on WHAT you have, and WHAT you need.
N
Nate The Surveyor
Well-Known Member
IF you are in need of USING OPUS, then I cannot help much... you can set up either base, or rover, and use net view, and do it all.
N
N
You are correct you will no longer need to use OPUS once you have a Javad base.
As far as your action profiles you should create a duplicate of the WAAS float profile that will accept all solution types. You should rename it OPUS-RS. Recall that profile and go to the collect screen and hit the azimuth box at the top. Hit "What to record" and make sure it is set to record raw data and see where it is saving it. Next go to how to stop and set it to stop with a minimum duration of 1200 seconds or 20 minutes.
Repeat this process with the exception of the renaming of the duplicate profile and the minimum duration 7200 seconds or two hours.
As far as your action profiles you should create a duplicate of the WAAS float profile that will accept all solution types. You should rename it OPUS-RS. Recall that profile and go to the collect screen and hit the azimuth box at the top. Hit "What to record" and make sure it is set to record raw data and see where it is saving it. Next go to how to stop and set it to stop with a minimum duration of 1200 seconds or 20 minutes.
Repeat this process with the exception of the renaming of the duplicate profile and the minimum duration 7200 seconds or two hours.
Nate The Surveyor
Well-Known Member
Aaron, the 5k for a T2 is pennies, compared to what it will do.
The system was built around the relationship between base and rover.
You'll like it!
Get home, plug it in, and 20 minutes later, Ch-Ching! We are on SPC!!!!
N
The system was built around the relationship between base and rover.
You'll like it!
Get home, plug it in, and 20 minutes later, Ch-Ching! We are on SPC!!!!
N
Aaron S
Active Member
Thanks! Do I need to set the HZ rate? I see from the CORS map that the likely stations used by OPUS in Minnesota will all be 5 second rate sampling (that means 5 Hz right?) So If I set to record data at 1 Hz, that would be a waste, wouldn't it? How about the position accuracy screen? Should that be set to "Accept all, including Standalone"?
All of the above applies to the Action Group... do I need to setup anything in particular for the General Group, or doesn't that matter since we are only interested in the raw data that it stores?
All of the above applies to the Action Group... do I need to setup anything in particular for the General Group, or doesn't that matter since we are only interested in the raw data that it stores?
You will want to match the recording rate on the LS to what your CORS will be using.
If you truly desire only a static file, you can setup a General Setup profile for this specifically by selecting "Stand-Alone" as the Operating mode. You will not end up with a point until you send the file off to OPUS.
The valid reason for doing this is when very long static files are desired.
When you use any method that is recording epochs in the manner we do with RTK, or even CDF (Code Float), at 1 per second, that is 3600 epochs per hour, or 86400 epochs for a 24 hour file. It is my opinion that the analysis portion of our software which displays the horizontal and vertical scatter plots during normal collection would tend to bog down. The simple recording of a static file will never bog down.
If you truly desire only a static file, you can setup a General Setup profile for this specifically by selecting "Stand-Alone" as the Operating mode. You will not end up with a point until you send the file off to OPUS.
The valid reason for doing this is when very long static files are desired.
When you use any method that is recording epochs in the manner we do with RTK, or even CDF (Code Float), at 1 per second, that is 3600 epochs per hour, or 86400 epochs for a 24 hour file. It is my opinion that the analysis portion of our software which displays the horizontal and vertical scatter plots during normal collection would tend to bog down. The simple recording of a static file will never bog down.
Jim Frame
Well-Known Member
OPUS decimates the files to 30 seconds, so recording at a higher rate won't help.
Aaron S
Active Member
I can't wait to get that DPOS capability. OPUS has screwed me on this last outing by saying I didn't have a long enough observation, even though I did 20 minutes for fast-static. I'm guessing after it threw out the unusable data, there wasn't enough left over.
Anyway... When I'm doing a DPOS session, it uses a 5 minute observation on the "Boundary" action, and then shifts the points after the adjustments are sent in and returned. If OPUS requires 15 minutes minimum, how can Javad get by with (what I'm assuming is) a solution of equal quality from a much shorter occupation?
Anyway... When I'm doing a DPOS session, it uses a 5 minute observation on the "Boundary" action, and then shifts the points after the adjustments are sent in and returned. If OPUS requires 15 minutes minimum, how can Javad get by with (what I'm assuming is) a solution of equal quality from a much shorter occupation?
That five minute observation is intended for a relatively short base to rover baseline, not CORS to rover. The minimum time needed to get a good solution from CORS to rover will be dependent on the CORS density for your area. I've tried short observations (10min) here in East Texas, but my CORS density isn't quite good enough to get a good answer in this short time. (Although as I think about this, I tested this before we were using the TxDOT CORS in DPOS and was using the NGS CORS which isn't nearly as dense in Texas... but I digress). To get a minimum time span, you'll need to do some testing in your area to see what will produce a reliable answer.
DPOS doesn't work the same as OPUS-RS. OPUS-RS works like PPP, smoothing out error sources (such as the ionosphere, troposphere and time) by using up to 9 CORS that surround the user's receiver. We process vectors from 5 CORS sites to the user's receiver (base or rover). We also process GPS and Glonass, whereas NGS still only uses GPS.
In my area I need 15 minutes and really 20 is probably more reliable. This is in very open skies. Add any obstructions and the time requirement goes up. Accuracy is time dependent also. A 15-20 minute observation will not provide as good a position as 4-6 hours.
DPOS doesn't work the same as OPUS-RS. OPUS-RS works like PPP, smoothing out error sources (such as the ionosphere, troposphere and time) by using up to 9 CORS that surround the user's receiver. We process vectors from 5 CORS sites to the user's receiver (base or rover). We also process GPS and Glonass, whereas NGS still only uses GPS.
In my area I need 15 minutes and really 20 is probably more reliable. This is in very open skies. Add any obstructions and the time requirement goes up. Accuracy is time dependent also. A 15-20 minute observation will not provide as good a position as 4-6 hours.
There are two things going on with DPOS: Process relative position of rover from base, Process relative position of receiver (base or rover) to CORS. Five minutes of data will produce excellent results (in open skies) between the base and the rover. Much better than OPUS-RS. Relative position of receiver to CORS is not likely to be possible in five minutes processing with DPOS.
Nate The Surveyor
Well-Known Member
Opus / dpos is a variable. Depends on lots of things. Around here, it's 80 miles to closest cors. (i don't do meters...)
So.. I want a 4 hr minimum dpos.
So.. I want a 4 hr minimum dpos.
RTK/DPOS. You will be able to use RTK with your own base and use DPOS to check your RTK shots. In really bad areas you may be able to get DPOS to give you a good fixed solution but you need to have multiple observations on the pin to be able to prove the DPOS solution is good. I generally take 3 shots on all boundary points whether it is RTK or DPOS to prove my position.
Aaron S
Active Member
Excellent, thanks. What do you use to qualify a shot as "good"? I know with Trimble stuff it gives you a horizontal and vertical precision for each shot, and everyone generally hangs their hat on that. I suspect with Javad there's a much better metric. So far, I've been going by the shape of the shots cluster, and the box in the upper right (I forget what it's called but it's similar to the Trimble numbers I think). With so many different ways to get shots with the LS, it would be nice to have some common ground to compare shots by all methods... apples to apples or whatever.
I can tell a shot is good by two things. Time between fixed epochs and repeatability (reason I shoot them multiple times). We can expect other to repeat our measurements if we can't repeat them.