Scenario A — “Access improved but downlink got worse”

Core idea: necessary vs sufficient.

• Access is primarily geometry: masks, LOS, FOV, pass timing.
• Downlink throughput is geometry × link margin × schedule feasibility × duty cycle.

Structured reasoning

• If access improved, something geometry-related loosened: lower elevation mask, wider FOV, different pointing rule, better phasing.
• If data got worse, the bottleneck is likely operational or comms: reduced $C/N_0$, stricter MODCOD, pointing loss, power constraint, scheduling conflicts.

Dominant assumption check

Ask whether your link model assumed:

• constant atmospheric loss (no weather / rain fade),
• static modulation/coding (no adaptive link),
• no pointing loss (perfect antenna alignment),
• no contention (no schedule conflicts / no duty cycle cap).

Mitigation

Promote usable downlink into an explicit gate: count a window only if $C/N_0 \ge$ threshold and the scheduler can allocate it.

Scenario B — “What assumption dominates your coverage results?”

Core idea: dominance is discovered by perturbation.

You test one assumption at a time and measure metric sensitivity:

• min elevation mask
• FOV half-angle
• range gate
• sunlit requirement
• slew / duty-cycle constraints
• coarse $\Delta t$ / refinement logic

def dominance_sweep(base_cfg, perturbations, metric_fn):
    """
    perturbations: list of (name, apply_fn) where apply_fn(cfg, frac)->cfg
    metric_fn(cfg)->float
    """
    results = []
    for name, apply_fn in perturbations:
        for frac in (-0.1, +0.1):
            cfg2 = apply_fn(dict(base_cfg), frac)
            m = metric_fn(cfg2)
            results.append((name, frac, m))
    return results

# Example: elevation mask dominance
perturbations = [
    ("min_el_deg", lambda cfg, f: cfg | {"min_el_deg": cfg["min_el_deg"]*(1+f)}),
    ("rho_max_km", lambda cfg, f: cfg | {"rho_max_km": cfg["rho_max_km"]*(1+f)}),
    ("fov_half_deg", lambda cfg, f: cfg | {"fov_half_deg": cfg["fov_half_deg"]*(1+f)}),
]

Scenario C — “What if LTAN constraint changes?”

Core idea: LTAN changes are not cosmetic; they shift illumination and operations.

LTAN controls:

• lighting geometry,
• eclipse phase relative to passes,
• thermal / power timing.

So changing LTAN shifts:

• detectability windows (sunlit gating),
• power budget timing,
• sometimes “good access” but “bad detection.”

Domain coupling

• F.4 sets plane/timing intent,
• F.7 creates crossing windows,
• F.8 filters detectability via illumination,
• F.10 turns feasible intervals into schedules and mission outputs.

Scenario D — “How do you scale to 30,000 objects?”

Core idea: scaling is prioritization, not brute force.

Brute force wastes compute proving “no event.” The scalable pattern is:

Pipeline (words)

• Regime filter: skip objects clearly outside your tracker’s regime (altitude/inclination bands).
• Coarse screening: relaxed range + relaxed FOV on coarse $\Delta t$.
• Rank: risk score or priority score (uncertainty growth, mission interest, proximity).
• Refine only top set: smaller $\Delta t$ + boundary solving.
• Store events: intervals + summary metrics, not dense samples.

def scalable_screen(objects, trackers, cfg):
    # 1) cheap filters
    objs = regime_filter(objects, cfg)

    # 2) coarse screen → sparse candidates
    candidates = coarse_candidate_windows(objs, trackers, cfg)

    # 3) rank and refine only a small subset
    ranked = rank_candidates(candidates, cfg)
    refine_set = ranked[:cfg["N_refine"]]

    # 4) full-fidelity evaluation only here
    events = refine_and_extract_intervals(refine_set, cfg)
    return events

Scenario E — “What happens if J2 is included?”

Core idea: this is a horizon + metric decision.

Without $J_2$ you get a plane that is “too stable.” With $J_2$ you get:

• RAAN precession,
• LTAN drift,
• long-term lighting shift,
• revisit pattern changes.

Rule-of-thumb

• For very short horizons, $J_2$ may be second-order.
• For multi-day horizons or LTAN-sensitive missions, $J_2$ becomes first-order.

Scenario F — “What if $\Delta V$ is applied at the ascending node?”

Core idea: local maneuver ≠ local effect.

Depending on $\Delta V$ direction:

• normal component → plane change efficiency
• tangential → semi-major axis / period shift
• radial → argument of latitude / timing shift

Operationally, any maneuver can change:

• next node timing,
• illumination phasing,
• ground track alignment,
• revisit cadence,
• scheduler contention.

Scenario G — “Why did access windows shift when I didn’t change physics?”

Most often: frame consistency or time-tag consistency, not real physics.

Common culprits:

• mixing TEME / ECI / ECEF inconsistently,
• applying Earth-fixed station constraints using inertial vectors directly,
• timezone / UTC conversion errors,
• inconsistent ephemeris sampling alignment.

Scenario H — “What breaks first when $\Delta t$ is coarse?”

Short crossings can occur between samples → you miss events, undercount duration, or distort boundaries.

Mitigation pattern (industry-standard)

• coarse scan to find candidates
• fine scan only inside candidates
• optional boundary solving (root find) for precise entry/exit

def boolean_to_intervals(ts, mask):
    intervals = []
    inside = False
    t0 = None
    for t, m in zip(ts, mask):
        if m and not inside:
            inside, t0 = True, t
        elif (not m) and inside:
            intervals.append((t0, t))
            inside, t0 = False, None
    if inside and t0 is not None:
        intervals.append((t0, ts[-1]))
    return intervals

Scenario I — “How do I validate a Python pass predictor properly?”

Validation is not a plot. It is a layered argument.

Cross-tool comparison

Compare AOS/LOS/max-elevation with STK or Orekit for selected cases.

Analytical sanity checks

Check monotonic trends: higher elevation masks reduce duration; higher altitude increases footprint, etc.

Regression tests

Maintain a set of “golden” cases (TLE + station + expected events) and rerun after code changes.

Edge-case tests

Equatorial, polar/SSO, high-eccentricity, dateline/polar station cases.

Scenario J — “Pointing access exists, but tracking performance collapses”

Often actuator saturation + estimation coupling.

When actuators saturate:

• control authority caps,
• tracking error grows,
• integrators wind up and rebound after saturation clears.

F.12 discipline

When “geometry says yes but performance says no,” check:

• actuator saturation logs,
• anti-windup handling,
• pointing rate feasibility inside the window.

Scenario K — “My filter is stable… until high dynamics”

Often observability and tuning, not “missing equations.”

Failure triggers:

• biases unobservable because the system never excites states,
• $Q/R$ mis-tuned (covariance collapse or blow-up),
• outliers not gated,
• dropout handling not robust.

F.12 discipline

• inspect innovations and residual distributions,
• apply gating (NIS checks),
• verify excitation: do you have enough motion to separate bias from rate?