Two products sit on one spacecraft registry. Telemetry Hub is the data plane. Mission Control is the control plane. Neither requires the other to run, and operators rarely buy only one.
Receives transport frames from your ground stations, validates and decodes them against your mission dictionary, and stores both the decoded parameters and the untouched frame. Answers queries over parameter history and keeps the raw record retrievable for as long as you need it.
Owns the operational picture: contact windows, uplink command queues, downlink priorities, alert rules and the people allowed to act on them. Built for operators who cannot afford a lost pass to go unnoticed.
The division is deliberate. Data handling and operational control have different failure modes, different audit requirements and different on-call rotations, and merging them into one surface makes both harder to reason about.
| Capability | Telemetry Hub | Mission Control |
|---|---|---|
| Ground station ingest | Core | Reads pass state from Hub |
| Frame validation and decoding | Core | — |
| Parameter history and queries | Core | Dashboard views over Hub |
| Object storage export | Core | — |
| Contact window computation | Element upload | Core |
| Uplink command queue and approval | — | Core |
| Downlink priority per spacecraft | Storage tiering | Core |
| Threshold and gap alerting | Rule evaluation | Core |
| Roles, grants, audit log | Service accounts | Core |
| Data retention | 90 days included, extendable | Configuration only |
Telemetry without a plan is a filing cabinet. A plan without telemetry is a spreadsheet. The products are useful apart and coherent together.
Every spacecraft is described once: its COSPAR identifier, its buses, the APIDs it emits, the parameters those APIDs carry and their units, the elevation masks it is flown against and the ground stations it can reach. Telemetry Hub resolves incoming packets against that description. Mission Control computes windows against it. A change to an APID map is a change in one place.
Telemetry timestamps are not the moment Helion received a frame. They are the spacecraft clock value carried inside the frame, corrected by the offset Helion maintains per spacecraft and per station. The receive time is kept alongside it, never instead of it. When an operator compares two spacecraft against a thermal event, both timelines refer to the same instant.
Helion is a hosted service. There is nothing to install on the spacecraft, and nothing to install on the station beyond an outbound stream.
Your station opens an outbound TLS connection to a Helion ingest endpoint. No inbound firewall rules on your side, no VPN, no SSH. Station credentials are scoped to the spacecraft they are authorised to send.
Register the bus, the APID map and the parameters. Helion validates incoming packets against it immediately, which turns a misconfigured map into an error at the first pass rather than a silent gap in a month of data.
Upload elements, choose stations, set the elevation mask. Contact windows appear with acquisition, loss of signal and usable duration, recomputed whenever the elements change.
Most teams start with Telemetry Hub because the pain is immediate and the data is already flowing. Mission Control tends to follow once the archive is trusted.