Precise 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](https://docs.rs/rinex/latest/rinex/struct.Rinex.html) and [RTK-rs position solver](https://docs.rs/gnss-rtk/latest/gnss_rtk/) 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. Use cases and Requirements ========================== 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. Reference coordinates and surveying =================================== 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](./Logs) and [QC](./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-geo` to describe geodetic coordinates - `--rx-ecef` to describe ECEF WGS84 coordinates Summary: 1. Unknown _apriori_ position: absolute solutions are resolved and projected but we have nothing to compare the results to 2. Defined _apriori_ position (either manually or automatically picked up in RINEX): the solutions are compared to that "reference" point. Default settings ================ 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. Config preset ============= Refer to the RINEX tutorials database (RINEX repo) for custom configuration examples. Several navigation filters are supported, we have examples for all of them. Timescales ========== We have the ability to express the final solutions in any [supported TimeScale](https://docs.rs/hifitime/latest/hifitime/enum.TimeScale.html). 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. Constellations ============== Refer to the list of constellation supported on the front page. Mixing constellation is supported, some examples may exist. CGGTTS ====== 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](./CGGTTS) special documentation. Input products versus Final Solution ==================================== 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. Output products =============== When running the `ppp` opmode, one custom chapter is appended to the report. It describes the generate context and presents the navigation solutions. Applications logs ================= 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. Getting started =============== - [Standard Point Positioning strategy (SPP)](./SPP) - including several examples. This strategy allows metric solutions (1m error), in best scenarios - [Code based Precise Point Positioning (CPP)](./CPP) - including several examples. This strategy reaches metric solutions (1m error) more easily, but requires a secondary signal (like L2 or L5)