Scenario kind pagesEdit on GitHubSource: docs/kinds/by-kind/pvt.md

pvt (scenario kind)

Scenario kind of the engine v0.38.0, family GNSS measurements, positioning and integrity. Advisory: analysis output from a research and engineering tool, not type-approved navigation equipment and not a safety-of-life service. Every label here is the engine's or the verification matrix's; a kind is MODELLED unless the matrix says otherwise (how a label is earned: the README's Evidence section).

What it does#

Real-observation single-point positioning: solve a receiver's position from a RINEX 3 observation file and a broadcast-navigation file (code pseudoranges, broadcast ephemeris, Klobuchar iono, Saastamoinen/Niell tropo), optionally validated against a surveyed coordinate.

One run of scenarios/pvt-abmf.toml summarises as: pvt 55bdd18628e1 | 11 sat nav | 2/3 epochs solved | mean 9.0 sats, PDOP 1.8 | 3D error RMS 5.74 m (max 7.12 m)

Inputs#

From the schema (kshana kinds --json):

  • Required fields: obs_rinex, nav_rinex
  • Optional fields: truth_ecef, apriori_ecef, mask_deg, dual_frequency

The example scenarios/pvt-abmf.toml sets, among others:

Field Value Unit
dual_frequency true flag
kind pvt text
mask_deg 5 deg
nav_rinex 3.03 N: GNSS NAV DATA M: MIXED text
obs_rinex 3.02 OBSERVATION DATA M text
truth_ecef [2.9198e6, -5.3837e6, 1.7746e6] not stated

Run it#

kshana scenarios/pvt-abmf.toml

What it gives#

The scalar results of that run, with the units the engine states:

Result Value Unit
fom.epochs_solved 2 count
fom.epochs_total 3 count
fom.max_3d_m 7.116806 m
fom.mean_n_used 9 count
fom.mean_pdop 1.793611 1
fom.mean_postfit_rms_m 1.971614 m
fom.rms_3d_m 5.740406 m
fom.rms_h_m 1.138199 m
fom.rms_v_m 5.626435 m
n_satellites_nav 11 count
The chart the engine writes for scenarios/pvt-abmf.toml, kind pvt

Evidence#

MODELLED: the verification matrix rows that name this kind.

  • MODELLED Divergence-free Hatch filter (ionosphere-free code carried by the ionosphere-free carrier, window N epochs, restart on loss of lock, geometry-free jump or gap) in the precise single-point positioning assembly
  • MODELLED dop_error_mc::run_geometry and check: a seeded Monte Carlo (N = 20,000 epochs per geometry, sigma = 1.5 m, ChaCha8 seed 36 + i) of the engine's own iterated least-squares fix (pvt::solve_spp, unit weights, solved from the true position) on Tests: uere_dop_monte_carlo.rs.

The rows the run itself exercised, with the oracle the matrix gives each (the public sources are named there):

  • VALIDATED IS-GPS-200 / Galileo-OS / BeiDou-OS broadcast-ephemeris Keplerian → ECEF satellite position from a parsed RINEX-3 navigation record. Oracle (ExternalDataset): RTKLIB v2.4.2-p13 eph2pos() compiled from C source (T. Takasu, BSD-2-Clause) — an independent IS-GPS-200/SIS-ICD implementation, fed the identical RINEX-3 nav records; satellite ECEF position matched to ~62 nm. (SP3 precise-ephemeris interpolation is validated separately — see 'SP3 precise-ephemeris interpolation')
  • MODELLED Deterministic, scenario-hashed, SBOM + cross-platform golden gates. Oracle (ExternalDataset): SBOM conformance to the official CycloneDX 1.5 JSON Schema (+ valid SPDX identifiers) — an external published standard, zero validation errors over the full dependency graph; the FoM-determinism / byte-reproducibility part remains a pinned self-consistency check, so the row stays MODELLED

Limitations#

What the run's own report says is not modelled or not validated:

  • Reproducibility & software assurance is MODELLED, not validated: a sub-claim is externally checked, but the whole capability composes modelled pieces, so the capability stays Modelled. (verification matrix (docs/MODELLED-RATIONALE.md))

See also#