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. Our goal is to propose a powerful solver with up to so called "PPP" capabilities.
PPP has the benefit of being simple to deploy, as it requires only a single receiver
and does not require to connect to a secondary reference (like DGNSS, SBAS or RTK station).
On the other hand, the algorithm is very complex to implement, especially to achieve the ultimate accuracy.
Depending on the targetted accuracy of the solutions (metric, decimetric, centimetric..), the requirements on your input data will vary (as we will explain and demonstrate later). This disables the ability to resolve utterly precise solutions in real time, with PPP approach, as it requires post processed products that laboratories publish about 2 or 3 weeks afterwards.
It is not quite accurate to say PPP is not real time, in the end it all depends on the targetted accuracy.
Therefore we distinguish two use cases of a PPP solver
- Users who want to determine a location with reasonnable accuracy, in real time. It may apply to rovers (roaming use case), especially since PPP does not require a direct link to subsidary reference.
- Users who want to determine a static location with very good accuracy but not in real time (post processing), without access to a secondary reference. This typically applies to Stations that will serve as Reference themselves afterwards, therefore cannot access a reference themselves. This type of usecase is called Geodetic 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
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)
- Precise Point Positioning (PPP) - including several examples. This strategy reaches below metric solutions but is demanding on the input data
