cpp
Like SPP, we only consider Pseudo Range (PR) observations, but we now consider those on two separate frequencies (L2 or L5). We still do not consider Phase Range (PH) observations, unlike PPP.
CPP is a little harder than SPP to comply with, because you will have to sample two carrier signals.
The combination allows accurate Ionosphere delay compensation. This means that the iono_delay field
of the Modeling section of the config script is irrelevant in CPP (like in PPP). It also means that
the Ionosphere Delay exposed in the CGGTTS solution is now measued, not modeled.
- Requires secondary carrier signal: harder to comply with
- Will not generate a single solution if your observations come from a single signal
- Ionosphere is not modeled, this option becomes irrelevant and processing is actually faster (no modelling)
- Reach high end SPP results much more easily
Note that this framework supports any RINEX code, and so, allows working with any signal in theory.
- Similar Ionosphere bias cancellation
- No phase observation required: less signal observations required, easier to comply with
- Troposphere can only be modeled. Soon we will have the ability to inject it in a Kalman filter, but that is not the case as of today
- Hard to cross the metric barrier
You can use the tutorials/ dataset to explore CPP resolution technique.
For example, tutorials/GAL/mojndnk.sh will perform a static survey.
By selecting an CPP compatible configuration, you can use this navigation technique in the process.
You can use CPP navigation technique when solving CGGTTS solutions.
Refer to the tutorials/ database once again, tweak one of the CGGTTS solutions,
for example tutorials/GAL/mojndnk.sh, to its resolution process uses CPP specifically.
