Skip to main content

solve_with_fallback

Function solve_with_fallback 

Source
pub fn solve_with_fallback(
    precise: &[Sp3],
    broadcast: &dyn EphemerisSource,
    inputs: &SolveInputs,
    policy: StalenessPolicy,
    with_geodetic: bool,
) -> Result<SourcedSolution, FallbackError>
Expand description

Solve a receiver position, preferring precise products and falling back to broadcast ephemeris, reporting which source was used and how stale it is.

The precise path is tried first through the product-staleness selection layer (select_sp3) at the receive epoch (inputs.t_rx_j2000_s):

  • If a precise product covers the epoch ([DegradationKind::Exact]) it is used. The solve is bit-for-bit identical to solve on that SP3 (the selection layer borrows the caller’s product untouched), and the result is FixSource::Precise with zero staleness. A solve failure here is a genuine error (the data covers the epoch), returned as FallbackError::Precise, never masked by a silent broadcast re-solve.
  • If a stale-but-within-cap precise product is selected ([DegradationKind::NearestPrior]) and it actually produces a fix, the result is FixSource::Precise carrying the nonzero StalenessMetadata. If instead it cannot serve the requested epoch (its coverage ends before it, so the solve fails on missing ephemeris), broadcast produces the fix and the result is FixSource::Broadcast(BroadcastReason::PreciseDegradedUnusable), carrying the tried product’s staleness and the precise solve error. This is the “precise unavailable for this epoch” condition the fallback exists for.
  • If the precise selection is declined outright (no product set, none covering or preceding the epoch, or the nearest beyond the staleness cap), broadcast produces the fix and the result is FixSource::Broadcast(BroadcastReason::PreciseUnavailable) carrying the selection layer’s SelectionError.

A broadcast fix is therefore never substituted silently: its BroadcastReason always records why precise was not used.

policy bounds how stale a precise product may be before broadcast is preferred; a generous cap keeps precise in use across normal product latency, a zero cap forces broadcast whenever no product covers the exact epoch.