leegreen, post: 439463, member: 2332 wrote: Just to be clear, don't use a single static receiver for point and send it to OPUS to process. You should run a static network using atleast two GNSS receivers, 4 would be best. Then post process yourself. You can OPUS as a check.
What would be the best procedure if you only have the budget for one unit? Are the results different using 2 receivers simultaneously vs an opus solution?
[USER=10876]@JMH4825[/USER]
Your rover would produce better results when there is also a base setup or you are on a network.
JMH4825, post: 439552, member: 10876 wrote: Are the results different using 2 receivers simultaneously vs an opus solution?
Here's the thing. If you get an OPUS solution on a point it is going to be good +/- about 0.10' or so (maybe a bit better, but not by much). If you did OPUS on two points 10 miles apart, both +/- 0.10', and had an extra long tape measure that could confirm the distance between these two OPUS points was between 52799.90' and 52800.10 feet you would be pretty pleased with that.
But if the points were 10 feet apart, both +/- 0.10', and you measure between them with your tape and get something like 9.90' or 10.10' between them - not so good (By luck you would sometimes get exactly 10.00', but that's just chance). Since you are able to measure the distance between these two OPUS points to a high degree of reliability you know that a better answer lies in giving the taped distance a lot of weight, and adjusting the OPUS positions each a bit to fit the tape between them.
A vector between the two receivers will have an error of just a few millimeters plus a few ppm. So that direct measurement between static receivers is like the tape measure, it tightens up the relative positioning.
In a 10 foot vector the ppm component of the error is virtually nothing. Even in a 10 mile vector it is still pretty small, perhaps a few to several hundreths of a foot. OPUS positions are typically derived using vectors from CORS that may be 50 miles long. In those the ppm error might amount to a few tenths of a foot. That's why an OPUS position has an error that seems to be pretty big. Relative to the points it is being positioned from that are many miles away it is pretty amazingly precise. But when two points positioned separately that way the relative errors will seem large.
Mark Mayer, post: 439565, member: 424 wrote: Here's the thing. If you get an OPUS solution on a point it is going to be good +/- about 0.10' or so (maybe a bit better, but not by much). If you did OPUS on two points 10 miles apart, both +/- 0.10', and had an extra long tape measure that could confirm the distance between these two OPUS points was between 52799.90' and 52800.10 feet you would be pretty pleased with that.
But if the points were 10 feet apart, both +/- 0.10', and you measure between them with your tape and get something like 9.90' or 10.10' between them - not so good (By luck you would sometimes get exactly 10.00', but that's just chance). Since you are able to measure the distance between these two OPUS points to a high degree of reliability you know that a better answer lies in giving the taped distance a lot of weight, and adjusting the OPUS positions each a bit to fit the tape between them.
A vector between the two receivers will have an error of just a few millimeters plus a few ppm. So that direct measurement between static receivers is like the tape measure, it tightens up the relative positioning.
In a 10 foot vector the ppm component of the error is virtually nothing. Even in a 10 mile vector it is still pretty small, perhaps a few to several hundreths of a foot. OPUS positions are typically derived using vectors from CORS that may be 50 miles long. In those the ppm error might amount to a few tenths of a foot. That's why an OPUS position has an error that seems to be pretty big. Relative to the points it is being positioned from that are many miles away it is pretty amazingly precise. But when two points positioned separately that way the relative errors will seem large.
Thanks for the explanation.
Mark Mayer, post: 439565, member: 424 wrote: Here's the thing. If you get an OPUS solution on a point it is going to be good +/- about 0.10' or so (maybe a bit better, but not by much). If you did OPUS on two points 10 miles apart, both +/- 0.10', and had an extra long tape measure that could confirm the distance between these two OPUS points was between 52799.90' and 52800.10 feet you would be pretty pleased with that.
But if the points were 10 feet apart, both +/- 0.10', and you measure between them with your tape and get something like 9.90' or 10.10' between them - not so good (By luck you would sometimes get exactly 10.00', but that's just chance). Since you are able to measure the distance between these two OPUS points to a high degree of reliability you know that a better answer lies in giving the taped distance a lot of weight, and adjusting the OPUS positions each a bit to fit the tape between them.
A vector between the two receivers will have an error of just a few millimeters plus a few ppm. So that direct measurement between static receivers is like the tape measure, it tightens up the relative positioning.
In a 10 foot vector the ppm component of the error is virtually nothing. Even in a 10 mile vector it is still pretty small, perhaps a few to several hundreths of a foot. OPUS positions are typically derived using vectors from CORS that may be 50 miles long. In those the ppm error might amount to a few tenths of a foot. That's why an OPUS position has an error that seems to be pretty big. Relative to the points it is being positioned from that are many miles away it is pretty amazingly precise. But when two points positioned separately that way the relative errors will seem large.
excellent Mark. Thanks
Field Dog, post: 439550, member: 9186 wrote: Thanks to all for replying! Hopefully we'll finish the traverse tomorrow, then I'll post some of the data for your scrutiny.
Be careful what you ask for. LOL!
I'm not sure what session length Mark is referring to. The accuracy of OPUS solutions improves with longer sessions, and you can do better than those numbers but it does take a long time.
The benefit of simultaneous measurements processed against the same fixed stations is that the error due to propagation through the ionosphere will tend to be similar over an area large relative to your project. Therefore the vector between your points will tend to have those errors cancel out and the vector will be much more accurate than the absolute positions.
Taking the vector between two OPUS solutions done at different times and perhaps with different fixed station references will tend to have independent errors and therefore not give you that cancellation of errors.
agreed, but if you have more than one Base won't Opus process the vectors between the bases also?
if Opus can't do that then you need to invest in a post processing program
[QUOTE=Peter Ehlert, post: 439633, member: 60if you have more than one Base won't Opus process the vectors between the bases also?
No OPUS will not process between your own static baselines. You need a post processing program for that.
leegreen, post: 439635, member: 2332 wrote: [QUOTE=Peter Ehlert, post: 439633, member: 60if you have more than one Base won't Opus process the vectors between the bases also?
No OPUS will not process between your own static baselines. You need a post processing program for that.
Well, OPUS_Projects DOES solve simultaneous occupations (multiple USER receivers), ALTHOUGH PAGES (the one used by OPUS_Projects), doesn't necessarily solve ALL of the interstation vectors. PAGES is a "session processor" which works somewhat differently than commercial baseline processors.
BTW, anyone can download and use PAGES_NT (FREE), but it does require some additional training to really get the most out of it.
Maybe GEODMIKE will chime in with a more detailed explanation.
Loyal
Bill93, post: 439615, member: 87 wrote: Taking the vector between two OPUS solutions done at different times and perhaps with different fixed station references will tend to have independent errors and therefore not give you that cancellation of errors.
A vector between Static (OPUS) sessions at different times is not possible. You need 2 receivers running simultaneously to get a vector. Regular OPUS doesn't do that. OPUS Projects does though.
OPUS won't calculate that vector between your two points, but you can calculate it from the values in the two OPUS reports.
Bill93, post: 439713, member: 87 wrote: OPUS won't calculate that vector between your two points, but you can calculate it from the values in the two OPUS reports.
Well, I suppose you could call that a vector, in a sense, but it's not an independent measurement.
One more setup to go to complete the traverse. The last 3 points are GPS points. We plan on 2 more,10 minute RTK sessions for all 5 GPS points. So far the numbers don't look good. GPS-derived traverse points 13 and 14 differ from their instrument-derived points by a few hundredths north or south and almost half a foot east or west! I know the GPS rover changed base stations at least once along the route. The traverse points are about 600 feet apart. This is for a topo, so the engineers can determine which side of a two-lane road a sidewalk should be built.
Looking for an example on how to calculate misclosure and adjustment of an open traverse. Can't find anything plain and simple on the Internet.
[USER=9186]@Field Dog[/USER]
Double meridian distance
Field Dog, post: 439992, member: 9186 wrote: Looking for an example on how to calculate misclosure and adjustment of an open traverse. Can't find anything plain and simple on the Internet.
What projection are you working in FD. Is this a local system or standard projection, i.e. State Plane. If the base was moved while working in a local projection it would explain things getting gobbed up. The east west deviation could be explained if you moved the base using a local projection, convergence from the new bearings from second base location.
Just because I'm paranoid, doesn't mean they aren't out to get me.
Did your traverse run generally in a north-south direction?
Field Dog, post: 439992, member: 9186 wrote: how to calculate misclosure and adjustment of an open traverse.
If it's truly open no closure or adjustment is possible. That's why it's called an open traverse.
Mark Mayer,
I believe Field Dog is asking "how to run a traverse with fixed coordinate pairs at each end, then check closure using Topcon Magnet Field".
Here is a tutorial that should help.
[MEDIA=youtube]2Pxv30oijsQ[/MEDIA]