-
Notifications
You must be signed in to change notification settings - Fork 25
spp
SPP is the "simplest" resolution method, is it Pseudo Range (PR) code based, it will not consider carrier phase and will only consider a single carrier signal. SPP also relaxes the requirement on the provided data compared to PPP.
While all of this applies, it still does not mean you cannot achieve decent result with SPP, it all depends on the final accuracy you want to achieve and what decent means:
- SPP will hardly output PVT solutions below 1 meter of accuracy (so about 5 to 10ns timing accuracy).
-
RINEX-Cli
andRTK-rs
are powerful enough to be able cross this barrier under specific conditions, by providing lots of data (say 48 hours) and tolerate long averaging. Usually this is not the typical use case of SPP. Yet it is interesting to be able to do so, for example if we consider a degraded context where we can only sample a single carrier. PPP will basically reach the SPP performance much much faster, at the expanse of more computation load.
Like any position solving strategies, SPP can be converted to CGGTTS, for remote clock comparison.
In this case, the CGGTTS resolution will be limited by the SPP limitations itself.
Our CGGTTS ecosystem is smart enough to be able to resolve on code based only contexts, so it is totally doable to run
such an analysis in degraded/limited conditions.
- Code based calculations, no phase to be considered
- LSQ filter, no Kalman filter. Computations are less expensive, SPP generates results much faster.
- SPP has a slower converging time compare to PPP. You need around 4 to 6 hours of SPP averaging to reach what you can do in a couple minutes of high standard PPP.
- Atmospheric biases are modeled, not measured and cancelled. Models are imperfect and may only apply under certain conditions. This is the main source of limitation to the SPP method. SPP will ultimately converge to a static value that is the bottom line limitation and providing more data will not help.
- Single carrier calculations. Providing more carrier signals like L2 or L5 will only enable more resolution possibilities, it will not improve the overall performance.
- Precise products like SP3 and Clock RINEX are originally not intended to be loaded. RINEX-Cli allows loading such data to achieve metric resolution.
SPP requires you to load code based pseudo range for at least one carrier signal, and provide orbital context for at least 4 SV by default, at the same window time frame.
Providing more source of orbital information (several NAV files) helps make sure an physical measurement will not get dropped out due to missing SV in sight.
Providing more signal observations, altough we will only use a single carrier, helps make sure the solver can elect the best code observation to resolve.
TODO
By providing good quality data and PPP compliant format, it is possible to obtain very good results, while still using a code based resolution method.
rinex-cli \
-f test_resources/CRNX/V3/ESBC00DNK_R_20201770000_01D_30S_MO.crx.gz \
-f test_resources/NAV/V3/ESBC00DNK_R_20201770000_01D_MN.rnx.gz \
-f test_resources/SP3/GRG0MGXFIN_20201770000_01D_15M_ORB.SP3.gz \
-f test_resources/SP3/GRG0MGXFIN_20201760000_01D_15M_ORB.SP3.gz \
-p --spp

- Wiki
- RINEX Data
- Getting Started
- Filter Designer (Preprocessor)
- QC/Analysis mode
- File operations
- Post Processed Positioning (ppp)