Question

Hello! I whant to realize PPP technique whith C1 data only. I did next:

...
RequireObservables requireObs(TypeID::C1);
requireObs.addRequiredType(TypeID::L1);

BasicModel basic(nominalPos, SP3EphList);

ComputeLinear linear(comb.c1Prefit);

XYZ2NEU baseChange(nominalPos);

SolverPPP pppSolver(true);

while(...){
     try{
             gRin     >> requireObs
                          >> basic
                          >> linear
                          >> baseChange
                          >> pppSolver; 
     }
}
...

It works on RINEX files with full data(P1, P2, L1, L2, ...). But on my obserbation files with C1, L1 data only it doesn't works. Actually it works but error is about 40km %)

Give me advice where I should look for thin places please. Thank you.

-- AntonScherbakov - 08 Sep 2009

Answer

Hi,Scherbakov

I never do PPP with C1 and L1, but I can give you some hint:

1) Take into count you process C1 and L1, it include phase observation, you should do cycle slip detection and mark it and keep track of satellite arcs.

2) Make sure ComputeLinear^? calcute both c1 prefit and l1 prefit with C1 but not P1.

3) Check SolverPPP^?'s equation system is the right one.

Have a look at Example8 or Example9, you'll get it in more detail.

-- YanWei - 08 Sep 2009

Thank you for hints! For my regret example8 and example9 works with full data. I think that my problem in 'Process' method of 'SolverPPP' class, i.e. 'Process' use data that I haven't. So I will study it.

-- AntonScherbakov - 10 Sep 2009

Dear Anton,

Please take into account that PPP processing implies several important issues:

• Use of precise ephemeris (It seems you have this right).
• Use of the ionospheric-free combinations (PC, LC). You can't do this with one frequency.
• A very detailed observable modeling (antenna phase center, tidal effects, etc.).
• Use of decimation to match RINEX data rate with precise ephemerides data rate.
• A specific solver setup, impliying phase-based positioning with ambiguity estimation. As Yan pointed out, class "SolverPPP" is the right one, but it will need careful adjustments in your case.
• Cycle slip detectors. They are basic for phase-based positioning and it seems that you've skipped them.

Further details may be found in:

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

There exist some PPP-like strategies that use only one frequency for positioning, but be aware that their performance will not match the original PPP.

May suggestions are:

• Check class "OneFreqCSDetector" and insert it in your processing chain. Be careful to match its configuration with your data rate.
• Implement as much as you can from the original "example8.cpp" file. This includes decimation and precise modeling.
• Research about the GRAPHIC combination. This is a one-frequency only combination that is ionosphere-free.

Finally, try to contact Octavian Andrei. He worked for a while with us at gAGE implementing some PPP-like one-frequency strategies:

http://www.gpstk.org/bin/view/Main/OctavianAndrei

Good luck with your endeavor,

Dago

-- DagobertoSalazar - 11 Sep 2009

Thank you, Dago!

I included "OneFreqCSDetector" to my processing chain. To correct ionospheric delay I use maps IONEX. So I included to chain "IonexModel" too.

But actually it works not correctly. I think that the problem is in "Process" method of SolverPPP^?. I'll chek it.

-- AntonScherbakov - 15 Sep 2009

Dear Anton,

As Dago mentioned in his post, PPP is basically designed for dual-frequency data. In addition, I would also like to emphasize the importance of the precise satellite clocks. Their frequency rate is important in PPP. If you use precise satellite information in SP3-format (i.e., 15 min rate) then you should produce positioning results at this particular rate. Thus, Dago mentioned you to use decimation. In addition, please notice that nowadays IGS provides satellites clocks in RINEX format at a higher rate (i.e., 30 seconds). However, there is no GPSTk class to handle this.

When you try to use single frequency data (C1/P1 and L1) some other considerations should be assumed:

• P1-C1 differential code biases (Jefferson et. al., 2001). This allows you to reconstruct P1 observable. More at: http://nng.esoc.esa.de/gps_data/p1c1bias.hist.
• P1-P2 differential code biases (Schaer at. al., 1998). You can find them in IONEX files. See below.
• Ionosphere is one of the most critical source of errors. Thus, for example, you can mitigate the ionospheric effect by using IonexModel^? and IonexStore^? objects. Ionex files can be found: ftp://cddis.gsfc.nasa.gov/gps/products/ionex/yyyy/ddd/igsgddd0.yyi
• As carrier-phases are used, you need a cyle slip detector (OneFreqCSDetector^?). Tune it with 'proper' values according with your measurement frequency rate.

Other suggestions:

• You need an specific object to update the precise satellite clocks if it is the case.
• Be careful to have the latest 'PRN_GPS' file (ftp://sideshow.jpl.nasa.gov/pub/gipsy_products/gipsy_params)
• Get the ocean tide loading values for your particular location (http://www.oso.chalmers.se/~loading/).
• Decimate your data to be consistent with your precise satellite clocks (e.g. 15-min). Please be aware that Decimate object might not work as expected when some epochs are missing.
• Filter out bad P1 observables using a SimpleFilter^? object. Do the proper object settings.
• Compute prefit-residuals (p1Prefit and l1Prefit) using ComputeLinear^? object.
• Pay attention to multipath when ionospheric-free code and phase combination (i.e., GRAPHIC combination) is considered According to Hofmann-Wellenhof et. al, 2008 (and my recent findings) in cases of low impact of multipath single-frequency ionosphere-free PPP solutions can be equivalent to the dual-frequency solutions.

In the end, I would like to stress that the order in which every object is called is important. Read the documentation for each individual object that you would like to use it. It is very helpful! Dagoberto did a wonderful work.

References:

1. Jefferson, D., M.B. Heflin, and R.J. Muellerschoen, (2001). Examining the C1-P1 Pseudorange Bias. GPS Solutions, 4(4), 25-30.
2. Schaer, S., W. Guntner and J. Feltens (1998). IONEX: The IONosphere Map Exchange Format Version 1, Proceedings of the IGS AC Workshop, Darmstadt, Germany, February 9-11, 1998, ESA/ESOC, 233-237.
3. Hofmann-Wellenhof, B., H. Lichtenegger, E. Wasle (2008): GNSS - Global Navigation Satellite Systems, Springer-Verlag Wien, 516 pages.

-- OctavianAndrei - 23 Sep 2009

Change status to: AskedQuestions AnsweredQuestions ClosedUnanswered