Paul
Over the last couple of years, I have done a LOT of experimenting with OPUS_RS, both in Utah AND the surrounding States. This INCLUDES breaking 8+ Hour observations on Control Points (AND PBO sites) into various OPUS_RS files (15, 30, 45 minutes etc.).
My conclusions are as follows.
OPUS_RS return “good” Horizontal solutions (a couple of centimeters or better) MOST of the time. By “Most of the time,” I would say ~90%.
OPUS_RS does NOT return very good Vertical solutions MOST of the time (3-5 centimeters or MORE). By “Most of the time,” I would say ~75%.
In other words, I have found that OPUS_RS is a very good [horizontal] check on Post Processed Fast-Static (30-45 minute, ½ to 2 mile local vectors), but it all too often returns unreliable vertical results. That said, it IS a very valuable tool, I just have to remain aware of its limitations and nuances around these parts.
Loyal
The problem with this logic is that GPS processing depends on simultaneously observed satellites.
It does not matter in your RTK or post-processed solution if one receiver is tracking satellites/signals that the other is not. Only the ones that both are getting are included in the solution as I understand it.
Generally, I would agree with you. Although, Navcom does have an "RTK Extend" option where StarFire corrections will kick in if a radio link is down and the user will seamlessly operate in PPP mode.
If this scenario is possible it would also be possible that for satellites which are not visible at the base station, the rover could still use these satellites in a PPP mode in combination with the RTK mode for the other satellites, but they would not be as accurate as the RTK corrections.
I don't know if they do this case, but if I had said "All software exclude satellites not observed at both base and rover..." then someone would have probably come with an exception to the rule 🙂
Not really.
I used TGO but it went defunct.
I use whatever goes with the receivers, GNSS Solutions with the PM3s.
I use Topcon Tools with the Topcon receivers at work. It's okay.
The navcom/deere receivers produce TWO solutions internally (one RTK with common SV's and one using SV's with Starfire corrections - which may have more SV's than the RTK solution), then they compute a vector between the two solutions. When the base corrections are lost the rover can "fall back" to the starfire only solution (which is on a different datum than your RTK), but will produce values which match the RTK datum because of the vector which was calculated prior to the loss of RTK.
So you are somewhat correct in saying that they are able to use different SV's in each solution.