Skip to main content

Telemetry and predictions

Telemetry is what happened; predictions are what the models expect next. The console keeps the two adjacent on the same entity card so a forecast can always be read against the stored truth it should agree with, and it is explicit about which backend produced every number.

Screenshot

A selected feeder link: telemetry sparklines for SNR and utilization on the left, the predictions panel on the right showing the SNR forecast with its model tier and refresh age.

Telemetry views

Every fleet asset and link carries time-series telemetry sampled against the sim clock: utilization, capacity, latency, queue depth, SNR, and health.

  • Live mode pins the playhead to the newest stored sample; entity sparklines and fleet statistics track incoming data. A connection indicator distinguishes live, stale (no fresh samples in 90 seconds), and disconnected, so a frozen feed never reads as a quiet one.
  • Replay mode samples the stored window at the playhead; scrub and the sparklines re-evaluate at that instant. Every trend states the exact window and coverage it computed over.

Under the hood, telemetry reads come from the platform's topology projection (stepped as_of_utc reads over the stored measurement), the same store your pipeline writes to via the Telemetry API. Imported assets with time-stamped rows join the same machinery: their samples chart, trend, and aggregate exactly like fleet telemetry, labeled with their provenance.

The predictions panel

Selecting a satellite, gateway, or link exposes a Predictions tab with the forecasts that make sense for that entity: link SNR and quality, traffic and congestion, weather and rain fade, RF interference, and conjunction screening, depending on the selection.

The production SNR model

SNR forecasting is the production-grade path today. The platform serves a trained model family (snr) through the Predictions API; the console requests it per link and renders forecast, confidence, and the model tier that produced it.

Fidelity tiers are a plan feature, mapped client-side: your subscription determines which tiers the console will request.

TierIncluded inCharacter
BronzeStandard and aboveOperational margins
SilverPro and aboveEnhanced propagation modeling
GoldPro and aboveMission-critical bounds, tighter confidence
CustomEnterpriseModels trained on your fleet

The mapping lives in the console's entitlements, not in the API: the platform serves what the key allows, and the console avoids requesting tiers your plan does not include, showing an upgrade hint instead of a permission error. See Permissions and tenancy.

The keyless baseline

Guest sessions and consoles without a tenant API key do not lose predictions entirely: they fall back to a general, physics-anchored baseline endpoint that serves the SNR family only. It is a real engine (link geometry in, SNR estimate out), clearly labeled as the general baseline rather than your tenant's trained model. If no baseline endpoint is configured either, the panel says predictions are unavailable and why; it never spins forever or invents a number.

Honest labeling for everything else

Prediction domains that do not yet have a production backend behind your key render from clearly labeled illustrative stubs. A stub outlook says it is a stub in the card itself. The rule across the panel is uniform: every forecast names its source (production model and tier, general baseline, or stub), so a screenshot of the panel can never oversell what the platform computed.

Caching and freshness

Predictions refresh on 60-second time buckets, with stale-while-revalidate semantics per entity:

  • A fresh request within the current bucket reuses the cached forecast; identical questions in the same minute get identical answers.
  • When a bucket expires, the cached forecast keeps rendering (marked with its age) while a fresh one is fetched, so the panel never blanks during a refetch.
  • Forecasts older than two refresh intervals are treated as stale and replaced rather than silently served.
  • The cache is bounded; the console prefers refetching over holding unbounded history in the browser.

This is the same honesty discipline as the rest of the console: you always know when a number was computed, and a network hiccup degrades to "showing the 90-second-old forecast" instead of an empty panel.

Common workflows

TaskHow
Check a link's forecast against realityPredictions tab next to the telemetry sparkline for the same metric
Watch fleet health during a passLive mode, gateway selected, links tab
Quantify a degradation windowReplay mode, trend query over the affected window; the answer states its coverage
Get SNR forecasts as a guestThe general baseline serves SNR-family forecasts, labeled as baseline
Ask for a forecast in chatThe assistant runs the same prediction tools and cites model and tier in its insight card
Validate a link budget end to endThe link-budget validation report workflow reconciles model against telemetry

Example scenarios

Model versus telemetry disagreement. A Pro user notices the gold-tier SNR forecast for a feeder link sits 2 dB above the stored telemetry trend. Because both render side by side with their windows stated, the discrepancy is visible instead of averaged away. The anomaly investigation workflow pins the divergence onset to a pointing change, evidence the model had no way to see.

Evaluating before buying. A prospect in guest mode selects a demo link and gets a baseline SNR forecast labeled as the general physics engine. The panel's tier column shows what bronze, silver, and gold would add. Nothing pretends to be a trained tenant model before a tenant exists.