Misses the published coordinates for the NGS mon. Both are Nad83(2011) and coord. for NGS mon. is based on GPS observation. Just trying to determine why it??s about double what I??d normally see with VRS and gauge if there is a rule of thumb for error and distance from base?
The workflow you discussed in your first post indicated that you were establishing base coordinates using VRS.
Depending on procedures for occupying that base point with VRS, you could easily have 0.05-0.1' of horizontal precision, at one sigma confidence level. Vertical will be about double the horizontal, and then double both again for a more realistic 95% confidence level.
Then you occupy that point with a base, observe another point with a rover, and you're now compounding centering and measure-up error at both base and rover (not much, but it still has to factor in), plus absolute error and relative error in the observed vector. Most receivers these days are spec'd at about 1cm+1ppm.
So base position error + centering error (base and rover) + measure up error (base and rover) + absolute vector error + relative vector error = compounded error.
That's best case scenario, assuming there are not any significant atmospheric errors or any other systematic errors contributing.
And all of that is in relation to the VRS stations, which are nominally on the NSRS, but likely positioned differently than that NGS mark. How did the NGS mark get positioned, and what are the network accuracies on the datasheet? That is another error source that you have to add to your error budget.
Generally, unless atmospheric conditions are significantly different between the base and the rover, a base/rover setup will usually rival VRS at the horizontal and often outperform it in the vertical, especially when it comes to repeatability, at less than 10-15km. A high power UHF radio doesn't typically go much farther than that anyways.
Now, I love network RTK because it will crank that relative error down to about 0.5ppm, and you can sit at 30-50km away from the nearest base station and still get good positions. But it's not necessarily always the best tool, and will not always outperform base/rover in every scenario.
It's really that base position (especially if derived from VRS) error that will get you, since everything hangs off of that. You're going to want to lock down that position as tight as possible, which means repeated observations at different times of day (can be annoying and impractical), or simply log static during the day and post process (far easier with more user control and often more precise).
(OK, that was a lot longer than I intended. Hope that makes sense, it's still early here.)
We have an old Topcon HiperLite+ base and receiver that we only use to get SPC. We get an autonomous position at the base and collect a couple of points with the Rover. If there are any nearby published points, we hit them as well. Those points are relative to true north at the base station with our data collection software(SurveyPro).?ÿ We then translate to the OPUS solution and rotate the points by the degrees of convergence reported on the solutions as well to get to SPC.
I still think about that first job almost 20 years ago where I missed the rotation step.
1. Setup base and radio and accept whatever initial position it gives me.
2. Connect the rover first to the Indiana VRS like I am used to, then shoot a ??good? SPC position on a project specific marker.
3. ?ÿThen connect the rover to the local base and ??force? the ??good? SPC position from the rover back to the base.
4. ?ÿRock and Roll.
I'm not familiar with Carslon SurvCE procedure. But I suggest eliminating step one.?ÿ
?ÿ
1) Connect the BASE first to the Indiana VRS like you are used to, then store an SPC position.
2) Setup Base RTK using the SPC from the VRS
3) Connect Rover to DC and Base radio, ready to Rock-Roll
........ in the office compare VRS vs OPUS base position
@jmh4825?ÿ
I've never seen a GPS observed NGS monument that far off. Something is going on there. The re-calculated ones are often that far off or more.?ÿ
If I were needing to correct position in the field, that's how I would do it.
Personally, the only time I will connect up to the VRS when running base/rover is if I both have high-quality search coords (which is not often) and I know that they will be difficult to locate (maybe 5% of the time).
Otherwise I'm running with an autonomous position from the base, while logging static.
Search and observe everything I need to over the course of the day, then in the office post process against the RTN stations and/or CORS to position the base. Check with OPUS and/or RTX-PP.
In my view, the whole purpose of base/rover is to have more control over my base position and being able to QC it myself. Final positions likely won't differ from your method by much, and both are valid methods, but I like having that control in the office.
@leegreen This is how I do it. Most or the time I use the OPUS solution as a check and keep the VRS coordinates.
@rover83 ?ÿThanks for breaking that down. ?ÿThis is some of the error value/sources I was looking for.
I use the Mississippi RTN and my network rover to establish the first point SPCS that becomes my base station point #1.?ÿ My field controller has a cellular SIM card and works in conjunction with my rover unit as a RTN rover.?ÿ Then, I set up my base station on the point, start my base, collect OPUS for double-check, and then use my rover unit as a GNSS rover with base.?ÿ My field software will not do stakeout from an autonomous base reference point.?ÿ In a tight, I lie to it with a bogus point, such as dropping the figures to the right of the decimal and rounding off the remaining numbers to the nearest foot or 10 feet. I correct again later with OPUS data.
