Kshana · क्षण · the precise instant
An open-source simulator for PNT (positioning, navigation and timing) resilience.

Open Kshana Studio · Install · Capabilities · Evidence · Research · Documentation · Cite

Languages: English · Nederlands · Polski · Português (Brasil) · Português (Portugal) · Suomi · Svenska · Dansk · Norsk bokmål · Čeština · Українська · Русский · Deutsch · Français · Español · Eesti · 日本語 · 简体中文
_{The command line, run summaries, charts and reports speak each language with --lang <tag>
(for example kshana scenarios/holdover-test-example.toml --lang de), and so do the Python, WebAssembly and MCP surfaces.
Each name opens this README in that language, and the website is translated too (for example kshana.dev/de/).
These are machine translations that no native speaker has reviewed yet; English is the reference.
See Localisation.}

Contents

Rehearse the minute GNSS goes dark
What's new in 0.40, What's new in 0.39, What's new in 0.38, and 0.38 in depth: jammertest scoring, the receiver's own flags, machine inputs, timing and holdover, standards packs, LunaNet AFS, the lab round trip, kshana-bench, the observatory, exporters, optical, space-user navigation and lunar infrastructure
Kshana Studio and every Studio page
Capabilities: the table of areas, every scenario kind by family, every command, every surface
How a run works, Missions
Evidence: the ledger, capability domains
Install, Architecture (and the diagrams), AI assistant
Editions, Research, Cite, Licence
Reference: usage, scenario format, output, repository layout, FAQ, troubleshooting, versioning, roadmap, contributing, documentation

Rehearse the minute GNSS goes dark

Kshana replays jamming, spoofing and clock holdover when GNSS (Global Navigation Satellite System) signals fail, and tells you how long a system keeps time and position inside its budget, and which clock or sensor buys the most margin. It is one Rust engine. It runs in a terminal, a notebook, an IDE (integrated development environment), an AI (artificial intelligence) assistant, or in your browser.

Every run is reproducible bit for bit from the scenario, the seed and the engine version. Every capability carries one of three labels in a machine-checked ledger: VALIDATED (an independent external oracle agrees), MODELLED (internally consistent, and said out loud) or PARTNER (a hardware partner owns it).

Status: v0.40.0. A validated, reproducible simulation substrate for PNT resilience. Timing and holdover come first, because that domain is the best validated. Kshana is a study and trade-off instrument: not radio-frequency (RF) signal-generator hardware (it drives no radio and transmits nothing; its signal-level output is baseband IQ sample files for software receivers), not a hardware or certified GNSS receiver (its software receiver is an analysis tool) and not a flight product. New to the field? Start with the plain-language primer and the glossary.

What's new in 0.40

0.40 adds a mission-level error budget, labels every figure and table with its evidence tier, reads measured clock logs, checks data-partner submissions, estimates where an interference emitter can be, and speaks seventeen languages beside English. The ledger is now 401 rows: 176 VALIDATED, 221 MODELLED, 4 PARTNER. No row was promoted to VALIDATED, and every miss below is pinned by a test.

Mission thread. The mission-thread kind chains phases from launch to entry (launch-ascent, leo-rendezvous, tli-and-cruise, entry and four lunar kinds) with stated handover rules, a margin against stated requirements and the weakest link; an end-to-end Artemis-class example over 11 phases (Earth and lunar segments), 92 scenario kinds in all. Every number is MODELLED. The cislunar propagation against the public Artemis I trajectory misses its pre-registered bar (45.3 km and 0.25 m/s against 5 km and 0.05 m/s; the cause is small manoeuvres the model does not include), and the lunar propagator against the CAPSTONE orbit misses (136.8 km against 25 km at the end of one revolution); the LRO comparison is met. The rows stay MODELLED (Mission thread, lunar segment). In the Studio the thread is read at /studio/mission-thread/.
Evidence labels. Every figure and table a run writes carries the tier and the ledger row ids it rests on, read from the matrix.
Measured clocks. Eight clock-log formats are read (docs/CLOCK-LOG-FORMATS.md) and a fitted series can drive the holdover. Against pre-registered bars the fit misses F1(a) on five of six records and F2 on one; both stay MODELLED (Changelog).
Data partners. kshana partner check checks the format of a submission and scores nothing (docs/PARTNER-DATA.md).
Emitter region. kshana interference-map locate gives a region and an ellipse, never a bare point, from ADS-B or AIS reports. Compared once with the Jammertest 2025 transmitter sites, the result is NOT ASSESSABLE for both sources (too few scheduled sessions in the open data), so the row stays MODELLED (Interference map).
Benchmark. The 0.40 re-campaign meets A3, D3 (both EXPLORATORY), R3 and R4; A2, D1 and R1 stay NOT MET (Bench).
Languages. nl, pl, pt-BR, pt-PT, fi, sv, da, nb, cs, uk, ru, de, fr, es, et, ja and zh-Hans, as machine translations that no native speaker has reviewed; English is the reference, and non-English runs take about twice as long (docs/i18n.md).

What's new in 0.39

0.39 adds no feature and changes no result; the engine's output is the 0.38 output. It fixes one thing on the command line, updates dependencies of the cross-validation tooling, and states the benchmark verdicts in full.

Command line. kshana kinds | head (any closed standard output) no longer panics: the program exits quietly with status 141, as other tools do for a closed pipe. Other write errors still report themselves.
Dependencies. memmap2 0.9.11 in the two ANISE cross-check locks and pillow 13.0.0 and certifi 2026.10.19 in the oracle environment pins, all under xval/: nothing that ships changed.
kshana-bench, all verdicts. Against the pre-registered bars, three are NOT MET, each pinned by a test: A2 (agc_k_sigma AUC 0.766 against at least 0.80), D1 (largest gap 0.0301) and task (b) R1 (carried, not re-run). No bar was loosened (Bench).

What's new in 0.38

0.38 makes the neutral referee measurable: it scores receiver logs against a published test schedule, reads more receivers and sensors, tests timing systems, and ships a benchmark and an interference observatory. It stays advisory: nothing here is certified, no result is a type approval, and nothing transmits. Each row states what the ledger holds for it (how a label is earned); a status names only what was checked, and the ledger row and the linked page say what was not.

New in 0.38	What it does, and why	Ledger status	Read
Jammertest scoring	`kshana jammertest import` reads the published NPRA test catalogue and transmission plan as scheduled truth; `jammertest score` scores a receiver log per test (detection latency, missed alarms, false alarms, time to recover), as a signed evidence pack if you give a key	MODELLED: one ledger row. The bars were pre-registered before any scored run; on the JammerTest 2024 data the minimum-data rule failed in both runs (4 and 7 scorable windows against 10 required), so no bar is assessable and nothing is claimed	Jammertest
The receiver's own flags	UBX-NAV-STATUS `spoofDetState`, UBX-SEC-SIG and NovAtel RXSTATUS read into a per-epoch `self_report` and compared with Kshana's alarms (both, receiver only, Kshana only, neither); a Septentrio SBF reader and read-only `--serial` input	MODELLED; agreement between a receiver's detector and Kshana's is not validation	Receiver trust
More receivers and sensors	RTKLIB `.pos`, NovAtel OEM7, RTCM 3 MSM4/MSM7 C/N0 (from the BSD-licensed pyrtcm tables, not the RTCM text), GNSS-SDR monitor streams, an IMU log as a second sensor, a ROS 2 package, a `gnss_lib_py` bridge, and `imu-fit` for hybrid sensor parameters	MODELLED: six ledger rows; self-written fixtures only, no capture from a real receiver, IMU, GNSS-SDR run or ROS graph was read	Machine inputs
Timing and holdover tests	the `holdover-test` kind scores a holdover test (GNSS removed by the operator, holdover, recovery) from a measured time-error record against ITU-T masks, "measured against the mask"; linuxptp and chrony log readers; the hardware stages and the `lab-attestation` field	MODELLED: two ledger rows; the times are the operator's statement, not verified	Timing HIL, Hardware safety
Standards packs, LunaNet AFS, lab round trip	scored packs for DHS RPCF, IMO MSC.1/Circ.1575 and ICAO Doc 9849 Appendix F against bars stated before the run, "supports evidence for"; a NIST IR 8323r1 crosswalk; a LunaNet AFS code generator and checker; a signed pack that links a lab run's scenario, test conditions, receiver log and score	MODELLED for the packs and the round trip; the AFS code check is VALIDATED against its printed check columns (see the ledger rows)	Standards, LunaNet AFS
kshana-bench and the observatory	fixed tasks, splits and metrics for interference detection, IQ detection, holdover prediction and the optimism gap, with a sealed holdout and a static leaderboard; a reproducible daily interference product with a 24 h delay, coarse cells and no attribution	no ledger row of its own: it scores submissions, and its baselines are labelled MODELLED in the result files; against the pre-registered bars the scorer, C1 to C3 and D2 are met and three bars are NOT MET (pinned by tests): A2 (`agc_k_sigma` AUC 0.766 against at least 0.80 on the test split), D1 (largest gap 0.0301) and task (b) R1 (carried, not re-run); see `xval/bench/RESULTS-v2.md`	Bench, Observatory
Exporters	trust telemetry as Home Assistant MQTT discovery and state messages (publish only, no credentials) beside Prometheus, CEF, LEEF and OTLP	MODELLED: one ledger row	Trust telemetry
Optical link margin against time	the `optical-atmosphere` kind can write one seeded realisation of a site's weather as a link-margin series	MODELLED: one ledger row; one draw from the model, not the climate	Optical atmosphere

0.37's highlights: changelog. The full 0.38 list is in the changelog.

0.38 in depth

Each capability from the table above, in a few lines: what it does, one command to run it, one picture drawn from a real run of the engine, and what the ledger holds for it. The pictures are written by tools/gen_figures_038.py into docs/figures/0.38/ (never drawn by hand): python3 tools/gen_figures_038.py rewrites them from a built engine, and --check fails if one is stale or its caption here differs. Where an input is a log, it is a made-up one the script writes, because the real third-party logs are never vendored, and the caption says so. Everything below is advisory: not certified, not a type approval, and nothing transmits. A status names what was checked and nothing more; how a label is earned.

Jammertest scoring

kshana jammertest import turns the published NPRA test catalogue and transmission plan into scheduled truth, and kshana jammertest score scores a receiver log against it: for each scheduled test, whether it was detected, how late, and how long the receiver took to recover, plus false alarms outside every slot. The catalogue is fetched, never vendored.

xval/jammertest-plan/fetch.sh ../jammertest-plan
kshana jammertest score session.toml --catalog ../jammertest-plan/testcatalog2025.json \
    --plan ../jammertest-plan/plan-tuesday-2025-09-16.json --location 1 --json

Scoring of one synthetic receiver log against a three-test schedule, from a real run of engine v0.40.0 (`kshana jammertest score`). The log is made up: 1800 s of NMEA with a 20 dB C/N0 drop over two intervals. The schedule lists three slots; the middle slot has no jammer in the log. The score marks 2 of 3 tests detected (median latency 0 s) and 1 missed, with 0 false-alarm runs over 0.25 h of clean time. Nothing here says anything about a real receiver. Advisory software, not type-approved navigation equipment (IEC 61108, IEC 61162): the operator remains responsible for the navigation of the vessel.

Ledger status: MODELLED. The bars were fixed before any scored run; on the JammerTest 2024 data the minimum-data rule failed in both runs, so no bar is assessable and nothing is claimed. Jammertest.

The receiver's own flags

UBX-NAV-STATUS spoofDetState, UBX-SEC-SIG and NovAtel RXSTATUS are read into a per-epoch self_report and set beside Kshana's alarms: both, receiver only, Kshana only, or neither. A Septentrio SBF reader and a read-only --serial input feed the same comparison. Neither side is ground truth.

kshana receiver-trust session.toml     # [log] format = "ubx", path = "receiver.ubx"

Ledger status: MODELLED. Agreement between a receiver's detector and Kshana's is not validation. Receiver trust.

More receivers and sensors

RTKLIB .pos, NovAtel OEM7, RTCM 3 MSM4/MSM7 C/N0, GNSS-SDR monitor streams, an IMU log as a second sensor, a ROS 2 package and a gnss_lib_py bridge all end in the same receiver-trust timeline. imu-fit reads the sensor parameters the hybrid and fusion scenarios need off a stationary IMU log, so a scenario can be run with the sensor you actually have.

kshana imu-fit still.csv --format csv --axis x --expected-mean 0 --id bench-imu

What `kshana imu-fit` reads off a stationary IMU log, from a real run of engine v0.40.0 on a made-up log (20,000 samples at 100 Hz, 200 s): the accelerometer velocity random walk q_va = 4.02e-06, the gyro angle random walk q_arw = 9e-08, the bias instability 0.00296 and the early Allan slopes (-0.51 and -0.49; about -0.5 where white noise dominates). The table beside it is the TOML the command prints. The estimator is checked on synthetic logs only. Advisory: analysis output from a research and engineering tool, not type-approved navigation equipment and not a safety-of-life service.

Ledger status: MODELLED. Self-written fixtures only; no capture from a real receiver, IMU, GNSS-SDR run or ROS graph was read. Machine inputs.

Timing and holdover tests

The holdover-test kind scores a holdover test (GNSS removed by the operator, holdover, recovery) from a measured time-error record against ITU-T masks, and says so in those words: measured against the mask. linuxptp and chrony log readers feed it; the hardware stages and the lab-attestation field say who stated what.

kshana scenarios/holdover-test-example.toml

A holdover test scored from a time-error record, from a real run of engine v0.40.0 on scenarios/holdover-test-example.toml (601 samples every 5 s). GNSS is removed by the operator at 600 s and restored at 2400 s; the time error drifts to 299 ns at the end of holdover, past the 100 ns budget after 675 s, and returns inside the 100 ns band 70 s after restoration. Verdicts: baseline masks PASS, holdover masks FAIL, holdover envelope FAIL, recovery RECOVERED. Measured against the mask, not an approval. The times are the operator's statement, not verified by Kshana. Advisory: analysis output from a research and engineering tool, not type-approved navigation equipment and not a safety-of-life service.

Ledger status: MODELLED. The times GNSS was removed and restored are the operator's statement, not verified. Timing HIL, Hardware safety.

Standards packs

Scored packs for the DHS Resilient PNT test profiles, IMO MSC.1/Circ.1575 and ICAO Doc 9849 Appendix F, plus a NIST IR 8323r1 crosswalk in compliance-report. Each test runs a bundled scenario and compares a result field with a bar stated before the run; a test that needs a receiver log is listed as needing an input, not scored. The wording is "supports evidence for".

kshana standards-pack list
kshana standards-pack run imo-circ-1575

Every test of the three scored standards packs, from real runs of engine v0.40.0 (`kshana standards-pack run`): dhs-rpcf: 6 met, 1 not met, 2 need an input; imo-circ-1575: 1 met, 4 not met, 2 need an input; icao-doc9849-appf: 6 met, 0 not met, 2 need an input. In all, 13 met, 5 not met and 6 need an input the engine does not have (a receiver log or equipment documentation). Each bar was stated before the run; a miss is kept as a miss. A met bar says a modelled scenario met a stated bar, nothing about a product. The packs support evidence for the rows they cite; they are not an assessment. Advisory: analysis output from a research and engineering tool, not type-approved navigation equipment and not a safety-of-life service; it must not be the sole basis for any navigation or safety decision.

Ledger status: MODELLED. A met bar says a modelled scenario met a stated bar, nothing about a product; every miss is kept and pinned by a test. Standards.

LunaNet AFS

The LunaNet Augmented Forward Signal code generator (Gold, Weil and tertiary codes, the message frame and its error coding) and a checker for a recorded or generated symbol stream, pinned to one edition of the specification.

kshana lunanet-afs-check spec
kshana lunanet-afs-check generate --frames 2 --out afs.sym
kshana lunanet-afs-check symbols afs.sym

The LunaNet AFS code generator checked against the printed columns of the specification, from a real run of engine v0.40.0 (`kshana lunanet-afs-check spec`, pinned to LNIS V5, AD1 Volume A (LSIS-AFS) V1.0, 29 January 2025; the document marks its code tables {LSIS-TBC}). 9 of 10 checks are met; B4 is NOT MET (420 of 421 matched). It checks a symbol stream against one edition of a published specification and says nothing about any LunaNet node or service. Advisory: analysis output from a research and engineering tool, not type-approved navigation equipment and not a safety-of-life service. It checks a symbol stream against one edition of a published specification and says nothing about any LunaNet node or service.

Ledger status: VALIDATED for the code and synchronisation checks, against the values the specification prints (which it marks TBC); one check is NOT MET, kept and pinned (one printed tertiary-code column differs: the document prints the same value for two PRNs). The LDPC and CRC words of subframes 2 to 4 are not checked. The ledger rows say exactly which. LunaNet AFS.

Lab round trip

kshana.test-conditions/1 is a published description of what a laboratory did (events, times, powers). kshana evidence round-trip links the scenario hash, the conditions hash, the receiver log hash and the score into one signed pack, and refuses a pack whose conditions and scoring scenario disagree about the events. Kshana never produces or replays a signal: how a scenario reached a receiver is the operator's responsibility.

kshana evidence --help

The structure of an evidence pack. A receiver log (NMEA, u-blox UBX, RINEX 3 or an Android log) and a time window go into kshana receiver-trust evidence, which writes seven files: log-slice.bin, config.json, epochs.json, summary.html, manifest.json, manifest.sig and an optional timestamp.tsr. The manifest records the SHA-256 of the whole log and of every file and a hash chain over the files; the signature covers the manifest. kshana evidence verify checks the signature, every file's hash, the chain and that no unlisted file is present, and exits 0 when verified, 1 when something failed and 3 when the signer was not pinned. A pack is a technical record, not a legal opinion.

The picture is the layout of a pack. Ledger status: MODELLED. Test conditions, Test bench.

kshana-bench

Fixed tasks, splits and metrics for interference detection, IQ detection, holdover prediction and the optimism gap, with a sealed holdout and a static leaderboard. It scores submissions; it is not a ranking of receivers.

kshana bench baseline --task d --split test --out results/

The built-in baselines of kshana-bench task D (the optimism gap) on the test split, from a real run of engine v0.40.0 (`kshana bench baseline`). Each bar pair is the area under the ROC curve on the in-distribution cases and on the shifted cases; the gap between them is the optimism gap, against a tolerance of 0.05. fused-max-z: 0.998 and 0.983 (gap 0.015); sqm-imbalance: 0.882 and 0.882 (gap 0.001); agc-excess: 0.848 and 0.819 (gap 0.030); raim-parity: 0.682 and 0.672 (gap 0.010); energy-cn0-drop: 0.595 and 0.565 (gap 0.030). The labels are generative-model labels of a synthetic corpus, never field data: MODELLED. Advisory: modelled or measured against stated references, not an approval, certification or statement of conformance. A score describes a log or corpus, never a product.

Ledger status: no ledger row of its own; the baselines are labelled MODELLED in the result files. Against the pre-registered bars the scorer, C1 to C3 and D2 are met and three bars are NOT MET, each pinned by a test: A2 (agc_k_sigma AUC 0.766 against at least 0.80 on the test split), D1 (largest gap 0.0301) and task (b) R1 (carried from the earlier campaign, not re-run). The figures are in xval/bench/RESULTS-v2.md. Bench.

Interference observatory

One product per UTC day and region from an open aircraft-position archive, on a fixed coarse grid: each cell is degraded, not degraded, or not observed (which is not "clear"). Released no earlier than 24 h after the day ends, with small cells suppressed and no attribution of cause.

kshana interference-map daily /path/to/extracted/2026-09-15 \
    --dataset adsb-lol --day 2026-09-15 --bbox 53.5,9.0,66.0,31.0 --out products/

Two synthetic interference-map days drawn from the committed samples in examples/interference-map/output, each with its own synthetic route and the route-exposure shares the engine reports. Left, an ADS-B day: 1 degraded cell, 6 not degraded, 4 unassessed (hatched) and cells with no entry, drawn empty, which were not observed. The route is 525 km: 11.5% of its length in degraded cells, 38.3% not degraded, 9.1% unassessed and 41.1% not observed. Right, an AIS day: cells flagged by the circle and on-land detectors, not-anomalous cells and empty cells; the route is 454 km with 10.5% in anomalous cells, 21.2% not anomalous, 0.0% unassessed and 68.3% not observed. ADS-B and AIS are separate layers, never combined. A flagged cell is not a finding of interference, and a cell with no colour was not observed, which is not the same as clear. All data are made up, in the open mid-Atlantic, and not a measurement.

The picture is the committed sample days, not an observatory product. Ledger status: MODELLED: no external oracle, no ground truth and no cause attribution; a cell that is not observed was not assessed, which is not the same as clear. Observatory method.

Exporters

Trust telemetry as Prometheus text, CEF, LEEF, OTLP and Home Assistant MQTT discovery and state messages. The command publishes only to a destination you give it and holds no credentials.

kshana trust-telemetry --result session.result.json --print-metrics
kshana trust-telemetry --result session.result.json --print-syslog --format cef

One trust result in three export formats, from real runs of engine v0.40.0 (`kshana trust-telemetry`) on examples/maritime-trust: Prometheus text exposition (the latest trust score is 5.9 and the untrusted band is the one set), and the last CEF and LEEF messages. The command publishes nothing unless given a destination, holds no credentials, and transmits no radio signal. Advisory software, not type-approved navigation equipment (IEC 61108, IEC 61162): the operator remains responsible for the navigation of the vessel.

Ledger status: MODELLED. Trust telemetry.

Optical link margin against time

The optical-atmosphere kind can write one seeded realisation of a site's weather as a link-margin series: cloud episodes, a liquid-water column for each, one scintillation sample per step. The Studio's Optical PNT page opens the optical-atmosphere scenarios.

kshana scenarios/optical-atmosphere-network.toml

One seeded realisation of the link margin of the site 'northern' over 336 h, from a real run of engine v0.40.0 on scenarios/optical-atmosphere-network.toml (seed 37, a step of 600 s). The margin falls below zero during cloud episodes; in this draw the link is up 40.5 % of the time, with 27 outages and a longest outage of 30.7 h. The inputs are illustrative, the series is one draw from the model and not the climate, and it differs from the statistical availability (37.8 %) by the sampling error of the draw. Advisory analysis only: not a certified availability, integrity or navigation product, and not a prediction for any real site unless its climate inputs come from a stated dataset.

Ledger status: MODELLED. One draw from the model, not the climate. Optical atmosphere.

New Studio views

kshana.dev/studio gains a Bridge replay (two runs side by side on one mission clock, at /studio/replay/), an Optical PNT page (/studio/optical/), a Holdover test page (/studio/holdover/) and an observatory viewer (/studio/observatory/). They run the same engine in the browser, nothing is uploaded, and they carry the same advisory statement. The pictures above are drawn from the engine's own output by a script; they are not screenshots of these pages.

Space-user navigation (`gnss-ssv`)

For a spacecraft above, around or far past the GNSS orbits: how many GNSS signals it can use, how strong they are, how good the geometry is, and what an onboard filter can do with them. One kind, four modes, chosen by the scenario's tables: a shell of users (the share of time with one and four signals, per constellation), a trajectory (signals, C/N0, dilution of precision and the limb-ray medium along an orbit), a navigation run (a nine-state filter on pseudoranges, to the Moon) and a formation (relative navigation of deputies about a chief). The public source for the availability comparison is the interoperable GNSS Space Service Volume booklet (UN OOSA ST/SPACE/75, from the International Committee on GNSS), which is itself a simulation; it is fetched, never vendored. Full page: docs/SSV.md.

kshana scenarios/gnss-ssv-shell.toml            # shell: the upper space service volume, reduced size
kshana scenarios/gnss-ssv-heo.toml              # trajectory: a high Earth orbit, limb medium
kshana scenarios/gnss-ssv-nav-lunar.toml        # navigation: an onboard filter toward the Moon
kshana scenarios/gnss-ssv-formation-heo.toml    # formation: relative navigation

Signals along one high Earth orbit (perigee 497 km, apogee 58622 km, period 18.8 h), from a real run of engine v0.40.0 on scenarios/gnss-ssv-heo.toml, band L1. Top: the best carrier-to-noise density among the signals in view, against the 20 dB-Hz threshold. Middle: the number of signals in view from all constellations, from 4 to 55 along the sampled points. Of the links received, 2252 came through a main lobe and 696 through sidelobes, using a labelled parametric stand-in pattern, not any system's measured pattern. Median PDOP 67, 95th percentile 358. MODELLED: a modelled study from stated inputs, not a measurement and not a service-volume claim for any system. Advisory: analysis output from a research and engineering tool, not type-approved navigation equipment and not a safety-of-life service.

Relative navigation of 2 deputies around a chief on a high orbit, from a real run of engine v0.40.0 on scenarios/gnss-ssv-formation-heo.toml (401 epochs). For each deputy, two bars: the relative position RMS from subtracting the two independent absolute estimates, and from the relative filter on single-differenced pseudoranges. Baseline 0.8 km: 5.1 m and 1.2 m. Baseline 2.0 km: 4.1 m and 2.1 m. The absolute filter is not consistent here: mean normalised estimation error squared 187 against about 3 for a consistent filter, so its stated uncertainty is far too small. MODELLED: a modelled study from stated inputs, not a measurement and not a service-volume claim for any system. Advisory: analysis output from a research and engineering tool, not type-approved navigation equipment and not a safety-of-life service.

Ledger status: MODELLED, and the comparison with the booklet mostly misses. The bars were fixed before the run. Of eight, only S0 (the inverse link budget, 13 of 13 values) and S6 (the lunar mission) are met. S1 to S5 and S7 are NOT MET: the upper and lower service volume geometry (43 of 52 and 48 of 52 cells), the 15/20/25 dB-Hz upper service volume, the six GEO missions, the HEO mission, and the parametric sidelobe pattern against measured GPS panel patterns. Almost every miss in S1 to S5 involves GLONASS, and the booklet prints two different reference angles for it; a diagnostic variant that uses the other pair brings S1, S2 and S4 to every cell, but it does not replace the run of record and no row is VALIDATED. The formation run's absolute filter is also overconfident (mean normalised error squared well above the value of about 3 that a consistent filter gives).

The recorded comparison of the space-user availability model with the public Space Service Volume booklet, from the committed results of the pre-registered run (xval/gnss-ssv/results-run1.json, written by the ssv_booklet_check example of engine v0.40.0). Bar by bar, the cells within tolerance: S0 13 of 13 (MET); S1 43 of 52 (NOT MET); S2 48 of 52 (NOT MET); S3 122 of 155 (NOT MET); S4 132 of 156 (NOT MET); S5 18 of 26 (NOT MET); S6 26 of 26 (MET); S7 0 of 20 panel patterns (NOT MET). Only S0 and S6 are met under the pre-registered reading. A diagnostic variant that uses the booklet's other GLONASS angles brings S1, S2 and S4 to every cell, but does not replace the run of record. No ledger row is VALIDATED. Advisory: analysis output from a research and engineering tool, not type-approved navigation equipment and not a safety-of-life service.

Space-user navigation, what the comparison shows.

Lunar infrastructure (`lunar-infrastructure`)

The Moon's orbit and surface as navigation and geodetic infrastructure, in five studies chosen by study: od-consistency (an onboard Earth-GNSS orbit determination in a halo orbit against an independent ground one), carrier-phase (integer ambiguity fixing between surface stations and an orbiter), frame-coestimation (the lunar datum from Earth-station ranging with and without orbiter links), space-tie (laser, VLBI and GNSS offsets on one spacecraft against the local-tie error) and geodesy-sensitivity (which observable family sees the Love numbers h2, k2 and l2). The model is a restricted three-body one with stated simplifications and illustrative inputs. Full page: docs/LUNAR-INFRASTRUCTURE.md.

kshana scenarios/lunar-infrastructure-od-consistency.toml
kshana scenarios/lunar-infrastructure-carrier-phase.toml            # quick; the scored run takes about eight minutes
kshana scenarios/lunar-infrastructure-frame-coestimation.toml
kshana scenarios/lunar-infrastructure-space-tie.toml
kshana scenarios/lunar-infrastructure-geodesy-sensitivity.toml

Carrier-phase integer ambiguity fixing between lunar surface stations and an orbiter, from the committed result of the scored run of engine v0.40.0 (tests/fixtures/lunar_infra/phase_full_run.json: 3 arc lengths, a Monte Carlo of 401 draws each, written by scenarios/carrier-phase-scored.toml). 1 day: success 1.0 % (standard error 0.5 %), 134 ambiguities, orbiter position sigma 45.6 m float and 18.5 m fixed; 2 day: success 0.5 % (standard error 0.4 %), 259 ambiguities, orbiter position sigma 21.5 m float and 8.7 m fixed; 3 day: success 2.8 % (standard error 0.8 %), 375 ambiguities, orbiter position sigma 6.3 m float and 2.1 m fixed. Integer fixing is not achieved: success stays between 1 % and 3 % at 25 dBi, and at the registered 12 dBi the problem cannot be formed. MODELLED: a restricted three-body model with stated simplifications and illustrative inputs, not a measurement of any lunar quantity. Advisory: analysis output from a research and engineering tool, not type-approved navigation equipment and not a safety-of-life service.

Precision of the seven-parameter lunar datum (three translations, a scale and three rotations) from Earth-station ranging, with and without orbiter-to-surface-station ranges, from a real run of engine v0.40.0 on scenarios/lunar-infrastructure-frame-coestimation.toml. The Cramer-Rao sigma of the translations and rotations falls with the orbiter links (for example t_z from 0.98 m to 0.046 m); the smallest information eigenvalue rises 111-fold and the CRLB trace falls to 1.0 % (bar F3 MET). This assumes the orbit is known in the lunar axes, with its error carried by the orbiter range sigma of 1 m. MODELLED: a restricted three-body model with stated simplifications and illustrative inputs, not a measurement of any lunar quantity. Advisory: analysis output from a research and engineering tool, not type-approved navigation equipment and not a safety-of-life service.

Precision of the offsets between laser ranging, VLBI and GNSS positions of one spacecraft, against the error of the ground local tie, from a real run of engine v0.40.0 on scenarios/lunar-infrastructure-space-tie.toml (one 6.56-day arc, technique sigmas GNSS 10 m, VLBI 1 m, laser 0.1 m). With a local tie from 1 mm to 1 m, the laser-minus-GNSS translation sigma stays near 1.04 m until the tie reaches 1 m: it is limited by the measurement noise of the techniques, not by the local tie. The floor set by the tie alone is the square root of two times its sigma. MODELLED: a restricted three-body model with stated simplifications and illustrative inputs, not a measurement of any lunar quantity. Advisory: analysis output from a research and engineering tool, not type-approved navigation equipment and not a safety-of-life service.

Ledger status: MODELLED, and three bars are NOT MET. The numerics are checked against independent numpy and scipy programs; nothing is compared with a measurement of a lunar quantity, and nothing is VALIDATED. Met: the two orbit solutions are consistent (mean q 5.81 against 6 expected), and orbiter links raise the smallest datum eigenvalue about 111-fold, assuming a known orbit. Not met: the injected 3e-10 m/s2 model error is not detected (C3: the onboard solution is known to about 350 m, so about ten metres hides in its covariance); integer fixing is not achieved (1 to 3 % success at 25 dBi, and at the registered 12 dBi the problem cannot be formed); and the trace half of G3 for adding an observable family (the trace rose in 12 of 28 additions, each time because the family raised the rank). Each miss is pinned by a test. Lunar infrastructure.

Kshana Studio

Open kshana.dev/studio and the whole engine runs in your browser, compiled to WebAssembly. Nothing to install, and nothing is uploaded. The Studio has two views of the same engine, and a switch in the header moves between them, keeping the scenario, the view and any settings you changed.

The Simple view is where the Studio opens. It starts from questions (how many satellites can I see, can I trust my position fix, how long can a clock keep time, what does a jammer do to my receiver) and from a map of everything the engine can do, each area with its share of validated methods. Open a scenario and the answer comes first: one plain sentence, written for what that scenario measures, then its key figures and a chart. At most five settings are on show, the ones that change the answer most; the rest wait under Advanced settings. How this is computed explains the method, and For researchers gives the engine's own figures, the scenario file, the code to run it from Python and the citation.

Kshana Studio, Simple view, on the bundled scenario integrity-raim, engine v0.40.0 running locally. The question: does the geometry meet the alert limits (horizontal and vertical protection level)? The answer first, marked Live result: Yes, mostly: for 95.3 % of the 12 h. The receiver's error bound stayed under the alert limits (40 m horizontal and 50 m vertical) at 344 of 361 checks, and no fix was misleading. Key figures: time the fix can be trusted 95.3 %, longest gap 10 min, typical error bound 6.5 / 13 m, misleading fixes 0. Beside it, Try other settings with five of them (the range error, the two alert limits, the duration and the elevation mask) and Run again, then the folded sections Advanced settings (13 more), How this is computed (8 validated, 6 modelled) and For researchers. Below, the views of this result and the protection levels plotted against the alert limit.

The Advanced view is the full dashboard: the scenario library, five numbered steps (Choose, Set, Run, Read results, Share or export), the key figures with PASS and FAIL chips where the run states a threshold, and every panel: overview, charts, maps, replay, the engine's report and exports. One search box reaches scenarios, domains and the fields inside them, and you can pin up to four runs and compare them side by side.

The Simple view's opening screen, and the Advanced view after a run

Kshana Studio, Simple view, opening screen, titled What would you like to find out?, with the engine v0.40.0 live and, in the top bar, three links: Training debrief, Interference map and Receiver trust. Four questions: how many satellites can I see anywhere on Earth, can I trust my position fix, how long can a clock keep time without satellites, and what does a jammer do to my receiver. Below the first, its recorded result: at least 22 satellites in view at every place and 31 on average with GPS, Galileo, BeiDou and GLONASS together, a fix possible at 100 % of places and times, on a world map of satellites in view, with an Open this result button. Beside it, Everything Kshana can do: 16 areas and 139 ready-to-run scenarios, each tile with a small chart from a recorded run and its share of validated methods, and the ledger's 173 of 350 capabilities validated.

Kshana Studio, Advanced view, after a run of the bundled scenario constellation-multi-gnss-coverage (Four GNSS constellations, one map), engine v0.40.0 running locally. On the left the scenario library, 139 scenarios in 16 domains. The five steps Choose, Set, Run, Read results and Share or export, with step 4 current. Key figures: 102 satellites, availability 100 % (PASS), median position dilution of precision (PDOP) 0.95 (PASS), PDOP 95th percentile 1.105 (PASS), 31.03 satellites in view on average and 22 at the fewest. Below, the panel row with Coverage selected, the replay bar, a world map of the mean PDOP from 0.831 to 1.0853 with every satellite drawn, and the global coverage figures.

The Studio's source and its build notes are in web/README.md.

The site

The rest of kshana.dev is built from this repository's own files and engine runs: missions, capabilities, the evidence ledger, the published research and the editions.

Three pages of kshana.dev side by side. The Home hero: the name line Kshana · क्षण · the precise instant above the headline Rehearse the minute GNSS goes dark, with the mission console of a real run of engine v0.40.0 (a globe and three live charts: clock time error, carrier-to-noise density and protection level). Evidence, Published research: the six arXiv papers built on the open engine, the newest with an engine figure. Editions, Kshana Pro, the same engine, amplified: Free runs one scenario, Pro answers the programme's question.

Capabilities

One engine covers the whole failure chain, from the first jammed satellite to the last nanosecond of clock holdover. The engine has 92 scenario kinds; kshana kinds lists them and docs/SCENARIOS.md documents every field.

View the full README on GitHub

New in 0.38

What it does, and why

Ledger status

Read

Jammertest scoring

kshana jammertest import reads the published NPRA test catalogue and transmission plan as scheduled truth; jammertest score scores a receiver log per test (detection latency, missed alarms, false alarms, time to recover), as a signed evidence pack if you give a key

MODELLED: one ledger row. The bars were pre-registered before any scored run; on the JammerTest 2024 data the minimum-data rule failed in both runs (4 and 7 scorable windows against 10 required), so no bar is assessable and nothing is claimed

Jammertest

The receiver's own flags

UBX-NAV-STATUS spoofDetState, UBX-SEC-SIG and NovAtel RXSTATUS read into a per-epoch self_report and compared with Kshana's alarms (both, receiver only, Kshana only, neither); a Septentrio SBF reader and read-only --serial input

MODELLED; agreement between a receiver's detector and Kshana's is not validation

Receiver trust

More receivers and sensors

RTKLIB .pos, NovAtel OEM7, RTCM 3 MSM4/MSM7 C/N0 (from the BSD-licensed pyrtcm tables, not the RTCM text), GNSS-SDR monitor streams, an IMU log as a second sensor, a ROS 2 package, a gnss_lib_py bridge, and imu-fit for hybrid sensor parameters

MODELLED: six ledger rows; self-written fixtures only, no capture from a real receiver, IMU, GNSS-SDR run or ROS graph was read

Machine inputs

Timing and holdover tests

the holdover-test kind scores a holdover test (GNSS removed by the operator, holdover, recovery) from a measured time-error record against ITU-T masks, "measured against the mask"; linuxptp and chrony log readers; the hardware stages and the lab-attestation field

MODELLED: two ledger rows; the times are the operator's statement, not verified

Timing HIL, Hardware safety

Standards packs, LunaNet AFS, lab round trip

scored packs for DHS RPCF, IMO MSC.1/Circ.1575 and ICAO Doc 9849 Appendix F against bars stated before the run, "supports evidence for"; a NIST IR 8323r1 crosswalk; a LunaNet AFS code generator and checker; a signed pack that links a lab run's scenario, test conditions, receiver log and score

MODELLED for the packs and the round trip; the AFS code check is VALIDATED against its printed check columns (see the ledger rows)

Standards, LunaNet AFS

kshana-bench and the observatory

fixed tasks, splits and metrics for interference detection, IQ detection, holdover prediction and the optimism gap, with a sealed holdout and a static leaderboard; a reproducible daily interference product with a 24 h delay, coarse cells and no attribution

no ledger row of its own: it scores submissions, and its baselines are labelled MODELLED in the result files; against the pre-registered bars the scorer, C1 to C3 and D2 are met and three bars are NOT MET (pinned by tests): A2 (agc_k_sigma AUC 0.766 against at least 0.80 on the test split), D1 (largest gap 0.0301) and task (b) R1 (carried, not re-run); see xval/bench/RESULTS-v2.md

Bench, Observatory

Exporters

trust telemetry as Home Assistant MQTT discovery and state messages (publish only, no credentials) beside Prometheus, CEF, LEEF and OTLP

MODELLED: one ledger row

Trust telemetry

Optical link margin against time

the optical-atmosphere kind can write one seeded realisation of a site's weather as a link-margin series

MODELLED: one ledger row; one draw from the model, not the climate

Optical atmosphere

xval/jammertest-plan/fetch.sh ../jammertest-plan kshana jammertest score session.toml --catalog ../jammertest-plan/testcatalog2025.json \ --plan ../jammertest-plan/plan-tuesday-2025-09-16.json --location 1 --json

kshana scenarios/gnss-ssv-shell.toml # shell: the upper space service volume, reduced size kshana scenarios/gnss-ssv-heo.toml # trajectory: a high Earth orbit, limb medium kshana scenarios/gnss-ssv-nav-lunar.toml # navigation: an onboard filter toward the Moon kshana scenarios/gnss-ssv-formation-heo.toml # formation: relative navigation

kshana scenarios/lunar-infrastructure-od-consistency.toml kshana scenarios/lunar-infrastructure-carrier-phase.toml # quick; the scored run takes about eight minutes kshana scenarios/lunar-infrastructure-frame-coestimation.toml kshana scenarios/lunar-infrastructure-space-tie.toml kshana scenarios/lunar-infrastructure-geodesy-sensitivity.toml

Kshana PNT-resilience simulator

Readme

Rehearse the minute GNSS goes dark

What's new in 0.40

What's new in 0.39

What's new in 0.38

0.38 in depth

Jammertest scoring

The receiver's own flags

More receivers and sensors

Timing and holdover tests

Standards packs

LunaNet AFS

Lab round trip

kshana-bench

Interference observatory

Exporters

Optical link margin against time

New Studio views

Space-user navigation (gnss-ssv)

Lunar infrastructure (lunar-infrastructure)

Kshana Studio

The site

Capabilities

Details

Kshana PNT-resilience simulator

Readme

Rehearse the minute GNSS goes dark

What's new in 0.40

What's new in 0.39

What's new in 0.38

0.38 in depth

Jammertest scoring

The receiver's own flags

More receivers and sensors

Timing and holdover tests

Standards packs

LunaNet AFS

Lab round trip

kshana-bench

Interference observatory

Exporters

Optical link margin against time

New Studio views

Space-user navigation (gnss-ssv)

Lunar infrastructure (lunar-infrastructure)

Kshana Studio

The site

Capabilities

Details

More from ashfordeou

Related AI & LLM Tools MCP servers

More from ashfordeou

Related AI & LLM Tools MCP servers

Space-user navigation (`gnss-ssv`)

Lunar infrastructure (`lunar-infrastructure`)

Space-user navigation (`gnss-ssv`)

Lunar infrastructure (`lunar-infrastructure`)