This last days I have been studying the most optimal way to post process with RTKpost a VRS network RINEX from Leica Spider (sorry no Trimble nor GEO++ network software here)
The most tempting option when requesting the creations of a VRS RINEX is to create the station as closes as possible to the static rover but if you do so I bet you will end up with the same result as I did which is most of the static observations as floating instead of fixed.
So the first question is “is it possible to fix a RINEX VRS solution setup right besides the rover?” The response is “yes, you can”, “how you say?” easy, just set your solution to kinematic instead of static.
What you will get with this is normally distributed noise around a central position (see the screenshot below).
But, Is there a better way (read more accurate) to fix those ambiguities with the default parameters of RTKpost? the response is again “yes, there is”, you just need to create the RINEX VRS at around 7 Km from your rover file, yes, yes, I know, this is totally counter-intuitive but believe me, it works. Instead of setting positioning mode to “kinematic” you set it to “static”, this time the standard deviation will be way smaller and the noise will no longer be normally distributed but will show a heavy temporal self correlation (see the screenshot below).
The following image shows the comparison of the SAME Emlid Reach raw data file processed against a VRS RINEX at 7 Km on the left and at 600 metres on the right. The picture on the left is configured a static observation whereas the picture on the right is set as kinematic observation.
Have a good one
PS1: Please avoid trying to fix GLONASS ambiguities for normal processing
PS2: If you are operating in network fringe area make sure you displace the VRS RINEX towards the inside of the network.
PS3: Those results are leaving most of the parameters to factory defaults. It may well be possible that by altering some of the numerical parameters in RTKpost the solutions change / improve.
PS4: Comments welcome!