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 currently only applies to 1D (single) GNSS receiver use case: we do not support DGNSS, SBAS and RTK (yet). Our goal is to propose a powerful solver with a correct implementation of the so called "PPP" algorithm.
PPP has the benefit of being simple to deploy, in the sense it does not require two receivers nor
a connection to a secondary reference station (like RTK).
On the other hand, the algorithm is very complex to implement (difficult on our side), and you cannot achieve
the best results in real time. That means you cannot perform centimetric geodetic surveys in the very moment.
You have to wait for high quality files to be produced by IGS, for the time you sampled the signal, which takes 2 to 3 weeks.
It is incorrect to say PPP is not real time, it just depends on the error you tolerate on the final solution.
Our PVT solver (-p option) 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). 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 are produced), you can only rely on degraded final solutions. This is typically required by reference stations that cannot access reference stations themselves, and will eventually serve as reference after the survey.
According to the positioning strategy, the requirements on the dataset will vary.
Users must comply with the requirements we will describe in the following pages for the algorithm to deploy
properly (some cases may cause panic) or to achieve the end results (some cases will generate a log warning).
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.
-
At least one Navigation RINEX file is required, for the day of the previous observations. This file provides the information about the constellation and the vehicles that were sampled during the observations.
As long as these two points are respected, the program will deploy.
RINEX-Cli totally complies with exotic use cases like
- Partial RINEX files, like 2h of observations. But you need to understand that may require to reduce the interpolation order
- Work with more than a single RINEX (ie., accumulate more than 24h of observations). But that has never been really tested yet (more examples to come soon).
Graph mode or Quality Check mode will help in understanding your dataset and if they fit the PPP requirements.
Currently, RINEX-Cli requires the definition of a reference position that we consider
the ideal results of the position solver and we use it to compare how we perform.
Technically, that would be the end results of a previous Geodetic survey.
Very soon, we will have the ability to get rid of that, to comply with the need of real
PPP solving, starting from scratch with no position known ahead of time.
To define it, you have two options:
- Most of the time it is defined in Observation RINEX. We have the capacity to pick it up automatically and we let you know in the applications log.
- You can manually define a reference position with
--rx-geo(for geodetic coordinates), or--rx-ecef(for ECEF WGS84 coordinates). When coordinates are defined manually, they always superceed the possible previous position.
To determine whether a reference position is described in your context or not, you
can run a couple of our analysis and read the logs, or attempt positioning with -p,
if it's missing in your current context, it will cause a panic (temporary behavior).
This framework prefers accuracy over processing load. Although in the end (most likely thanks to Rust), it performs very well and it turns out the most demanding options do not increase the processing time dramatically.
Use the preset we propose in this toolbox to get started and tweak them to learn about physical aspects.
The presets are located in rinex-cli/config/rtkand are formatted in JSON.
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.
But the RUST JSON ecosystem is powerful enough to allow us to operate on very simplistic configuration scripts.
For example, compare our preset database to a typical RTKLib configuration file, to understand what we mean by this.
You just need to remember that any field of the Configuration structure
that you ommit in the JSON script, will rely on its default value.
To understand what the default values are, and what is truly happening inside the solver, simply read the applications log.
Unfortunately comments are not allowed in JSON, therefore these pages are our only interface to truly document them.
This framework allows expressing 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.
The current version allows precise positioning with GPS and Galileo constellations.
We are actively working on unlocking BeiDou and QZSS.
Note that only GPS and Galileo are truly compatible with centimetric positioning,
because high end post processed input files (SP3, CLK) only exist for such constellations.
Use the -P options to focus on desired Constellations (see the preprocessing toolbox).
The framework allows positioning on mixed contexts, for example GPS + Gal.
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)
