positioning
Precise positioning is one of the most important opmodes of RINEX-Cli, and it is activated with ppp.
The objective is to resolve precise Position, Velocity and Time (PVT) solutions of a single receiver.
RINEX-Cli combines the RINEX core library and RTK-rs position solver to create an efficient interface to do so.
RINEX-Cli can perform precise geodetic surveys and resolve the position of a single receiver. This is called Precise Point Positioning (PPP). Most important points being:
- RINEX-Cli can only manage a single receiver and is currently incapable to process ground-ground differential positioning, like RTK
- this tool is oriented towards Post Processing. We can resolve with either Post processed products like SP3, or solely based on Broadcast navigation (BRDC), but we currently do not have an interface that would permit a real time stream of data (wether it be a Broadcast Navigation frame, or specific hardware).
- SBAS augmentation can be activated, if SBAS vehicles are sighted and selected, but only in BRDC Navigation. It is not clear whether SBAS would be meaningful in fully post processed context, if you are knowledgeable, just let us know!
- As long as the combination of both a hardware interface and network interface is not available, RTK (ultimate differential positioning) is not available.
PPP has the benefit of being simple to deploy, in the sense it does not require to connect to a reference station like RTK. On the other hand, the algorithm is very complex to implement and you cannot achieve the best results in real time. That means you cannot perform centimetric geodetic surveys in the very moment you sample the signals. You have to wait for the post production of high quality files for that day. Agencies like NASA or IGS produce these files 2 to 3 weeks after a given day. It is incorrect to say PPP is not real time, it just depends on the error you tolerate on the final solution.
The PVT solver (ppp opmode) applies to the following cases:
- BRDC: Users in posession of a single receiver who want to determine their location with reasonnable accuracy, without access to a reference station
and in real time. It may apply to rovers (roaming use case, dynamic applications), but it has never been tested yet (soon to come).
You may hope for errors of about 1m in your final solution. It is sometimes possible to achieve better with this tool, it mostly depends on the Constellation and the signals you select.
The input are one Observation RINEX and one Navigation RINEX. - Geodetic Surveys: users who want to determine the location of a future reference point (to servce in future differential positioning),
with highest precision, but not in real time. Therefore, the surveyed position is a static position.
The input are one Observation, one Navigation and one Clock RINEX, and one SP3 file.
Ideally the Observation and Clock RINEX should be expressed in the same timescale.
Whether your context describes a location (usually in Observation RINEX) or not, we can deploy and survey, because we have the capacity to survey without a priori knowledge.
If a location is described in the context, the logs and QC reports will let you know, and it serves as a point of comparison in the PPP report (solely).
If your dataset does not describe a location, but you want to use coordinates for comparison, you can manually specify them with either
-
--rx-geoto describe geodetic coordinates -
--rx-ecefto describe ECEF WGS84 coordinates
Summary:
- Unknown apriori position: absolute solutions are resolved and projected but we have nothing to compare the results to
- Defined apriori position (either manually or automatically picked up in RINEX): the solutions are compared to that "reference" point.
This framework prefers accuracy over processing load.
Therefore you might get notifications of possible improvements if you deploy without SP3 or CLK RINEX
(so called radio navigation). It does not mean that this is bad, it simply means better performances
could be achieved.
Refer to the RINEX tutorials database (RINEX repo) for custom configuration examples.
Several navigation filters are supported, we have examples for all of them.
We have the ability to express the final solutions in any supported TimeScale.
This is what the time_scale field of the Configuration script (-c) does.
It is particularly useful if you are interested in expressing the results in UTC for example.
Refer to the list of constellation supported on the front page.
Mixing constellation is supported, some examples may exist.
Switch to CGGTTS opmode is done by adding --cggtts to ppp opmode.
It implies switching to TimeOnly solutions. The calculations are not heavier but much more time consuming,
because we now resolve for each vehicle. Refer to the CGGTTS special documentation.
Input Data versus surveying startegy and error in the final solution:
| Input | Strategy | Final solution | Notes |
|---|---|---|---|
| RINEX2 | SPP | Hardly < 1m | Only GPS or Glonass. Avoid, Ionosphere needs to be modeled accurately. Expect discontinuities at midnight. Stack IONEX file(s) for better modeling and improvements in the solution. Stack Meteo observations for accurate Troposphere Model. Insert Troposphere Model in the filter, when filter type is set to Kalman, to improve the solution. |
| RINEX3 | SPP | Hardly < 1m | GPS, Glonass, BeiDou, Galileo. Better but expect discontinuities at midnight. Same remarks |
| RINEX4 | SPP | Hardly < 1m | Better, discontinuities at midnight should disappear. Same remarks. |
| Any | CPP | Target 1 m | Ionosphere model is disregarded. Use Kalman + Troposphere. Stack SP3 and CLK for high end solutions. |
| Any | PPP | Target < 1m | Ionosphere model is disregarded. Kalman + Troposphere usually intended. Stacked SP3 and CLK intended. CLK and OBS RINEX in same timescale for high end solutions |
This toolbox allows loading SP3 and CLK RINEX whatever the other options might be.
This has the benefit to allow advanced navigation options for usecase where these files are not available (BeiDou for example, or real time navigation).
Stacking SP3 and CLK RINEX will always improve the final solutions.
This toolbox is smart enough to operate with SP3 and without CLK RINEX, especially if your SP3 file comes with clock models.
This scenario is better than the basic scenario, and not ideal compare to the complete PPP scenario.
When running the ppp opmode, one custom chapter is appended to the report.
It describes the generate context and presents the navigation solutions.
Use the Rust logger (see other introduction pages) to have an accurate report of the session.
Pay attention to the initial phase where we analyze the input dataset and verify it complies to the
configuration. The solver will always let you know if something is limiting or could be improved.
It will also let you know if a configuration is not realistic, with respect to the input data.
- Standard Point Positioning strategy (SPP) - including several examples. This strategy allows metric solutions (1m error), in best scenarios
- Code based Precise Point Positioning (CPP) - including several examples. This strategy reaches metric solutions (1m error) more easily, but requires a secondary signal (like L2 or L5)
