We described in the previous Section that once the Network RTK server has received all the reference station observations it reduces them to a so called “common ambiguity level”. The algorithms that do this are specific to the Network RTK server software being used (e.g. Leica GNSS Spider).
Once a common ambiguity level is found, the server software employs a Network RTK method (e.g. MAX) to produce the RTK corrections for the rover.
All Network RTK methods have the advantage of reducing the distance dependent errors and therefore allowing large baseline lengths between the reference stations and the rover. However, each method achieves this in different ways.
To evaluate these different Network RTK methods let us define some criteria.
Network RTK methods can be categorized as either standardized or non-standardized.
A standardized method is a method where the server software uses internationally standardized algorithms to generate Network RTK corrections. These algorithms have been published and are available to the public. This provides consistency and transparency for everyone who uses it.
A standardized method means that all information provided to rovers, regardless of manufacturer, follows clearly defined international standards.
A non-standardized method is a method where the server software uses unpublished algorithms to generate Network RTK corrections.
Rover-Controlled Network Solution
The aim of Network RTK is to reduce the distance dependent errors in the RTK solution – to optimize the solution and to improve initialization speeds over large distances between the rover and reference stations.
Depending on the method, either the server or the rover controls the calculation of the network solution to reduce the distance dependent errors.
A rover-controlled network solution is achieved when the rover can control which reference stations are used in the solution, how many reference stations, and which strategy is used to reduce distance dependent errors.
The advantage of a rover-controlled network solution is that the rover can continually evaluate the quality of its RTK solution and monitor the effectiveness of the distance dependent error corrections it is calculating. If the rover determines that the RTK solution is no longer optimized (e.g. due to a change in atmospheric conditions), then the rover can make an on-the-fly decision and change to a different strategy and calculate a network solution that is more appropriate – therefore maintaining initialization and an optimal RTK solution.
When the server controls the network solution, the server typically uses one strategy for all rovers – optimizing for the network, not for the individual rover. The server does not know how each rover is performing. Therefore, if the network solution is not appropriate for the rover’s situation, the RTK solution might not be optimized and ultimately fast initialization may not be gained.
To ensure fast initialization and an optimized RTK solution, the rover should control the RTK solution.
Maximize Use of All Satellite Data
Network RTK servers collect satellite data from all the reference stations and generate RTK corrections to send to the rover. However, some methods do not maximise the full use of this data. In certain circumstances, this might mean the difference between being able to calculate an RTK solution or not.
For example, imagine a surveyor is in the field observing 8 satellites at their rover. They expect their rover to be able to quickly initialize. However, one of the reference stations being used to generate the RTK corrections is only observing 5 of the same satellites (as the rover). In this case, some Network RTK methods can only generate RTK corrections for the 5 common satellites or must drop one reference station from the solution and therefore weakening the solution. The rover may not receive enough data to initialize quickly and the surveyor is left waiting in the field.
The surveyor might have the best rover on the market, but its performance is being limited by the RTK corrections it is receiving. This is rather like buying the latest high definition TV to watch old VHS videos.
To maximise the rover’s ability to calculate a RTK solution, the Network RTK method needs to maximise the use of all the available satellite data.
Traceability And Repeatability
Traceability is a common survey principle adopted by many surveying authorities around the world. This typically means that all measurements are legally required to be related to physical monuments. These measurements should also be able to be directly re-measured.
For example, a single baseline (dX, dY, dZ) between a reference station and a survey mark should be able to be repeated. This requires physical monuments (e.g. a pillar or peg), and therefore means the measurement is traceable.
Hence, any baselines generated from Network RTK should be traceable and repeatable.
With single reference RTK the position accuracy decreases with distance from the reference station. With Network RTK this effect is reduced. The position and its accuracy should therefore be more consistent (homogeneous) throughout a survey (of course normal good practice guidelines for GNSS surveying, such as satellite availability and DOP values, also apply for network RTK).
A user does not want the position and accuracy to be jumping around. Therefore, positions and accuracies from Network RTK should be consi stent. Before going into detail on the different methods of Network RTK, let’s focus on the relationship between the Network RTK server and the rover. This relationship is the major point of difference between the Network RTK methods.