I have several questions about PPP, and I need you help.

1. In the PPP example 8(or example 9) you provided , we try to estimate the wet part of zenith path troposphere delay, this is ok and the example do it exactly. But when compute prefit residual of PC and LC, you correct slant path troposphere delay,which include both wet part and dry part. Then what will happen ? the wet part of troposphere you corrent additionally will take a error into the prefit residual of PC and LC, and it may be absorbed by the receiver clock or the phase ambiguity, it's not fatal but will lead to some error to the station position.

OK, let's have a look at the function "void example9::printSolution()", you output of zenith troposphere is (wetTropo+0.1+dryTropo), taking the above analysis into account, the output should be the former wet part and dry part add the estimated wet part.

           // Definition to compute prefit residual of PC
      pcPrefit.header                     = TypeID::prefitC;
      pcPrefit.body[TypeID::PC]           = +1.0;
      pcPrefit.body[TypeID::rho]          = -1.0;
      pcPrefit.body[TypeID::dtSat]        = +1.0;
      pcPrefit.body[TypeID::rel]          = -1.0;
      pcPrefit.body[TypeID::gravDelay]    = -1.0;
      pcPrefit.body[TypeID::satPCenter]   = -1.0;
      pcPrefit.body[TypeID::tropoSlant]   = -1.0;      // pay attention to this line

2. A Rand Walk Stochastic Model is used to estimate troposphere , my second question is about "Process spectral density : d(variance)/d(time) or d(sigma*sigma)/d(time)". In you example, you set it to "3.0e-8", how can I choose the value? In the following paper, I found : A rand walk process noise of 5mm/sqrt(h) is assigned to the zenith path delay. 3.0e-8 equal to 10mm/sqrt(h)? is my understand ok?

"Kouba, J. and P. Heroux. "Precise Point Positioning using IGS Orbit and Clock Products". GPS Solutions, vol 5, pp 2-28. October, 2001."

Thanks for your excellent work of GPSTk and the great help to me!



-- YanWei - 09 Sep 2009


ALERT! If you answer a question - or have a question you asked answered by someone - please remember to edit the page and set the status to answered. The status is in a drop-down list below the edit box.

Hi Yan!

When computing the prefit residual for ionosphere-free combinations PC and LC, the slant path tropospheric delay being used is composed of two parts:

1) The slant path DRY tropospheric delay (dry_mapping*zenital_dry_delay).

2) The NOMINAL slant path WET tropospheric delay (wet_mapping*nominal_zenital_wet_delay).

The important part is that the wet delay, for prefit computations purposes, is a nominal value. This is done in this way because it is extremely difficult to do a good estimation of this parameter. Indeed, most tropospheric models have important failures here.

If we accept this limitation, the strategy is to set a nominal wet delay value and to handle the resulting mismodeling as an additional unknown (this is similar to what we usually do with receiver clock). In the case of the Neill-based tropospheric model, we set a fixed zenital wet tropospheric delay of 10 cm.

Then, the value stored in "TypeID::tropoSlant" is the sum of items 1) and 2) above. That operation is done by the processing class "ComputeTropModel".

In summary, the missing (residual) zenital tropospheric wet part will get into the prefit residuals (as you correctly pointed at), but it WILL NOT be absorbed by either the clock, the ambiguities or the position because it will be estimated separately (as a new unknown).

Bear in mind that this additional unknown is OBSERVABLE: Although it is the same residual zenital tropospheric wet delay for all the satellites, its slant part is different because of the effect of the wet mapping function. Therefore, as geometry changes, it is possible to separate it from receiver clock, ambiguities and position.

Later, when the solver is done, the full zenital tropospheric delay will be reconstructed from the addition of the model-estimated zenital dry delay, the nominal zenital wet delay (10 cm), and the solver-estimated residual zenital wet delay (dryTropo+0.1+wetTropo).

Regarding the "Process spectral density" issue, this parameter represents your "informed guess" about how quickly the wet troposphere is going to change.

A low value (let's say, below 5 mm/sqrt(h)) means that you are pretty sure that the water vapor content of the troposphere is going to change very slowly (in the place you have your receiver). A bigger value means you are open to more sudden changes.

it is a matter of choice and of the specific application at hand. If you are too tough with the model (i.e., you set a very low process spectral density value), and the troposphere changes fast, you will introduce a notable mismodelling and the residual WILL INDEED affect the positioning. If on the other hand this value is set high, it will be harder for the filter to separate the tropospheric effect from the other unknowns, and solution convergence will be slower.

We at gAGE usually try to be on the safe side, so we often use 10 mm/sqrt(h) for fixed stations at mid-latitudes.

Finally, you should use values one or two order of magnitude higher if you are trying to apply PPP-like techniques for fast-moving vehicles.

Thanks very much for your comments. It is nice to read that our work is being useful for others.

Best regards,


-- DagobertoSalazar - 11 Sep 2009


Thank you for explaination so munch in detail. I misunderstood the nominal zential wet delay(10cm), and I should have read your comment and check NeillTropModel carefully, sorry!

Recently, I'm trying a new PPP strategy:

First, I process all the obs epoches with a standard kalman filter(SolverPPPFB::Process()), and store the solution of ambiguities to the struct with TypeID::BLC;

Second,I smooth the epoches with SolverPPPFB::ReProcess();

Third, I try to fix the ambiguities and process phase data only with LastProcess();

I expect this strategy is effective and can get better position results, but it failed. Maybe there are something problem with my codes, or this processing idear is totally wrong. Wish you can tell me something.

Thank you!



-- YanWei - 13 Sep 2009

Hi again, Yan!

When you tell me that you try to fix the ambiguities, I wonder if you are trying to fix the "TypeID::BLC" ambiguities (which are related to the ionospheric-free phase combination, LC).

It turns out that the ambiguities of the ionosphere-free phase combination are NOT integers, and therefore they are not fixable, at least in the standard meaning of the "fixing" term.

There is, however, a "PPP-fixing" procedure being used lately. It involves separate estimation of satellites' instrumental delays and single inter-satellite differences.

Please check the following references:

  • J. Geng, F. N. Teferle, C. Shi, X. Meng, A. H. Dodson and J. Liu. "Ambiguity resolution in precise point positioning with hourly data". GPS Solutions. 2009.
  • D. Laurichesse, F. Mercier, J.P. Berthias, P. Broca and L. Cerri. "Integer Ambiguity Resolution on Undifferenced GPS Phase Measurements and Its Application to PPP and Satellite Precise Orbit Determination". Navigation: Journal of the Institute of Navigation. 2009.



-- DagobertoSalazar - 13 Sep 2009


Thank you answer in time. Yes, the ambiguities of the ionosphere-free phase combination are not integers, and I mean fixed it to the float value from the previous PPP Process. I'll keep trying, if any good result is obtained, I'll write to you.

It's good to hear of you 'll do a "PPP-fixing" procedure lately, that's I want to see.

I'll pick up the references and check it carefully. You are really my mentor, and it's nice to talk to you.



-- YanWei - 13 Sep 2009

Hi, Dago

I failed to find this reference, woud you send me a copy?

* D. Laurichesse, F. Mercier, J.P. Berthias, P. Broca and L. Cerri. "Integer Ambiguity Resolution on Undifferenced GPS Phase Measurements and Its Application to PPP and Satellite Precise Orbit Determination". Navigation: Journal of the Institute of Navigation. 2009.

My email address is XXXXX

And, I found this paper explain it in much detail:

* Ge M, Gendt G, Rothacher M, Shi C, Liu J (2007) Resolution of GPS carrier-phase ambiguities in precise point positioning (PPP) with daily observations. J Geod 82(7):389–399. doi:10.1007/s00190-007-0187-4

Resolution of GPS carrier-phase ambiguities in PPP is not a easy task, we have a long way to go!

Thank you!

Best Regards,


-- YanWei - 14 Sep 2009 No such template def TMPL:DEF{PROMPT:supportquery}

Topic revision: r9 - 14 Sep 2009, DagobertoSalazar

This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback