It has been a few weeks since my last update on the u-blox data processing. The lack of stability of the position estimates in the single-frequency PPP (SF-PPP) solution without precise external ionospheric constraints bothered me and I spent some time thinking about possible means of improving the solution. In this blog post, I present the preliminary results of my investigation and I invite everybody with insights to share them so that we can all solve this issue.

Estimating slant ionospheric delays in the SF-PPP filter is quite a reliable approach for stations equipped with geodetic-quality receivers and antennas. Choke-ring antennas eliminate a great deal of the code multipath and further multipath and noise reduction algorithms in the receivers can provide pseudorange noise of 10-20 cm at higher elevation angles. These measurements thus allow for a precise estimation of the slant ionospheric delays, leading to cm- to dm-level positioning accuracies.

In the u-blox data set that I collected with a 20$ patch antenna, code observations were contaminated by meter-level multipath effects. It is easy to visualize, based on the GRAPHIC combination, that code multipath propagates directly into the position solution. When explicitly estimating slant ionospheric delays, the process noise can filter multipath effects and provide smoother position time series. However, in this data set, this strategy alone was not sufficient to avoid contamination of position estimates by code multipath. It is clear, in this case, that unmodeled time-correlated errors in the observations become a nuisance to the filter estimates.

On the other hand, the time variation of the slant ionospheric delays derived from a global ionospheric map (GIM) are smooth and can often offer a more representative estimate of the true ionosphere variation than multipath-contaminated code observations. One of the problems with using GIMs to define pseudo-observables in the PPP filter is that the STEC values computed are often biased due to several factors such as the mathematical representation of VTEC, the temporal resolution of the maps, the spatial interpolation required, etc. Unless there are ionospheric irregularities, the biases contained in the GIM values vary rather slowly and therefore contain time-correlated errors. As a consequence, adding constraints from GIMs at every epoch without accounting for time correlation will put too much weight on this observable and will most likely bias the solution.

From the discussion above, it should be apparent that unmodeled time-correlated errors are a limiting factor in our context. As explained in a previous blog post, there are several means of accounting for these errors in PPP, but the easiest method for me to implement was the state-augmentation approach, leading to the following functional model for the carrier-phase (L), code (C) and GIM (G) observables on frequency “i” to satellite “j”:

It is assumed here that the phase and code observables were corrected from error sources such as satellite clock errors and tropospheric effects. The parameters to be estimated are thus the receiver position (contained in rho), the receiver clock offset (dT), the slant ionospheric delays (I) and the carrier-phase ambiguities (N). To model time-correlated errors, two new types of parameters are now included in the filter: satellite-dependent code multipath (M) and GIM bias (B). Even though this is a serious case of over-parameterization (we have a lot more unknowns that observations), I will show hereafter that these parameters are helpful in absorbing errors in the measurements.

The tedious part of the state-augmentation approach is to provide meaningful a priori constraints and process noise for these new parameters. I could have a lengthy discussion on this topic but I will refrain from going into these details for the moment. After running the software dozens of times with different (realistic) values, I came up with the following solution:

**Fig 1 Kinematic SF-PPP solution with modeling of time-correlated errors**

Even though we did not expect a full convergence of the solution with one hour of data, at least the estimated displacement is greatly improved with respect to my previous attempt (knowing that the receiver was stationary). It is also interesting to have a look at the estimated multipath for satellite G13 with respect to the values obtained by simply differencing the code and the phase observations:

**Fig 2 Estimated multipath vs multipath computed from observations**

The previous plot suggests that the process noise on my multipath parameter, although quite permissive, was still too tight to capture the full peak-to-peak variations. However, increasing the process noise on multipath parameters basically means that code observations do not contribute to estimating the position anymore (they only serve in estimating the multipath). This is why tuning the initial constraints and process noise for time-correlation parameters is quite complex: they are data set dependent. I tried applying the same estimation strategy to a geodetic-quality station and, although the results were not terrible, they were not as good as without modeling time correlation, which can be quite easily explained.

In view of an automated online PPP service, these results are puzzling. Should we model time correlation and help low-cost users get rid of some code multipath while biasing geodetic-quality solutions? Or does it become necessary to put in place a pre-assessment of data quality to determine the level of code multipath prior to computing a PPP solution?

Write a comment

8#1Denis Laurichesse(Friday, 16 June 2017 13:49)Hello Simon,

did you try with the Doppler measurements? It should help a little bit.

Denis

#2Simon Banville(Friday, 16 June 2017 19:39)@Denis: I found that Doppler measurements are not helping much when continuous carrier-phase measurements are available.

One thing that I haven't tried is to model the rate of the slant ionospheric delays, for which Doppler measurements could contribute. But that means adding even more parameters!

#3Denis Laurichesse(Friday, 23 June 2017 09:26)Simon,

I would be interested to see the results in the position domain when you set the process noise on multipath parameters to its maximum value.

Denis

#4Simon Banville(Tuesday, 27 June 2017 13:18)@Denis: The positioning results when adding more process noise to multipath parameters are actually quite similar to the ones posted above: the time series are slightly smoother (especially in height) and the curves are offset by a few centimeters only.

In this case, the data set was collected at mid-latitude during the evening (local time), and the ionospheric corrections provided by the GIM seem to do a decent job at modeling both the absolute and time variation of the ionospheric delays. Hence, discarding code measurements (or using large process noise for the multipath parameters) actually helps the solution.

In cases where the GIM can't model the ionosphere properly, using this strategy is obviously not recommended. Again, it comes down to tuning: you need to have a basic knowledge of the precision of your observables.

#5Denis Laurichesse(Tuesday, 27 June 2017 14:29)Okay, maybe you should consider using the SBAS ionophere, which should be better than GIM.

Another question: the quality of the patch antenna seems good for the phase: do you correct phase measurements for cycle slips ?

Denis

#6Simon Banville(Tuesday, 27 June 2017 19:56)@Denis: Thanks for the SBAS suggestion. Not sure how good it is in Canada though...

The phase data was pretty clean, no need to correct for cycle slips.

#7Adam(Tuesday, 11 July 2017 17:12)I am assuming you are modelling both the Ionosphere and multipath with gauss markov processes?

Can you reliably model both at the same time? Wouldnt it be better to include one Gauss markov processes that encompasses both ionosphere and multipath?

#8Simon Banville(Tuesday, 11 July 2017 19:19)@Adam The slant ionospheric delay and multipath parameters are modelled as random walk processes in my software but Gauss-Markov processes would work just fine as well.

There are three types of measurements contributing to the ionospheric delay estimates (phase, code and GIM), while only code measurements contribute to the multipath estimates. The standard deviation of all parameters decreases over time, meaning that they are observable, although they could be correlated. However, from the multipath estimates shown above, it seems like it is absorbing the proper error source.

For these reasons, I believe that it is possible to estimate both parameter types at the same time and I don't really see any strong justification for trying to merge parameters.