Network Real Time Kinematic GPS
GNSS Solutions” is a regular column featuring questions and answers about technical aspects of GNSS. Readers are invited to send their questions to the columnist, Dr. Mark Petovello, Department of Geomatics Engineering, University of Calgary, who will find experts to answer them. firstname.lastname@example.org
Q: What is the effect of user and CORS height on NRTK performance?
A: Network Real Time Kinematic (NRTK) positioning is nowadays a very common practice in many parts of the world. The benefits of NRTK positioning and the details of network products have been previously discussed in this column (see the contribution by Leila Kislig in the July/August 2011 issue of Inside GNSS), as has the positioning performance as function of the inter-station distances of the network’s continuously operating reference stations (CORS) (see the contributions by P. Dabove et alia in the November/December 2011 issue).
However, because GNSS measurement errors are modelled by the network software, the quality of the dif-ferential corrections sent to the rover depends on the ability of the network to estimate errors (mainly the atmospheric ones) at individual stations, as well as the capability to spatially model the errors.
So, what are the CORSs requirements in order to have good NRTK positioning, considering a multi-fre-quency and multi-constellation receiver, even in areas with extreme changes in altitude? More specifically, can a heterogeneous network in terms of height of CORS sites be used to obtain centimeter-level accuracy for the rover?
We carried out some experiments to answer these questions and present the results in this article.
The network was adjusted according to the EUREF Permanent Network (EPN) Processing Instruction for Local Analysis Centres (see EPN Guidelines in the Additional Resources section near the end of this article).
For real-time processing of the network data, the Politecnico di Torino has set up a server on which it has installed some network software that performs simultaneous processing of all stations in the network. This provides a better estimation of the global parameters (e.g., ionospheric and tropospheric errors, satellite clock error, ambiguity phase fixing) and increases the reliability of the results compared to the single-station approach.
The CORS network has an average height of about 1,000 meters but the height distribution of stations is highly uneven, varying from as low as 300 meters (Novara) to more than 3,400 meters (Jungfrau Joch — JUJO).
The network software is able to fix the carrier phase ambiguity of the entire network within a few minutes of activation and, apparently, none of the stations are particularly disadvantaged in terms of the percentage of “fixed” satellites. However, the state of the network must also be assessed for measurement quality. In particular, a strong height variability may have an effect on the modeling of atmospheric errors, especially on tropospheric delays — which themselves are highly sensitive to height.
In fact, the sensitivity of GNSS errors with height likely caused the exclusion of the Jungfrau Joch station from the real-time products of the AGNES network described in Leila Kislig’s July/August 2011 article.
The chosen test sites were: Varallo Sesia, Alagna Valsesia, Pianalunga and Punta Indren, as shown in the magnified rectangle in Figure 1. We chose these locations to verify the functioning of the CORS network near (but still within) the limit of coverage: the local ski lifts enabled us to go to Punta Indren, a site located approximately one kilometer inside the edge of the network.
The heights of the stations are summarized in Table 1 (inset photo, above right).
The rover receiver that we used is able to receive differential corrections in a variety of formats. For the purpose of this work, the format selected requires knowledge of the user’s location (provided to the network using a two-way communication channel) and is similar in concept to the virtual reference station approach described in the July/August 2011 “GNSS Solutions.” However, unlike that case, the format used here always provides corrections for real (instead of virtual) reference stations. In this way, the baseline between a master station and the user is measured directly.
Our data analysis compared the coordinates obtained using NRTK with those obtained using post-processing. The reference coordinates of the points indicated with the blue triangle in Figure 1, herein called “true coordinates” for simplicity, are in fact obtained using a commercial GNSS processing software and is based on an adjustment of three static, single-base station processing runs using stations at Zermatt, Biella, and Domodossola. The final accuracy of the true coordinates is a few millimeters.
Analyzing the results at the lower altitude point (Varallo Sesia), we noted both a planimetric and vertical shift with respect to the results obtained from the post-processing position. We should point out, however, that the planimetric average remains within the threshold.
Regarding the height, an average shift of about -8 centimeters can be seen in addition to the presence of numerous points outside the 7.5-centimeter threshold.
Also, for the second measurement site (Alagna Valsesia) we can observe a shift in both the planimetric and vertical solutions, even if the amount is less than the previous case. The planimetric average is still acceptable, while the altimetric average is around the value -5 centimeters. This means a slight improvement in the result of positioning relative to the lower altitude receiver.
The third measurement site (Pianalunga) shows the presence of a false fix of the ambiguity phase identifiable in the point cloud that deviates notably from the mean value. If this false fix is not included in the computation, it is possible to affirm an improvement in the average value of the deviations from the previous cases, especially in the vertical component where the cloud of the points has a mean close to zero, except for a few values near -5 centimeters.
Despite having requested a network-based correction, analyzing the LOG file from the network software showed that the differential correction broadcast to the rover was instead coming from the nearest reference station (Zermatt, about 20 kilometers away). The same behavior was also observed for the final site (Punta Indren). Nevertheless, the results obtained in these are the best: both the planimetric and the altimetric averages are quite close to zero.
This is very interesting because it allows us to understand the limits of the NRTK positioning, considering the height difference between the rover and the master stations of the cell. In this case, when the rover’s height is more than 1,500 meters with respect to the lowest station of the cell, the network software broadcasts corrections derived by the nearest station instead of the requested network correction (it is noted, however, that other network software may or may not exhibit similar behavior).
Unfortunately, unless a user is using the RTCM protocol, it is not currently possible to determine in real-time whether the network is broadcasting corrections interpolated from the network or from the nearest reference station only. To do so requires analyzing the LOG file provided by the network software (if it is available) or evaluating the distance between the positions of the rover and the master station (if it is avail-able during the survey).
We should also note, for the network software used in this study, only two documented possibilities exist with which to obtain a nearest-station correction instead of a network-based correction. The first is if the rover is outside the network, but that is not the case here. The second is if one or more master stations shares only a few fixed satellites with the rover, but this case is excluded here, too.
The take-away from this is that even if the user is aware of the type of corrections being received, in the absence of a proper modeling of atmospheric errors due to the strong variability of the station/user heights, the network software automatically provides the data of nearest station, thus providing acceptable positioning accuracy.
The preliminary results allow us to confirm the good operation, even at high altitudes, of a GNSS heterogeneous network because the network itself is able to detect when the rover is performing positioning at altitudes that are much higher with respect to the average of the considered cell.
Regarding positioning at lower altitudes, the results are slightly worse due to the difficulty encountered by the network in correctly estimating the atmospheric biases on stations with considerable differences in heights.
We can say, therefore, that in the presence of this type of network, it is essential to increase the number of permanent stations regardless of the planimetric inter-station distances between them. Rather, users must ensure that wide variations exist in elevation between nearby permanent stations, in order to limit erroneous estimation of atmospheric biases on GNSS signals. The number of “extra” stations is still an area of study but is expected to be a function of the vertical inter-station distance between the CORS.
ManufacturersThe receivers used in the experiments were GX 1230+ GNSS from Leica Geosystems, Heerbrugg, Switzerland. Initial adjustment of the network used Bernese GPS Software 5.0 developed at the Astronomical Institute of the University of Bern. The network software was GNSS Spider v4.2 distributed by Leica Geosystems, and generation of truth coordinates used Leica Geo Office v.8.0.
Copyright © 2017 Gibbons Media & Research LLC, all rights reserved.