In Survey Pro it's listed as acceptance criteria with VRMS, HRMS and PDOP as my options where I can set a maximum acceptable number for each of the three. For more accurate gps staking, what figures do you guys use? Are the default numbers generally accepted as ideal? If I were to uncheck all of them would I see a drastic reduction in accuracy?
Not necessarily, a fixed integer solution is what it is. Those settings don't affect what the receiver does, they only dictate what the data collector software will accept coming out of the receiver. So if you were in bad conditions yes you would probably get some bad results, but in good conditions you'd get the same results you'd get if you left them checked / on defaults.
The default values are generally set to be realistic - tight enough to hopefully prevent poor solutions and outliers from being accepted but loose enough that the inherent "noise" of the measurement won't cause data to be rejected. I leave them set to the defaults - when we need higher accuracy or reliability we get it through technique.
Lee D, post: 354495, member: 7971 wrote: Not necessarily, a fixed integer solution is what it is. Those settings don't affect what the receiver does, they only dictate what the data collector software will accept coming out of the receiver. So if you were in bad conditions yes you would probably get some bad results, but in good conditions you'd get the same results you'd get if you left them checked / on defaults.
The default values are generally set to be realistic - tight enough to hopefully prevent poor solutions and outliers from being accepted but loose enough that the inherent "noise" of the measurement won't cause data to be rejected. I leave them set to the defaults - when we need higher accuracy or reliability we get it through technique.
The reason I asked is because I'm trying to figure out why my older controller running survey pro 4.7 would get a fix while my new controller on survey pro 5.7 would be stuck on float. I was using the same base and rover in the same location, the weather conditions were very cloudy though. Any idea what settings might be causing this?
I changed the older controller to match the acceptance criteria of the newer one and still it got a fix.
I agree with Lee D.
Unchecking them will only prevent being notified before you screw up. If you are getting lots of warnings, you are probably not working in good conditions.
I'm not familiar enough with Survey Pro to guess at what could prevent you from going from Float to Fixed, but it has to be a setting in the collector if the same receiver / radio combination goes fixed with your older one.
I change it depending on what I am doing. If I am doing something real tight, I will turn down my precision to make it get really tight. If I am doing rough topo, I might turn it up a little. Just depends. That's where the professional judgement comes in to accomplish the task at hand.
I used to abuse my RTK system all the time in the woods shooting corners multiple times. I've probably spent 3 hours on one corner before just making sure it was right. One thing I learned is that those accuracy numbers don't mean a lot in the woods. You go do repeated RTK shots on the same point over a period of time and start developing how close are those shots you learn a lot that way.
Fixed does not always mean that it's fixed in the right spot!
For RTK control I keep mine under 0.05 for H and 0.10 for V, PDOP is set at 4.00.
Here is a link to CT GNSS Standards
Could be that the controller is sending to your rover some stringent criteria for fix/float. For instance, many manufacturers allow users to set what statistical confidence interval they require for the receiver to indicate a fix. It could be that one controller is configuring the rover to show a fixed solution provided the engine has a 95% confidence of having determined the correct integer ambiguity. It could be that the other controller is requiring a 99% confidence.
It could also be that one controller is disabling a constellation, or is raising the mask angle, effectively removing satellites from the solution. This could be happening at the base or the rover. Either one would affect the rover's ability to fix.
Since GPS relies on one way communication from the satellites to the receivers the only thing RMS tells you is an analysis of the data it's getting. It doesn't tell you about orbital errors at the other end.
There's a little bit more material that can add error to GPS. If you wait for precise orbits it can remove one more error source.