As promised, I took my new u-blox NEO-M8T outside. My first test simply consisted of evaluating the data quality of the carrier-phase and code measurements collected with a 20$ patch antenna. To achieve this, I have simply put the antenna on the roof of my car and parked on the street for 45 minutes. Results show that a cm-level precision is definitely achievable in a pseudo-kinematic mode using the PPP-RTK processing scheme, although code measurements contaminated with multipath significantly impacted the solution when no precise ionospheric information was provided to the filter.
I first started by analyzing the multipath on the code observables. To do this, I computed the difference between the code and phase measurements of each satellite collected at a 1 Hz sampling rate, assuming that the ionospheric delay variation is negligible with respect to code multipath. The figure below shows this time series for satellite G13, tracked at an approximate elevation angle of 15 degrees. The multipath signature is clearly apparent which should not be surprising given the quality of the antenna and the surrounding environment. Since nearby houses could either cause signal obstructions or act as reflective surfaces, I ended up applying an elevation cut-off angle of 15 degrees because satellites tracked at a lower elevation suffered from much larger errors.
Fig 1 Multipath on the C1C signal for satellite G13
To process the data, I used the integer clocks from the Centre National d’Études Spatiales (CNES). Using the widelane biases provided in the clock file header and the P1-C1 and P1-P2 differential code biases (DCBs) provided by CODE, I generated biases on L1, L2, C1, P1 and P2 using the methodology described in a previous blog post (see case 2). The biases resulting from this transformation allow for ambiguity resolution on the L1 phase measurements only.
I then processed two nearby permanent reference stations operated by NRCan, NRC1 (18 km) and CAGS (22 km), using PPP-AR to extract precise slant total electron content (STEC) information from GPS satellites only. Even though this data was processed at a 30-sec interval, precise ionospheric corrections can be interpolated to fit the 1 Hz data of the u-blox.
The u-blox data was processed using the PPP-RTK method using the following inputs:
- Satellite orbit and clock products (from CNES)
- Code and phase biases (computed as described above)
- A global ionospheric map (GIM) from CODE
- VMF1 grids to compute the tropospheric zenith delay
- Precise ionospheric (STEC) corrections (computed as described above)
Both GPS and GLONASS data was used to estimate the rover position, the receiver clock offset, carrier-phase ambiguities and stochastic slant ionospheric delay parameters. The latter were constrained using both the GIM and the STEC values from nearby stations, and a random walk process noise of 3 cm/sqrt(sec) was applied to model the time variation. No residual tropospheric zenith delay was estimated to match my default settings for single-frequency PPP processing.
The figure below shows the convergence of the solution in static mode. It took approximately 16 minutes to achieve ambiguity resolution on most satellites. This time varies as a function of many factors including observation weights and ambiguity resolution strategy, but it is encouraging to see that ambiguities did indeed converge to integer values. Unfortunately, it is not possible to determine with certainty if the estimated position is correct since the antenna was not at a known location, but there is no apparent reason to believe otherwise.
Fig 2 Convergence of the u-blox position in static mode using PPP-RTK
Using the same configuration, the data was then processed in kinematic mode. The figure below shows position differences with respect to the static position determined above for a smoothed (forward+backward) solution. Ambiguity resolution could again be achieved for GPS signals and the results show a precision of 9 mm, 7 mm and 19 mm for the latitude, longitude and height components respectively. These results seem quite decent to me, given that the reference stations providing STEC corrections were about 20 km away. The residual ionospheric errors are estimated within the positioning filter but this process is obviously not as precise as with dual-frequency receivers.
Fig 3 Position estimates of the u-blox in kinematic mode using PPP-RTK
The data was processed one last time by removing the precise STEC corrections, but keeping all other processing options the same. The figure below shows position errors at the meter level with respect to the static solution. The position biases indicate that the solution did not have time to converge, which is quite reasonable considering one hour of data from a single-frequency receiver. Estimating stochastic ionospheric delays using code measurements contaminated with large multipath effects impacts the stability of the solution and does not seem like such a good idea in this context. While this technique worked well with geodetic-quality antenna and receivers as demonstrated in a previous post, more work seems required to improve its reliability with low-cost receivers.
Fig 4 Position estimates of the u-blox in kinematic mode without precise external ionospheric corrections and estimating slant ionospheric delay parameters
The next step would be to take the receiver on a ride, although I need to think of ways to define a reference trajectory...