{"id":28387474,"url":"https://github.com/rtk-rs/gnss-rtk","last_synced_at":"2025-06-26T20:31:42.675Z","repository":{"id":204428681,"uuid":"711832369","full_name":"rtk-rs/gnss-rtk","owner":"rtk-rs","description":"Precise Point Positioning (PPP) and Real Time Kinematics (RTK)","archived":false,"fork":false,"pushed_at":"2025-06-22T12:41:50.000Z","size":2572,"stargazers_count":54,"open_issues_count":2,"forks_count":10,"subscribers_count":5,"default_branch":"main","last_synced_at":"2025-06-22T13:19:43.671Z","etag":null,"topics":["galileo","geodesy","gnss","gps","rtk"],"latest_commit_sha":null,"homepage":"","language":"Rust","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mpl-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/rtk-rs.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2023-10-30T09:09:10.000Z","updated_at":"2025-06-22T09:41:36.000Z","dependencies_parsed_at":"2023-12-16T15:24:35.119Z","dependency_job_id":"acc958ee-a8e5-4539-bef8-47159f8ad5a0","html_url":"https://github.com/rtk-rs/gnss-rtk","commit_stats":null,"previous_names":["rtk-rs/gnss-rtk"],"tags_count":14,"template":false,"template_full_name":null,"purl":"pkg:github/rtk-rs/gnss-rtk","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rtk-rs%2Fgnss-rtk","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rtk-rs%2Fgnss-rtk/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rtk-rs%2Fgnss-rtk/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rtk-rs%2Fgnss-rtk/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/rtk-rs","download_url":"https://codeload.github.com/rtk-rs/gnss-rtk/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/rtk-rs%2Fgnss-rtk/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":261298137,"owners_count":23137398,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["galileo","geodesy","gnss","gps","rtk"],"created_at":"2025-05-30T17:41:52.190Z","updated_at":"2025-06-26T20:31:42.610Z","avatar_url":"https://github.com/rtk-rs.png","language":"Rust","funding_links":[],"categories":["Uncategorized"],"sub_categories":["Uncategorized"],"readme":"GNSS-RTK\n========\n\n[![Rust](https://github.com/rtk-rs/gnss-rtk/actions/workflows/rust.yml/badge.svg)](https://github.com/rtk-rs/gnss-rtk/actions/workflows/rust.yml)\n[![Rust](https://github.com/rtk-rs/gnss-rtk/actions/workflows/daily.yml/badge.svg)](https://github.com/rtk-rs/gnss-rtk/actions/workflows/daily.yml)\n[![crates.io](https://img.shields.io/crates/v/gnss-rtk.svg)](https://crates.io/crates/gnss-rtk)\n[![crates.io](https://docs.rs/gnss-rtk/badge.svg)](https://docs.rs/gnss-rtk)\n\n[![MRSV](https://img.shields.io/badge/MSRV-1.82.0-orange?style=for-the-badge)](https://github.com/rust-lang/rust/releases/tag/1.82.0)\n[![License](https://img.shields.io/badge/license-MPL_2.0-orange?style=for-the-badge\u0026logo=mozilla)](https://github.com/rtk-rs/gnss-rtk/blob/main/LICENSE)\n\nThe `GNSS-RTK` library provides Position Velocity Time (PVT) solution solvers,\nwith abstract and flexible interfaces, so it may apply to most navigation scenarios,\nwhether your application is real-time or post-processing does not matter.\n\n\u003cdiv align=\"center\"\u003e\n    \u003cp\u003e\n        \u003cbr\u003ePPP solver\u003c/br\u003e in static application, surveying a professional geodetic marker\n    \u003c/p\u003e\n    \u003ca href=https://github.com/rtk-rs/rinex-cli/blob/main/plots/front-page/map.png\u003e\n        \u003cimg src=https://github.com/rtk-rs/rinex-cli/blob/main/plots/front-page/map.png alt=\"Plot\"\u003e\n    \u003c/a\u003e\n\u003c/div\u003e\n\n\u003cdiv align=\"center\"\u003e\n    \u003cp\u003e\n        Errors from the geodetic marker (CPP, Galileo E1+E5)\n    \u003c/p\u003e\n    \u003ca href=https://github.com/rtk-rs/rinex-cli/blob/main/plots/front-page/coordinates.png\u003e\n        \u003cimg src=https://github.com/rtk-rs/rinex-cli/blob/main/plots/front-page/coordinates.png alt=\"Plot\"\u003e\n    \u003c/a\u003e\n\u003c/div\u003e\n\n\u003cdiv align=\"center\"\u003e\n    \u003cp\u003e\n        Roaming session (pedestrian profile), post-processed with \u003cbr\u003ePPP solver\u003c/br\u003e (no ground reference), \n        CPP, GPS L1/L5 + Galileo L1/L5\n    \u003c/p\u003e\n    \u003ca href=https://github.com/rtk-rs/rinex-cli/blob/main/plots/front-page/roaming-ppp1.png\u003e\n        \u003cimg src=https://github.com/rtk-rs/rinex-cli/blob/main/plots/front-page/roaming-ppp1.png alt=\"Plot\"\u003e\n    \u003c/a\u003e\n\u003c/div\u003e\n\nLicensing\n=========\n\nThis library is part of the [RTK-rs framework](https://github.com/rtk-rs) which\nis delivered under the [Mozilla V2 Public](https://www.mozilla.org/en-US/MPL/2.0) license.\n\nP.V.T Solutions\n===============\n\nThe objective of each solver is to resolve the state of the target device: the GNSS receiver,\nin space time, with high accuracy. The solutions are called P. V. T. for Position Velocity Time\nsolution, that emphasizes the space \u0026 time coordinates. \n\nWhether the receiver is moving or not is application dependent. You should select the solver\nthat suites your application best.\n\nGNSS-RTK is limited to ground based (=low altitude, within atmosphere) navigation on planet Earth. \nAlthough it would be possible to make GNSS-RTK more abstract and compatible with other Planets, it\nis not planned to this day. You can reach out to us and join forces, if you want to see this happen !\n\nPVT Solvers\n===========\n\nThis library proposes the `PPP` solver and the `RTK` solver, which you can select\ndepending on your application. Currently we do not offer a hybrid solver that can do both,\nbut that will be easily created in near future.\n\n- `PPP` is used when you cannot access an RTK network (or reference sites).\n- `RTK` is used for differential navigation, with at least one RTK reference site.\n\n`RTK` is currently limited to a single reference, but we will augment this to N base in very near future.  \n`RTK` should always be prefered over `PPP` to obtain higher accuracy more easily.  \nBoth solvers can operate without initial preset and can make a very good first guess to initialize themselves.\n\nIn static applications, it is important you keep the user `Profile` up to date, if the range of velocity varies.  \n`Profile` also contains the perturbations of the measurement system, this applies to all cases, either\nstatic or dynamic.\n\nApplication Programming Interface (API)\n=======================================\n\nThe API requires a few function pointers to be implemented. The orbit provider\nis mandatory. Other are actually optional, if you return `None` or `0.0` in those,\nyou will just degrade the accuracy of the solution.\n\nThe API is designed to allow real-time applications, which requires\nreal-time collection of orbital data and measurements. For each measurement,\nwhich happen in chronological order, you should group them as a list of Candidates\n(solving attempt proposal) that are synchronous and attempt solving, which requires mutable access.\n\nWhen solving attempt is requested, the solver will soon after issue a request on the orbit\nprovider interface, which is non mutable. In real-time application, the measurement\nand orbit collection should live in separate threads. The API is designed to allow\nthe Solver and the Orbit provider to live in the same thread. Assuming orbit collection\nwill require mutable access (on your side), you can use the concept of `Interior Mutability`,\nbecause the orbit provider is wrapped in a `Rc\u003c\u003e` structure.\n\nOrbit Provider\n==============\n\nWhen measurements have been proposed, the solver will issue a request to this function pointer,\nsoon after. That you must answer, otherwise this candidate proposal will be dropped and will not contribute\nto the solution. That is not a big deal, assuming you are in position to provide many measurements.\nBut we will always need at least 4 proposal to pass this step and future \"post-fit\" attitude filters\nthat you may have selected.\n\nOther function pointers are much easier to implement and are not mandatory.\n\nEnvironment models \u0026 perturbations\n==================================\n\nWe provide a function pointer that allows you to apply the Ionosphere and Troposphere perturbations\ncompensation. If you are in position to apply your own database and/or model, you then have an interface\nto do so. Returning no compensation will simply degrade the quality of your solution.\n\nIf you don't have a custom model, simply pick one of our internal models and apply it as the answer\nto the request. For example, `TroposphereModel` can serve as a simple answer to the troposphere perturbation request.\n\nTime transposition function\n===========================\n\nWe require a function pointer to perform any time transposition. This is very useful if you have\naccess to correction tables for finer temporal corrections. In case you don't, simply return\nthe transposition using `Epoch.to_time_scale()`.\n\nThis API allows us to support all timescales supported by Hifitime and obtain higher\nprecision for people who have access to such data.\n\nExamples\n========\n\nThis library is no longer shipped with examples. But our framework hosts applications that illustrate\nall use cases: \n\n- [GNSS-Qc](https://github.com/rtk-rs/gnss-qc) is dedicated to post processing workflows (more complex workflow).\n- [RT-Navi](https://github.com/rtk-rs/rt-navi) is a real-time application which therefore, requires multi-threading and \nrespect the threading requirements. It is also hardware dependent (obviously).\n\nLogs\n====\n\nThis library uses `$RUST_LOG` to report the current state, what it is doing, analyze your preset\nand give recommendations, and finally, help debug potential use cases.\n\nFor correct debugging, you should set `$RUST_LOG=debug`. For ulimtate debugging, `$RUST_LOG=trace`\nwill give all the information we output.\n\nSummary\n=======\n\nSelect a navigation method, depending on your equiment and targeted accuracy:\n\n| Method        | Physics                                  | Accuracy      |  Application                                            |\n|---------------|------------------------------------------|---------------|---------------------------------------------------------|\n| `SPP`         | Single Frequency Pseudo Range navigation |  2/5          | Low cost devices                                        |\n| `CPP`         | Dual Frequency Pseudo Range navigation   |  4/5          | Mid cost devices, Timing applications                   |\n| `PPP`         | Dual Frequency Pseudo Range + Phase      |  5/5          | High cost devices, Very precise applications, Profesionnal surveying and calibrations |\n\nSelect your solver, depending on your use case, type of application and targeted accuracy:\n\n| Solver        | Method        | Accuracy      |  Context                 |\n|---------------|---------------|---------------|--------------------------|\n| `PPP`         | `SPP`         | 3/5           | Low cost / hobbyist      |\n|               | `CPP`         | 4/5           | Mid cost / lab           |\n|               | `PPP`         | 4.5/5         | High cost / profesionnal |\n| `RTK`         | `SPP`         | 4/5           | Low cost / hobbyist      |\n|               | `CPP`         | 4.5/5         | Mid cost / lab           |\n|               | `PPP`         | 5/5           | High cost / profesionnal |\n\nDeployment\n==========\n\n:warning: ANISE requires internet access either\n\n1. at built time, when built with `embed_ephem` option \n2. at first deployment ever, when using low precision models and built without `embed-ephem` option\n3. regularly, when using highest precision models, regardless of the compilation options.\n\nThis library exposes the `embed_ephem` compilation option. By using it, it is possible to run up to\nmid-range and precise application without internet access. Ultra precise applications require\nregular updates from the Internet.\n\nConfiguration simplicity\n========================\n\nAlthough the taks is challenging, one objective is to keep things simple.   \nTo do so, we rely on the `serde` ecosystem and are able to provide [a consice and comprehensible Parametrization interface](./documentation/Config.md)\n\nNotes on Navigation Method\n==========================\n\nAbsolute or differential is selected at deployment. The \n[navigation method](https://docs.rs/gnss-rtk/latest/gnss_rtk/prelude/enum.Method.html) is defined\nby the configuration preset.\n\n- `SPP`: is a Pseudo Range navigation method for single signal / degraded / limited setups.\nPhase range observations are disregarded, unless you intend to use the L1+C1 enhancing smoothing technique.\nYou can enhance the `SPP` with an external model for environment perturbations. You can use the models we provide \nto answer that requirement. If you do not provide an accurate model (which is a complex thing to do), you cannot obtain\naccurate solutions. We recommend using a different technique for any setups that allow you to do so.\nIt is often times interesting to degrade a CPP or PPP run back to SPP to actually see the huge difference\nthese two made.\n\n- `CPP`: starting at CPP, we use physical cancellation of the ionosphere bias.\nYou need to provide two separate frequencies for this mode to operate.\nCPP is like SPP and purely based on Pseudo Range navigation, phase range are disregarded,\nunless you intend to use the L1+C1+L2+C2 smoothing technique.\n\n- `PPP`: has the same requirements and objectives, but phase observations\nare now also expected. It can be further enhanced by deploying the code smoothing technique.\nSince PPP is very heavy and requires all signals to be available, our PPP presets activate the \nsmoothing technique by default.\n\nAll of these are independent of the rover's profile AND the navigation technique:\n\n- you can use any signal strategy along any rover profile\n- you an use any signal strategy with either static or dynamic applications\n- you can use any signal strategy along RTK differential technique\n\nEnhanced Navigation techniques\n==============================\n\nWe provide a few options to enhance the accuracy of the solutions, depending of the context and input scenario.\n\n- When using `SPP` technique, you can provide L1 phase observations and deploy the L1+C1 code smoothing technique,\nto improve the accuracy of your results. This is very interesting for degraded / low-cost use cases.\n\n- When using the `CPP` technique, you can provide L1+L2 phase observations and deploy the L1+C1+L2+C2 code smoothing\ntechnique, which does not really make sense, because you are providing all the necessary input to switch to PPP technique.\nYou should switch to `PPP` technique any time L1 + L2 phase observations are feasible\n\n- Enhancing the `PPP` technique with code smoothing will improve the accuracy of the solutions.\n\nSurveying and Apriori Knowledge\n===============================\n\n`GNSS-RTK` is a complete surveying tool that can operate without apriori knowledge.  \nIn otherwords, it is possible to obtain a precise solution from scratch.  \n[Refer to this page that demonstrates this capacity](https://github.com/rtk-rs/rinex-cli/blob/main/demos/SURVEY.md). \n\nSignal and Measurement Flexibility\n==================================\n\nOne objective is to make this solver flexible and capable to adapt to most exploitation scenarios.  \nAnswering 100% of usecases is impossible, for the simple reason that GNSS applications\ncover a very wide spectrum and vary a lot. Yet we provide central key elements that are very interesting:\n\n* Possibility to navigate using a single signal. Obviously, the samples you provide\nshould match your navigation technique at all times. Yet, we have several navigation techniques,\nsome are compatible with single frequency observation. This makes our solver compatible with\ndegraded or low-cost environments\n\n* Military codes: our library only cares about frequencies.\nWhether you arrive from a decoded military or civilian signal does not matter.\nL1 is treated as main reference as always.\n\n* High precision frequencies: E6 (Galileo) and LEX (QZSS) are both known\n\n* :warning: This library requires L1 frequency to be present for advanced CPP or PPP techniques\n(as reference signal). We allow L2 or L5 as subsidary signal, without prioritizing them.\n\nConstellations, Timecales \u0026 Absolute time\n=========================================\n\nLike other topics, `GNSS-RTK` tries to be convenient to operate\nand flexible, regarding the temporal solution.\n\nWe support all timescales provided by `Nyx-Space/Hifitime`.   \nThe `Time` trait should be implemented for applications that require very precise temporal solutions.  \nIt allows following the timescale states precisely (using external corrections).  \n\nThis library is flexible enough to let you express your measurements in the timescale you want,\nand express the solution in the timescale you want. UTC timescale is fully supported.\n\nOther features\n==============\n\nNon exhaustive list of other interesting features\n\n- It is possible to apply a custom conic Azimutal + Elevation mask\n\nFramework\n=========\n\nGNSS-RTK includes itself within and is closely tied to the following libraries:\n\n* [ANISE](https://github.com/nyx-space/anise) for orbital calculations\n* [Nyx-space](https://github.com/nyx-space/nyx) for advanced navigation\n* [Hifitime](https://github.com/nyx-space/hifitime) for timing\n* [Our GNSS library](https://github.com/rtk-rs/gnss) for basic GNSS definitions\n* Nalgebra for all calculations\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Frtk-rs%2Fgnss-rtk","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Frtk-rs%2Fgnss-rtk","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Frtk-rs%2Fgnss-rtk/lists"}