MRTKLIB is a completely modernized, thread-safe, and modularized C11 library for standard and precise GNSS positioning.

It is designed to overcome the architectural limitations of the original legacy RTKLIB, providing a robust foundation for next-generation GNSS applications, including high-scale server processing, containerized environments, and seamless integration of Japanese QZSS augmentation services.

The structural foundation is based on MALIB (MADOCA-PPP Library) feature/1.2.0 developed by JAXA and TOSHIBA. The PPP/PPP-AR positioning engine comes from MADOCALIB, while the centimetre-level PPP-RTK engine is built on CLASLIB — making MRTKLIB the first open-source implementation to support real-time CLAS PPP-RTK positioning via rtkrcv. Kinematic positioning accuracy is further enhanced by selected algorithm improvements from demo5 RTKLIB. Both post-processing (rnx2rtkp) and real-time processing (rtkrcv) are supported, including L6E (SSR orbit/clock/bias) and L6D (CLAS CSSR) correction streams. Beyond the QZSS services, MRTKLIB also supports IGS-products PPP via the correction axis: float PPP from precise IGS/MGEX files (igs) or a real-time IGS-RTS RTCM-SSR stream (igs-rts), and integer PPP-AR from Bias-SINEX OSB phase biases. It additionally decodes Galileo HAS (High Accuracy Service) corrections from the free, global E6-B C/NAV signal for float PPP (gal-has) in both post-processing and real-time. The CLAS engine also handles single-band configurations — single-frequency (nf=1) signal sets and the Galileo E1/E5b band mismatch typical of u-blox ZED-F9P-class receivers (E5b tracked, CLAS corrects only E5a): the affected satellites run E1-only and the solution stays bounded (dm-level on the F9P mismatch dataset, not DF-equivalent), courtesy of the v0.7.4 ionosphere Gauss-Markov decay rather than any dedicated machinery. Both configurations are locked by regression tests against independent truth (see docs/design/sf-ppp-rtk.md).

MRTKLIB is not just another fork; it is a ground-up architectural redesign aimed at modern software engineering standards:

• Thread-Safe Design: Introduced the mrtk_ctx_t context structure to encapsulate states, error handling, and logging on a per-instance basis, replacing legacy global variables in the major processing pipelines and enabling parallel processing (e.g., handling multiple streams in a single server).
• POSIX & C11 Pure: Purged all Win32 API and legacy #ifdef macros. The core library is purely POSIX/C11 compliant, ensuring perfect portability across Linux, macOS (Apple Silicon), and embedded ARM/RISC-V devices.
• Modern Build System (CMake): Replaced scattered Makefiles with a unified, clean CMake build system. It natively supports standard find_package(LAPACK) for hardware-accelerated matrix operations (replacing bundled proprietary Intel MKL binaries).
• Domain-Driven Directory Structure: Flat source files have been beautifully categorized into specific domains (src/core/, src/pos/, src/rtcm/, src/models/, etc.) for high maintainability.

The ultimate goal is to unify the fragmented QZSS augmentation ecosystem into a single, conflict-free library. Current integration status:

With the MADOCALIB integration complete, users can process L6E (orbit/clock/bias corrections) and L6D (ionospheric STEC corrections) streams seamlessly in both post-processing and real-time modes.

MRTKLIB's positioning engines have been progressively modernized across releases (community-fork back-ports, new correction sources, tooling). Per-version detail is in the CHANGELOG and release notes:

Latest — v0.7.6: TOML configuration redesign. The configuration vocabulary from the v0.5.0 TOML migration is re-organized end to end: sections are regrouped by the engine that consumes them (the [receiver] / [server] grab-bags are dismantled, [adaptive_filter] nests under [positioning.clas]), inaccurate names are renamed, dead keys are removed, and several option-slot collisions in the positioning code are fixed. Old configs keep working — renamed paths load through deprecation aliases that warn with the new location, and unknown keys warn instead of being silently ignored (migration table in the CHANGELOG). The generated configuration reference gains a CI drift gate. Also new: receiver code bias + an opt-in uncorrected-pseudorange gate for IGS PPP-AR (#263), and the claslib periodic filter reset in post-processing PPP-RTK (#264) (PRs #256–#290).

v0.7.5: Single-band CLAS PPP-RTK — regression coverage and capability record. Not a feature release (no positioning-code change): two configurations the v0.7.4 engine already handles — single-frequency (nf=1) signal sets and the Galileo E1/E5b band mismatch of ZED-F9P-class receivers — are locked in by regression tests anchored to independent truth (GSI F5: 2D 1σ 2.5 cm; ECJ02 IGS-products coordinate: 3D 1σ 18.5 cm, E1-only-degraded and bounded, not DF-equivalent). docs/design/sf-ppp-rtk.md records the mechanics, the dependency on the ionosphere Gauss-Markov decay, and the post-mortem of the prototyped-then-subsumed SF iono constraint (PR #253).

v0.7.4: CLAS PPP-RTK accuracy — claslib parity. A five-part sync series aligns the CLAS PPP-RTK engine with upstream claslib across the correction-stream timing, measurement-model, and SPP-seed layers, closing the storm-day fix-rate gap tracked in #225. On the deterministic-BLAS storm benchmark the kinematic fix rate rises 89.44 % → 93.54 %, now above upstream claslib's 92.88 % on the same data — the single largest contributor being a BackupCSSR/BackupGrid port that bridges short correction gaps (+118 fixed epochs). A recurring ~0.10 m Galileo E5a antenna-PCV error (claslib ANTEX compaction) and the est-adaptive ionosphere Gauss-Markov decay wiring are both fixed. A new opt-in MRTK_DETERMINISTIC_BLAS build links single-thread OpenBLAS so these ±0.1 pp comparisons are bit-reproducible run-to-run (no positioning-code change; default build unaffected). The release also carries independent fixes: l6extract stack overflow, all-GNSS .stat output, and traceopen path handling (PRs #244–#248).

Next: BeiDou PPP-B2b as the next v0.7.x global SSR service; extend the CLAS-style CSSR dump to MADOCA / Galileo HAS / BeiDou B2b (#229); investigate the HAS absolute-accuracy offset (#215); tuned SPP P5/P6 (clock-jump + position EKF) on the GSDC smartphone benchmark (#165)

• Real-time CLAS L6D: Dual-channel support uses stream 3 for L6 ch1 and stream 2 (base slot, unused in PPP-RTK) for L6 ch2.
• Real-time L6E: The rtksvr provides a single correction input (inpstr3). Multiple QZSS L6E channels (e.g., QZS-3 and QZS-4) are supported when the receiver multiplexes them into one SBF stream.
• Real-time PPP-AR+iono: Ionospheric STEC correction via L6D is available in CLAS PPP-RTK mode but not in the MADOCA PPP-AR+iono path (post-processing only).

Real-time CLAS PPP-RTK positioning performance can be monitored on a public Grafana dashboard:

CLAS Summary Dashboard

The dashboard shows fix rate, ENU accuracy, satellite visibility, and correction age streamed from an active mrtk run session.

• CMake (>= 3.15)
• C11 compatible compiler (GCC, Clang)
• LAPACK/BLAS (Optional but recommended for fast matrix operations. e.g., liblapack-dev on Ubuntu, Accelerate framework on macOS) — requires the LP64 (32-bit integer) interface; ILP64 providers are not supported (for example, avoid OpenBLAS built with INTERFACE64=1). On CMake ≥ 3.22, MRTKLIB requests a 32-bit integer BLAS/LAPACK interface by setting BLA_SIZEOF_INTEGER=4. This is a CMake selection hint, not a complete ABI verifier for all BLAS/LAPACK package layouts: if FindBLAS/FindLAPACK still resolves an ILP64 provider (e.g. an ILP64 OpenBLAS published as plain libopenblas.so with no 64-suffixed name), make an LP64 BLAS/LAPACK provider visible to CMake explicitly. On older CMake, install an LP64 build of your BLAS/LAPACK provider (the default for most distributions).

MRTKLIB uses standard CMake workflow. Out-of-source builds are strictly recommended.

# Clone the repository
git clone https://github.com/h-shiono/MRTKLIB.git
cd MRTKLIB

# Configure the project
cmake -B build -DCMAKE_BUILD_TYPE=Release

# Build the library and apps
cmake --build build -j

The unified mrtk binary will be located in the build/ directory.

Configuration files (TOML) are stored in the conf/ directory. Test data and regression datasets are available in tests/data/.

# Example: Running post-processing analysis
./build/mrtk post -k conf/malib/rnx2rtkp.toml tests/data/rtklib/rinex/xxxx.obs ...

# Example: Real-time positioning
./build/mrtk run -s -o conf/claslib/rtkrcv.toml

MRTKLIB is developed using an AI-assisted workflow. Algorithm porting, test authoring, and code migration are performed with Claude Code (Anthropic). Architecture, implementation strategy, and final review are directed by the project author; porting strategy design is also supported by Gemini Pro (Google).

All commits, test results, and architectural decisions remain under human authorship and review.

MRTKLIB includes both robust unit tests (utest) and regression tests to ensure core stability when merging complex GNSS algorithms.

cd build
ctest --output-on-failure

The codebase is fully documented using Doxygen. To generate the API reference and call graphs:

cmake --build build --target doc

Documentation will be generated in build/doc/html/index.html.

If you use MRTKLIB in your research or product, please cite it via its archived release on Zenodo. You can cite all versions by using the concept DOI 10.5281/zenodo.20373746; Zenodo also mints a version-specific DOI for each individual release.

@software{mrtklib,
  author    = {Shiono, Hayato},
  title     = {{MRTKLIB: Modernized RTKLIB for Next-Generation GNSS}},
  publisher = {Zenodo},
  doi       = {10.5281/zenodo.20373746},
  url       = {https://doi.org/10.5281/zenodo.20373746}
}

MRTKLIB is distributed under the BSD 2-Clause License.

This project stands on the shoulders of giants:

For detailed licensing information, please refer to LICENSE.

Kinematic (geodetic). The PPC-Dataset (Precise Positioning Challenge 2024), kindly released as open data by:

Taro Suzuki, Chiba Institute of Technology https://github.com/taroz/PPC-Dataset

Smartphone (SPP). The Google Smartphone Decimeter Challenge 2023 (GSDC-2023), released on Kaggle by Google for the ION GNSS+ conference and used here under the Kaggle competition rules:

https://www.kaggle.com/competitions/smartphone-decimeter-2023

See docs/reference/benchmark.md (kinematic) and docs/reference/benchmark-gsdc.md (smartphone) for usage instructions.