positioning
Precise positioning is one of the most important opmodes of RINEX-Cli, and it is activated with -p.
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 notably:
- SBAS vehicles are not handled properly yet, so cannot be used in
-popmode - RTK (differential positioning) is not supported yet. We resolve the position of a single receiver by itself
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.
To summarize, our PVT solver (-p opmode) currently applies to two use cases:
- 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). You may hope for errors of about 1m in your final solution.
- Geodetic Surveys: users who want to determine a static location with very good accuracy but not in real time (2 to 3 weeks after sampling). In the meantime (until SP3 and CLK RINEX files become available), you can only rely on temporary solutions. Stations that want to serve as RTK reference stations need to perform a geodetic surveys themselves first, to determine their precise location they will later serve to the network.
According to the positioning strategy, the required input data vary.
Users must comply with the requirements to achieve the best results.
The application will help identify what could be improved, and will let you know if somethings wrong, through the
generated logs.
What remains constant is that
-
At least one Observation RINEX file is required. This file provides signal observations and is currently how we provide this information to RINEX-Cli. Because it is impossible to connect a real-time receiver to RINEX-Cli (yet).
-
At least one Navigation RINEX file is required, for the day of the observation sampling. This file provides the information about the constellation and the vehicles that were observed during that day.
As long as these two points are respected, the program will deploy. RINEX-Cli totally complies with exotic use cases:
-
Partial and truncated RINEX files (for example, 2h of observations). This will limit the quantity of Epoch we can integrate. The more averaging, the better the final solutions. It might also limit the interpolation order you can use when working with SP3/CLK RINEX.
-
Work with more than a single RINEX (for example, accumulate 2 or 3 days of observations). Although this has not been tested yet, we're planning on putting up an example where we take advantage of that to improve the final solution even further.
Generating a few graphs or running the Quality Control might help become familiar with the dataset.
RINEX-Cli is capable of performing geodetic surveys where no position is known ahead of time.
The end goal is to determine where the antenna is located with ultimate accuracy.
It is possible to deploy without knowledge of the final position, ahead of time (so called, a priori position).
RINEX files usually come with the definition of the apriori position in their header.
If one of your files has such information, we let you know and we automatically project it onto the map.
We will also compare the final solution to this apriori position.
We have the option to manually define a position by the command line. Use --rx-geo to pass geodetic
coordinates, or --rx-ecef to pass ECEF WGS84 coordinates. When using manual definition, note that it will
superceed the possible RINEX header position.
Summary:
- Unknown apriori position: absolute solutions are resolved and projected but we have nothing to compare to
- Defined apriori position (either manually or automatically picked up in RINEX): the solutions are compared to that "reference" point.
Check the applications log to determine whether a position preset is contained inside your RINEX data.
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).
This repo comes with several configuration preset, stored in rinex-cli/config/rtk.
PPP is a complex topic which involves many aspects to reach the best performance.
This typically winds up in huge configuration setups that are complex to understand.
Our ecosystem is smart enough to rely on default preset for any omitted field.
This has the benefit of being able to perform complex tasks with simple configurations.
For example, compare our preset database to a typical RTKLib configuration file, to understand what we mean by this.
Use the applications logs to
- make sure the solver did deploy on the intended setup
- understand what other parameters can be modified
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.
We can currently operate with GPS, Galileo, BeiDou and QZSS (hypothetically, not tested yet).
Note that only GPS and Galileo are truly compatible with centimetric positioning, in the sense the post processed high quality products are available for them.
When working with BeiDou and QZSS, you are limited to deploy the toolbox without SP3 and CLK RINEX (navigation is solely based on radio messages).
Use the preprocessor to select the vehicles and constellation you want to work with.
We can operate on crossed mixed constellations (for example Gal+BDS), but the restrictions on the input data still apply.
Any PVT Solution Type are supported in the configuration script.
By default we need 4 SV in sight, but providing a fixed altitude (say you know it ahead of time) reduces that number to 3.
Switching to CGGTTS opmode implies withing to TimeOnly solutions, we do that switch for you
(see the applications log) in case you forgot to modify the type of solutions you want to resolve
while working in CGGTTS mode.
Most (soon, all) physical and environmental effects can be modeled and accounted for in our settings.
Learn how one impacts the final solutions by desabling or enabling it.
As previously stated, we prefer final accuracy over computation time, therefore the proposed presets will emphasize that.
The solver will let you know if the modeling of one effect is not meaningful based on the current settings or input dataset (as a warning in the logs).
The navigation filter (and other solver options) can be fully customized in the configuration script.
This means you can push strategies like SPP to their limit by using a huge interpolation order
or a Kalman filter (which is typically implied by PPP, not SPP). This framework gives you that flexibility,
since all of these things are interdependent
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.
The position solver generates a dedicated HTML page where
- the PVT solutions are projected on a world map
- the position and velocity vectors are plotted, for accurate performance monitoring
- they are also projected in 3D, which gives a rough visualization of how the solutions are centered around the actual position
- the receiver clock offset is presented along TDOP in a dedicated plot
- Dilution of precision is also presented in separate plots
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.
- Single 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)
