Circular two-body orbits (no J2/drag perturbations), spherical Earth, arbitrary simulation epoch (not tied to real-world sidereal time, so satellite positions here do not correspond to any actual real-world instant). Built for comparative, order-of-magnitude engineering intuition, not precision ephemeris — for a full SGP4-based propagation of the Kuiper constellation with real epochs, see the companion Python simulator in leosim/.

GPS and Kuiper each have their own independent elevation-mask model (rail: "GPS Mask & Antenna" / "Kuiper Mask & Antenna"), not one shared control. The "Simple angle" mode is a flat cutoff with no antenna modeling at all — GPS defaults to this, at 10°. The "Link-margin model" adds a simplified phased-array scan-loss term (projected-aperture approximation, gain ∝ cosⁿ of the scan angle from zenith) plus relative free-space path loss, and solves for the elevation where combined loss vs. the ideal zenith case equals a margin budget you set — Kuiper defaults to this. At each profile's default budget/exponent (13.75 dB, n=1.5 — the same starting numbers, tunable independently) this lands GPS's effective mask (~9°, if switched to link-margin mode) close to its real-world ~5-10° operational mask — but that's a coincidence of curve-fitting, not causation: GPS's real mask comes from multipath and tropospheric/ionospheric delay tolerance, a completely different mechanism than phased-array scan loss, which is exactly why GPS defaults to the simple mode instead. Kuiper's higher effective mask (~20°+), on the other hand, is exactly the mechanism this model represents, since every real LEO broadband constellation uses phased-array terminals. Neither mode models atmospheric attenuation, rain fade, or satellite-side antenna patterns.

The Link Budget tab adds absolute C/N0 (EIRP − FSPL − other loss + G/T + 228.6 dB) on top of that. GPS and Kuiper (Shell 1) are shown simultaneously, each at its own real fixed altitude and frequency with its own independently adjustable EIRP/G-T/loss/data-rate sliders — not one shared state toggled between systems. Both deliberately hold EIRP and G/T constant across elevation — no scan-loss term — so each system's own "link-limited mask" (where margin crosses zero) is a different, independent estimate from the rail's scan-loss-aware effective mask for that same system; expect them to disagree somewhat, that's the two models' different simplifications showing, not a bug. GPS's default parameters are well-documented (EIRP reverse-derived from IS-GPS-200's published −158.5 dBW minimum received power spec); this dashboard's LEO-GNSS payload's numbers now match docs/leo-vs-meo-gnss.md §5.7's own "common handheld receiver" figures exactly (EIRP +15.5 dBW, G/T −24 dB/K — deliberately the same receiver as GPS's, not a purpose-built broadband terminal's, so that the C/N0 advantage this tab computes reproduces that section's headline +10.33 dB result, not some other number) rather than the generic Ka-band phased-array antenna theory (aperture gain, typical LNA noise figure) an earlier version of this tab derived them from independently — those numbers were never reconciled with the document's own later, more carefully worked link budget until this pass, and stay fixed regardless of which real LEO constellation is selected above, since this payload is hypothetical either way. Its data rate default is similarly 750 bps, the real Kuiper-PNT nav-message rate from §11.4 (kept as the illustrative figure even when Kuiper isn't the selected constellation, since it names a specific published Amazon design, not a generic LEO figure), not the selected constellation's real, far higher broadband service rate (a different, real, but not-this-tab's scenario, and a different number for each real constellation besides). Its carrier on this tab is selectable between an L-band and an S-band reference frequency (docs/leo-gnss-design.md) rather than any real constellation's actual broadband frequency, but its EIRP/G-T defaults are not re-derived per band — the same numbers are reused at whichever frequency FSPL is computed at, since a fixed real aperture's actual gain would differ substantially between bands, same simplification §5 itself doesn't need to make (it only evaluates L-band). The "other loss" term is clear-sky only and excludes rain fade, historically the dominant real-world design driver for Ka-band links specifically — not that this tab's default scenario uses Ka-band any more.

The Ionosphere & Troposphere tab uses a single-layer thin-shell ionosphere model (fixed 350 km shell height, the classic Klobuchar (1987) assumption, also codified in IS-GPS-200) rather than a full 3D electron density profile, and a simple cosecant tropospheric mapping function (less accurate below ~15° elevation than real mapping functions like Niell (1996)). Tropospheric delay is treated as frequency-independent, which is true for refractive delay but excludes absorption lines and rain fade specific to whichever real band a system actually operates in. Kuiper is shown at the L-band and S-band reference frequencies used throughout the Kuiper-GNSS design work (docs/leo-gnss-design.md), not its real broadband carrier frequency — no chart on this dashboard uses a real constellation's own downlink frequency. VTEC and zenith tropo delay are user-adjustable illustrative values, not tied to any real date, location, or space-weather data — Kuiper's L-band iono delay is identical to GPS's by construction (same frequency), and its S-band figure follows directly from the 1/f² dispersion law regardless of the specific VTEC chosen.

The Frequency Bands tab reuses the same Doppler, ionospheric-delay, and C/N0 calculations from elsewhere, swept across carrier frequency with every other parameter (altitude, EIRP/G-T, VTEC) held fixed. Real systems typically co-design antenna gain with operating frequency — a higher-frequency system usually uses a higher-gain antenna to offset the ∝f² path-loss penalty the C/N0 chart shows — so read that chart as "impact of frequency alone, other things equal," not a prediction of how a real system's link budget would change if its carrier were simply retuned.

The GNSS Accuracy Budget tab is a hypothetical design exercise, not a real system — see docs/leo-gnss-design.md for the full rationale. GPS's clock/ephemeris, ionosphere-free residual, post-model tropospheric residual, and multipath terms are fixed illustrative allowances, not re-derived from other tabs — in particular, the tropospheric term here is a small (cm-level) post-model residual, deliberately not the same quantity as the Atmosphere tab's multi-meter raw zenith delay, since real receivers (single- or dual-frequency alike) correct troposphere with a standard blind model and only the residual belongs in a UERE budget; using the raw delay here would swamp every other term and hide the comparisons this tab exists to show. GPS's ionosphere term is the exception that does reuse this dashboard's own atmosphere model directly, since GPS here has no dual-frequency correction to apply. Kuiper-GNSS's clock term comes from a simplified holdover model (Δr = c·σ_y(τ)·holdover time) that is explicitly not a rigorous Allan-variance derivation — the OCXO grade uses one illustrative flat σ_y, while the CSAC grade uses Microchip's real SA.45s/Space CSAC-SA65 datasheet, log-log interpolated across its four published points rather than a single flat number (a flat τ=1s value overstated CSAC's long-holdover error by roughly an order of magnitude, caught by the Node smoke test before publishing). The tracking-noise term uses a standard non-coherent DLL discriminator formula (Van Dierendonck, Fenton & Ford 1992) evaluated at a fixed narrow-correlator/loop-bandwidth/integration-time configuration — none of those three are exposed as sliders. That tracking-noise term is also where the dual-L-vs-L+S frequency-plan choice actually acts (via the ionosphere-free amplification factor A(γ)); it's real but small enough to be invisible in the total-UERE chart, so it's shown on its own in the second chart instead. The ambiguity-resolution "speedup" stat is a ratio of each system's own 45°-elevation angular rate (the same physical quantity the Multipath tab's fade period depends on), not an absolute convergence-time prediction. The cold-start acquisition card models only the Doppler dimension of the acquisition search (code-phase search is unaffected by altitude); the assisted-search window (±500 Hz) is an illustrative round figure, not derived from a specific ISL message-format budget.