The 10 minutes before a contact window starts are probably the most consequential 10 minutes in a satellite operator's day. The pass itself might last only 8-12 minutes. If you waste 3 of them on manual status checks that could have been done beforehand — or worse, you arrive at first contact with the satellite in an unexpected mode — you've burned mission time that you won't get back until the next orbit.

We've watched operators lose entire contact windows to preventable problems: a payload in safe mode that nobody noticed before the pass, an uplink command script pointing at yesterday's TLE, a ground antenna stuck in standby because the pre-pass sequence wasn't triggered. None of these are hardware failures. They're process failures that automation fixes reliably.

What Pre-Pass Checkout Actually Covers

A well-designed pre-pass checkout sequence does three things: it validates that the spacecraft is in the expected state for the planned contact type, it validates that the ground station is configured correctly for the pass, and it confirms that the command script or data capture plan matches the current orbital geometry. All three have to pass before the contact window opens — not during it.

Spacecraft state validation typically includes checking the most recent telemetry beacon (usually received on the prior pass or via store-and-forward network) for battery state of charge, attitude control mode, payload power status, and any active fault flags. For a 6U with a 22 Wh battery, we want to confirm that the battery is above the minimum operational threshold — typically 30% state of charge — before queueing a power-intensive payload downlink session. Trying to run an X-band 50 Mbps downlink with a satellite at 18% SOC is a good way to trigger an undervoltage fault mid-pass.

Ground station validation checks antenna pointing algorithm parameters against the current TLE, verifies that the receive chain is locked and functional, and confirms that data routing is configured to deliver the downlink to the correct destination — whether that's an S3 bucket, an Azure Blob container, or an on-premise mission control server. A misconfigured data route discovered after a successful downlink pass means the data was received but went nowhere useful.

Structuring the Automation Sequence

In our implementation at Orbitvein, the pre-pass checkout sequence triggers automatically at T-12 minutes before the scheduled contact window. The sequence runs through a defined checklist and produces a green/amber/red status for each check. Green means proceed; amber means proceed with operator awareness; red means abort and page the duty operator.

The sequence typically runs in this order:

  1. T-12 min: TLE freshness check. Confirm that the TLE used for pass prediction is no older than 48 hours. If older, flag amber and attempt auto-refresh from the TLE catalog. If refresh fails, escalate to red.
  2. T-10 min: Last beacon validation. Parse the most recent beacon telemetry frame received from the spacecraft. Check battery SOC, attitude mode, and payload status against pre-defined thresholds for this contact type. A payload downlink pass has different readiness requirements than a TT&C-only housekeeping pass.
  3. T-8 min: Ground station initialization. Issue antenna pointing commands and verify slew is proceeding. Confirm RF chain is active and nominal. Verify data delivery endpoint is reachable (S3/Azure connectivity check).
  4. T-5 min: Command script validation. If the pass includes uplink commands, verify the script has been reviewed and approved in the last 24 hours. Check that command parameters are consistent with current spacecraft state (don't send a payload power-on command if the payload is already on).
  5. T-2 min: Final readiness confirmation. All checks must be green or amber with operator acknowledgment. Amber items are logged to the contact record. Red items trigger abort and operator escalation.

The key design principle: the checkout sequence should be deterministic and fast. We target a total runtime under 90 seconds for the full sequence. Any check that takes longer than 20 seconds indicates a dependency — external API, satellite beacon, antenna health endpoint — that needs a timeout and fallback policy. A checkout sequence that hangs is worse than no checkout sequence at all.

Handling Conditional Pass Types

Not all passes are created equal, and the checkout sequence has to account for this. A typical LEO operator running a 10-satellite EO constellation might have three distinct contact types:

  • Routine telemetry downlink: Low urgency, payload data collection. Checkout focuses on payload health and SOC threshold. Failure is recoverable — data can be retrieved on the next pass.
  • Command uplink pass: Higher stakes. Verification that the command sequence is correct matters more here than for downlink-only passes. We recommend requiring a second operator sign-off on the command script for any pass that modifies spacecraft configuration, not just routine telemetry commands.
  • Anomaly response contact: Highest urgency, minimum checkout time. In anomaly mode, the operator needs to reach the satellite as fast as possible. The checkout sequence for anomaly passes is abbreviated to the essentials: TLE age check, antenna initialization, and basic ground chain verification. The spacecraft state check is skipped or made advisory only — if there's an anomaly, you already know the spacecraft isn't nominal.

Having these contact types defined explicitly in your ground system means the automation knows which checks to run and which to skip. We store these as contact type templates in the scheduling system, so operators select a contact type when booking a pass and the checkout sequence applies the right checklist automatically.

Integration with the Ground Network API

For operators using a shared ground network like Orbitvein, the pre-pass checkout integrates with the network API at several points. The TLE freshness check can query the API to confirm the TLE version the station will use for pointing. The station initialization check can query the station status endpoint to verify antenna health before the pass starts. And the post-pass data delivery confirmation closes the loop — the checkout system gets a callback when data delivery to the operator's endpoint completes.

This API-driven integration is a significant advantage over proprietary single-station setups, where pre-pass checks depend entirely on local system health monitoring. When a station in the shared network has a hardware issue — a receiver card offline, an LNA fault — the network's station status system can route the pass to an alternate station with sufficient advance notice to re-run the checkout sequence without missing the contact window. In our experience, proactive rerouting based on pre-pass station health checks accounts for roughly 60% of the contact reliability improvement operators see when moving from proprietary to shared infrastructure.

Logging and Post-Pass Review

Every pre-pass checkout run should produce a structured log entry that becomes part of the contact record. The log should include: each check name, its result (pass/warn/fail), the timestamp, and the raw value that was evaluated. This isn't just for audit trail purposes — it's the fastest way to diagnose a failed or degraded contact after the fact.

When a pass delivers only 40% of the expected data volume, the first place to look is the pre-pass checkout log. Was the satellite SOC lower than expected? Did the TLE age check produce an amber? Was the payload in a non-nominal mode that didn't trigger a red? Answering these questions in 5 minutes from a structured log is a qualitatively different experience from piecing together the answer from disconnected station logs and manual telemetry review.

The satellite operations teams who build good pre-pass automation tend to build it once and then stop thinking about it — which is exactly the point. Contact windows are finite and mission time is expensive. Manual pre-pass checks are a solvable problem, and solving it once with a well-designed automation sequence is one of the highest-return investments an early-stage operator can make.