The operational picture for a small satellite operation. Contact windows computed from your elements, uplink commands queued with approval, downlink priority per spacecraft, and alert rules that fire on engineering values rather than on log lines.
A schedule is a set of windows with a start, an end and a usable arc. Everything in Mission Control is built around computing those windows honestly.
Upload a set of orbital elements — two-line elements, an CCSDS OEM file, or an ephemeris in the formats your propagator already produces. Helion propagates the orbit, computes the antenna look angles against each station's latitude, longitude and elevation, and reports the interval where the elevation mask is satisfied.
Three numbers come out of that computation for every pass: acquisition of signal, loss of signal, and the usable duration between them. The margin above the mask at the closest approach is reported alongside, because a pass that clears the mask by four degrees is a different pass from one that clears it by thirty.
When two spacecraft are visible from the same station at the same time, the station cannot serve both at full rate. Mission Control surfaces the overlap explicitly, ranks the candidates by downlink priority and by how long the other option would have to wait, and leaves the decision with the operator. Silent priority resolution is not offered, because the trade-off usually depends on which spacecraft is more tolerant of a delayed pass.
A pass that passed without downlink is recorded as a missed pass with the reason: the station did not connect, the acquisition failed, the spacecraft was not commanded, or the pass was intentionally skipped. The reason drives the alert rule, so a configuration mistake alerts differently from a hardware fault.
A command is an object with an author, an approval state and a delivery attempt. Nothing reaches the spacecraft without passing through the queue.
The command is defined against a spacecraft and a command dictionary: an identifier, a payload, a timeout and a criticality flag. It sits in draft until submitted. Drafts are private to their author.
Critical commands require a second operator to approve. The approver cannot be the author. Every approval is recorded with a timestamp and the identity of the approver, and the command becomes eligible for the next window.
The command is attached to a contact window. Helion holds it until acquisition of signal and releases it inside the window, with the configured pre-transmission lead time applied so the command lands after the spacecraft has stabilised.
Transmission is attempted with a bounded retry count. The attempt history, the round-trip time and the acknowledgement status are recorded against the command. A command that is not acknowledged before the window closes is marked expired, not sent.
Where the spacecraft returns a verification packet for the command, the verification is matched to the command by correlation identifier. The operator sees confirmed, unverified or rejected, with the verification packet attached.
A command that did not make its window is expired and can be rescheduled against a later window without re-authoring. Expired commands are retained in the log; they are never deleted silently.
Rules are written against decoded parameters with units attached, evaluated on a rolling window, and delivered through channels that reach a human.
Alerts route to email, to a webhook, or to a chat integration. Routing is per rule, so a battery warning can go to the operations channel while a pass failure goes to the person on call. Every alert records its evaluation, its state change and its delivery attempts.
A rule can escalate: if it stays unacknowledged for fifteen minutes, it is re-routed to a second recipient group. Acknowledgement is explicit and is written to the audit log, because the question that matters after an anomaly is not whether the alert fired but who saw it.
Four roles out of the box, with grants scoped per spacecraft. The point is not the role names but what each one is allowed to do.
| Role | View telemetry | Author commands | Approve critical | Manage access | Change rules |
|---|---|---|---|---|---|
| Owner | Yes | Yes | Yes | Yes | Yes |
| Operator | Yes | Yes | Yes | No | Yes |
| Viewer | Yes | No | No | No | No |
| Automation | Scoped | Pre-approved set | No | No | No |
Every operator action is written to an append-only log: sign-ins, role changes, command authoring, approval, transmission, rule edits, exports and deletions. Each entry carries the actor, the action, the target, the timestamp in UTC and the request identifier, so an export of the log can be reconciled against an API call log.
Automation uses scoped tokens rather than operator credentials. A token carries an explicit list of permitted actions and an expiry, and it can be limited to a single spacecraft. Token creation and revocation are themselves audited, and a token cannot approve a critical command.
Mission Control is designed to be driven by software as much as by people, because most small operations already run their ground segment from scripts.
Windows, commands, rules and grants are all available through the API. Idempotency keys on writes, cursor pagination on reads, and a versioned path so a breaking change is never silent.
Pass events, command transitions and alert state changes are delivered as signed webhooks with a retry ladder and a replay window. Payloads are versioned alongside the API.
The contact window catalogue exports as CSV and JSON on a schedule, so an existing planning tool can read it, or a print of the week can go to the wall of the room where the passes are actually watched.
Bring your elements and your station list. We will compute a week of windows and show you the overlap before you commit.