Projekt Suncatcher: Ein Prototypsatellit ist jetzt im Orbit

Project Suncatcher: Ein Prototyp-Satellit befindet sich jetzt im Orbit

Ein Prototyp-Satellit für Project Suncatcher befindet sich jetzt im Orbit. Das ist die Schlagzeile, und sie stammt aus einer einzigen Primärquelle: Googles KI-Blogbeitrag unter https://blog.google/innovation-and-ai/models-and-research/google-research/project-suncatcher-prototype, mit einem zugehörigen Zeitstempel von 2026-10-01T23:30:00.000Z.

Das ist ein kurzer Satz. Für alle, die KI- und Dateninfrastruktur betreiben, ist er außerdem die Art von Satz, die eine lange Kette an Ingenieursarbeit auslöst. Sobald Hardware im Orbit ist, wandern die interessanten Probleme von den Designdokumenten zu den Bodensystemen: zu wissen, wo sich das Objekt befindet, wann man mit ihm sprechen kann, wie man ingestiert, was es sendet, und wie man den Unterschied zwischen „nichts ist angekommen“ und „etwas ist angekommen, war aber falsch“ erkennt.

Dieser Artikel bleibt bei dem, was die Quelle tatsächlich stützt. Er spekuliert nicht über die Nutzlast, die Umlaufbahn, die Trägerrakete oder den Downlink-Plan, weil die Ankündigung diese nicht belegt. Stattdessen legt er die Arbeit am Bodensegment dar, die jeder Meilenstein der Art „Prototyp ist im Orbit“ impliziert, mit konkreten, ausführbaren Werkzeugen, die Sie anpassen können.

Was die Quelle belegt – und was nicht

Die bestätigte Aussage ist eng gefasst und es lohnt sich, sie präzise zu wiederholen: Ein Prototyp-Satellit von Project Suncatcher befindet sich im Orbit. Die Aussage wird durch eine zugängliche Primärquelle gestützt, was sie für einen einzelnen Fakt auf ein starkes Evidenzniveau hebt.

Alles unterhalb dieser Linie ist Schlussfolgerung. Die Quelle liefert uns auf den ersten Blick nicht:

• eine Objektkennung oder Katalognummer,
• Bahnelemente, Höhe, Inklination oder erwartete Lebensdauer,
• einen Frequenzplan oder ein Modulationsschema,
• irgendeine Aussage über Nutzlastfähigkeit, Rechenleistung, Energie oder Datenvolumen,
• irgendeine Leistungsaussage oder einen Benchmark,
• eine Aussage darüber, ob das Raumfahrzeug lediglich im Orbit ist oder vollständig in Betrieb genommen und gesund.

Das ist wichtig, weil der Name „Suncatcher“ eine bestimmte Geschichte nahelegt – Solarenergiegewinnung, Energieübertragung, orbitales Rechnen –, und nichts davon wird durch eine Schlagzeile belegt, die besagt, dass ein Prototyp im Orbit ist. Die ehrliche Lesart ist: Ein Meilenstein wurde erreicht, und die technischen Konsequenzen beginnen jetzt.

Warum „Im Orbit“ ein Meilenstein für die Boden-Software ist

Für ein Forschungsteam ist es üblicherweise ein Hardware- und Startmeilenstein, einen Prototyp in den Orbit zu bringen. Für die umgebende Softwareorganisation ist es der Moment, in dem eine Reihe zuvor theoretischer Schnittstellen zu lebenden Verträgen werden.

Drei Dinge ändern sich gleichzeitig:

Die Telemetriequelle wird physisch. Bis zum Start kann Telemetrie mit einem Fixture simuliert werden. Nach dem Start ist das Fixture ein Funkgerät, und die Ausfallmodi sind physisch: ein Überflug, der nie über die Elevationsmaske steigt, eine Aufzeichnung, die zu spät beginnt, ein verrauschtes Frame, das eine Längenprüfung besteht und eine Prüfsumme nicht.

Zeit wird zu einer harten Abhängigkeit. Überflugvorhersage ist eine Berechnung im Zeitbereich. Wenn die Uhr einer Bodenstation um eine Sekunde driftet, verschlechtert sich die Nachführung; wenn sie um eine Minute driftet, verpassen Sie das Zeitfenster, und es gibt keinen erneuten Versuch bis zur nächsten Umlaufbahn.

Idempotenz ist nicht länger optional. Ein Frame kann zweimal ankommen, teilweise ankommen oder beim Dekodieren fehlschlagen und eine erneute Ingestion aus einer Rohaufzeichnung erfordern. Systeme, die Ingestion als reines Anhängen behandeln, neigen dazu, stillschweigend doppelte Datensätze anzusammeln.

Nichts davon ist exotisch. Es ist die gewöhnliche Disziplin jeder Pipeline, deren vorgelagerte Quelle unzuverlässig ist. Der nützliche Schritt ist, diese Disziplin vor dem ersten Überflug aufzubauen, nicht nach der ersten Datenlücke.

Ein wiederverwendbares Bodensegment-Muster

Das folgende Muster ist bewusst generisch. Es ist kein offizielles Tooling von Project Suncatcher und setzt nichts voraus, was die Ankündigung nicht aussagt. Es ist eine Referenzimplementierung für ein kleines Bodensegment: TLE-basierte Überflugvorhersage, einen Aufzeichnungsschritt und einen strukturierten Telemetrie-Ingestion-Pfad.

Betrachten Sie es als Gerüst, das Sie Stück für Stück ersetzen, sobald echte Schnittstellendokumentation eintrifft.

Anforderungen

Bevor Sie irgendetwas installieren, bestätigen Sie Folgendes:

• Betriebssystem: eine Linux-Distribution mit einem aktuellen Paketmanager. Die folgenden Befehle gehen von einem Debian- oder Ubuntu-abgeleiteten System aus.
• Python: 3.11 oder neuer. Die Bibliothek skyfield hängt von modernem Packaging und numerischen Bibliotheken ab.
• Uhrdisziplin: ein NTP-Client wie chrony. Überflugvorhersage mit einer driftenden Uhr ist eine selbst zugefügte Wunde.
• Netzwerkzugriff: ausgehendes HTTPS zu einem öffentlichen Satellitenkatalog, damit Sie aktuelle Elementsätze abrufen können.
• Optionale SDR-Hardware: ein Empfänger der RTL-SDR-Klasse reicht aus, um den Aufzeichnungspfad Ende-zu-Ende zu belegen, bevor Sie in ein hochwertigeres Funkgerät investieren.
• Speicherplatz: genug Platz für rohe IQ-Aufzeichnungen. Diese wachsen schnell, planen Sie also die Aufbewahrung vor Ihrer ersten langen Aufzeichnung.
• Eine Satellitenidentität: ein Objektname oder eine Katalognummer von Ihrem Betreiber oder Ihr eigener Katalogeintrag. Die Ankündigung veröffentlicht keine, daher muss diese von anderer Stelle kommen.

Schritt-für-Schritt-Installation

Installieren Sie zunächst die Systempakete. Dadurch werden Python, ein Uhr-Daemon, die SDR-User-Space-Werkzeuge und ein grafischer Client zur Überflugvorhersage für die manuelle Überprüfung installiert.

sudo apt update && sudo apt install -y python3 python3-venv python3-pip chrony rtl-sdr gpredict

Bestätigen Sie, dass die Uhr diszipliniert wird, bevor Sie irgendeiner Zeitausgabe vertrauen.

chronyc tracking

Erstellen Sie eine isolierte Python-Umgebung, damit die Abhängigkeiten der Pipeline nicht mit Systempaketen kollidieren.

python3 -m venv .venv && source .venv/bin/activate

Aktualisieren Sie die Packaging-Werkzeuge innerhalb der Umgebung und installieren Sie dann die drei Bibliotheken, die die Referenzskripte verwenden: skyfield für die Bahnpropagation, requests für Katalog- und Webhook-Aufrufe und pyyaml für die Konfiguration.

pip install --upgrade pip && pip install skyfield requests pyyaml

Überprüfen Sie, dass die Umgebung korrekt aufgelöst wird. Wenn der Import eine Version ausgibt, haben Sie einen funktionierenden Propagations-Stack.

python -c "import skyfield, requests, yaml; print(skyfield.__version__)"

Erstellen Sie die Verzeichnisstruktur, die der Rest dieses Artikels annimmt. Die Trennung von Konfiguration, Daten und Protokollen hält Rohaufzeichnungen aus Ihrem Codebaum heraus und macht Aufbewahrungsrichtlinien unkompliziert.

mkdir -p suncatcher-ground/{config,data,logs}

Konfiguration

Erstellen Sie eine einzige Konfigurationsdatei. Jeder Wert, den die Quelle nicht belegt, bleibt ein ausdrücklicher Platzhalter statt eines plausibel aussehenden Standardwerts, damit niemand eine Annahme für einen Fakt hält.

cat > suncatcher-ground/config/ground.yaml <<'YAML'
station:
  name: "station-01"
  latitude_deg: 0.0        # auf Ihre Bodenstation setzen
  longitude_deg: 0.0       # auf Ihre Bodenstation setzen
  elevation_m: 0

catalog:
  tle_url: "https://celestrak.org/NORAD/elements/gp.php?GROUP=active&FORMAT=tle"
  object_name: "REPLACE-WITH-OPERATOR-SUPPLIED-NAME"

passes:
  elevation_mask_deg: 10.0
  horizon_hours: 24

capture:
  downlink_mhz: null       # NICHT veröffentlicht; aus dem ICD des Betreibers entnehmen
  sample_rate_hz: 2400000
  output_dir: "data/raw"

telemetry:
  schema_version: 1
  max_frame_bytes: 512
  alert_webhook: "https://example.invalid/hooks/ground"  # ersetzen oder auf null setzen
YAML

Schreiben Sie nun das Skript zur Überflugvorhersage. Es lädt den Katalog einmal, erstellt eine topozentrische Ansicht von Ihrer Station und tastet das nächste Zeitfenster mit fester Kadenz ab, um zu ermitteln, wann das Objekt die Elevationsmaske überschreitet. Ersetzen Sie den Objektnamen durch die Kennung, die Sie von Ihrem Betreiber erhalten haben.

# suncatcher-ground/passes.py
import yaml
from skyfield.api import load, wgs84

with open("config/ground.yaml") as fh:
    cfg = yaml.safe_load(fh)

ts = load.timescale()
url = cfg["catalog"]["tle_url"]
sats = {s.name: s for s in load.tle_file(url)}
sat = sats[cfg["catalog"]["object_name"]]

station = cfg["station"]
topos = wgs84.latlon(
    station["latitude_deg"], station["longitude_deg"], station["elevation_m"]
)
difference = sat - topos

mask = cfg["passes"]["elevation_mask_deg"]
horizon = cfg["passes"]["horizon_hours"]

for minute in range(0, horizon * 60, 1):
    t = ts.utc(ts.now().utc_datetime().replace(second=0, microsecond=0))
    t = ts.tt_jd(t.tt + minute / 1440.0)
    alt, az, _ = difference.at(t).altaz()
    if alt.degrees >= mask:
        print(f"{t.utc_iso()}  alt={alt.degrees:6.1f}  az={az.degrees:6.1f}")

Schreiben Sie als Nächstes das Ingestion-Skript. Der folgende Frame-Parser ist absichtlich ein Stub: Er erzwingt eine maximale Länge und einen Prüfsummen-Slot, aber Sie müssen verify_checksum durch das echte Verfahren aus der Schnittstellendokumentation ersetzen. Diese Funktion isoliert zu halten bedeutet, dass Sie an dem Tag, an dem das ICD eintrifft, eine Funktion ändern statt der Pipeline.

# suncatcher-ground/ingest.py
import hashlib
import json
import yaml

with open("config/ground.yaml") as fh:
    cfg = yaml.safe_load(fh)

MAX = cfg["telemetry"]["max_frame_bytes"]


def verify_checksum(frame: bytes) -> bool:
    """PLATZHALTER: durch die im Schnittstellendokument definierte Prüfsumme ersetzen."""
    if len(frame) < 5:
        return False
    body, declared = frame[:-4], frame[-4:]
    computed = hashlib.sha256(body).digest()[:4]
    return computed == declared


def parse_frame(frame: bytes) -> dict:
    if len(frame) > MAX:
        raise ValueError("Frame überschreitet die konfigurierte maximale Länge")
    if not verify_checksum(frame):
        raise ValueError("Prüfsummenfehler")
    return {
        "schema_version": cfg["telemetry"]["schema_version"],
        "length_bytes": len(frame),
        "payload_hex": frame[:-4].hex(),
        "digest": hashlib.sha256(frame).hexdigest(),
    }


if __name__ == "__main__":
    import sys

    raw = open(sys.argv[1], "rb").read()
    print(json.dumps(parse_frame(raw), indent=2))

Verwendungsbeispiele

Sagen Sie den nächsten Tag nutzbarer Überflüge voraus. Dies ist der Befehl, den Sie ausführen, bevor Sie irgendetwas anderes planen, und es ist auch der schnellste Weg, um zu bestätigen, dass Ihre Stationskoordinaten korrekt sind.

cd suncatcher-ground && python passes.py | head -n 20

Zeichnen Sie während eines Überflugs rohe IQ-Daten auf. Die Frequenz wird aus einer Umgebungsvariable gelesen, weil sie in der Ankündigung nicht veröffentlicht wird; legen Sie sie anhand der Dokumentation des Betreibers fest. Bestätigen Sie immer, dass der Dongle sichtbar ist, bevor ein zeitkritisches Fenster beginnt.

rtl_test -t

Zeichnen Sie dann auf und schreiben Sie in eine Datei mit Zeitstempel, damit wiederholte Überflüge einander nie überschreiben.

export DOWNLINK_MHZ=000.000   # aus Betreiberdokumentation festlegen
rtl_sdr -f ${DOWNLINK_MHZ}M -s 2400000 data/raw/pass_$(date -u +%Y%m%dT%H%M%SZ).iq

Lassen Sie ein Frame durch den Parser laufen, um zu bestätigen, dass sich Ihre Prüfsummenlogik gegenüber echten Bytes wie erwartet verhält.

python ingest.py data/raw/frame_0001.bin

Wenn Sie schließlich einen Webhook konfiguriert haben, senden Sie nach jedem Überflug einen Heartbeat, damit eine ausbleibende Warnung selbst eine Warnung ist. Stille Pipelines sind diejenigen, die wochenlang unbemerkt ausfallen.

# suncatcher-ground/heartbeat.py
import requests, yaml

cfg = yaml.safe_load(open("config/ground.yaml"))
url = cfg["telemetry"].get("alert_webhook")
if url:
    requests.post(url, json={"station": cfg["station"]["name"], "status": "pass_complete"}, timeout=5)

Was offen bleibt

Das Nützlichste, was ein technischer Leser aus diesem Meilenstein mitnehmen kann, ist eine klare Landkarte der Unbekannten. Die Quelle bestätigt, dass ein Prototyp im Orbit ist. Sie bestätigt nicht den Betriebsstatus, die Datenrückgabe oder irgendeine Fähigkeitsaussage. Solange keine Objektkennung und Schnittstellendokumentation existieren, ist jede Zahl in Ihrer Konfiguration – Frequenz, Modulation, Frame-Format, Überflugkadenz – ein Platzhalter, der darauf wartet, durch etwas Autoritatives ersetzt zu werden.

Das ist keine Schwäche der Ankündigung. Es ist einfach der Punkt, an dem die Grenze der öffentlichen Evidenz liegt, und sie als solche zu behandeln, hält ein Bodensegment ehrlich.

Fazit

Ein Prototyp-Satellit im Orbit ist eine Zeile Text und eine große Menge nachgelagerter Ingenieursarbeit. Die Arbeit, die folgt, ist wenig glamourös, aber machbar: disziplinierte Uhren, reproduzierbare Überflugvorhersage, Aufzeichnungen, die einander nie überschreiben, und ein Ingestion-Pfad, dessen unbekannte Teile ausdrücklich als unbekannt gekennzeichnet sind.

Die obige Referenzpipeline lässt sich in Minuten installieren und gibt nicht vor, mehr zu wissen als die Quelle. Nutzen Sie sie, um Ihr Bodensegment jetzt Ende-zu-Ende zu belegen, behalten Sie jeden nicht veröffentlichten Wert als benannten Platzhalter bei und ersetzen Sie ihn durch die echte Schnittstellenspezifikation, sobald sie existiert.