Projet Suncatcher : un satellite prototype est maintenant en orbite

Projet Suncatcher : un satellite prototype est désormais en orbite

Un satellite prototype du Projet Suncatcher est désormais en orbite. C’est le titre, et il provient d’une source primaire unique : l’article de blog IA de Google à l’adresse https://blog.google/innovation-and-ai/models-and-research/google-research/project-suncatcher-prototype, avec un horodatage associé de 2026-10-01T23:30:00.000Z.

C’est une phrase courte. C’est aussi, pour quiconque exploite une infrastructure d’IA et de données, le genre de phrase qui déclenche une longue chaîne de travail d’ingénierie. Une fois le matériel en orbite, les problèmes intéressants migrent des documents de conception vers les systèmes sol : savoir où se trouve l’objet, quand vous pouvez communiquer avec lui, comment vous ingérez ce qu’il envoie, et comment vous faites la différence entre « rien n’est arrivé » et « quelque chose est arrivé, mais était erroné ».

Cet article s’en tient à ce que la source étaye réellement. Il ne spécule pas sur la charge utile, l’orbite, le lanceur ou le plan de liaison descendante, car l’annonce n’établit pas ces éléments. Ce qu’il fait à la place, c’est exposer le travail de segment sol qu’implique tout jalon « un prototype est en orbite », avec des outils concrets et exécutables que vous pouvez adapter.

Ce que la source établit — et ce qu’elle n’établit pas

L’affirmation vérifiée est étroite et mérite d’être reformulée précisément : un satellite prototype du Projet Suncatcher est en orbite. L’affirmation est étayée par une source primaire accessible, ce qui lui confère un niveau de preuve solide pour un fait isolé.

Tout ce qui se trouve sous cette ligne relève de l’inférence. La source ne nous donne pas, à première vue :

• un identifiant d’objet ou un numéro de catalogue,
• des éléments orbitaux, une altitude, une inclinaison ou une durée de vie attendue,
• un plan de fréquences ou un schéma de modulation,
• toute déclaration sur la capacité de la charge utile, la puissance de calcul, l’énergie ou le volume de données,
• toute affirmation de performance ou tout benchmark,
• une déclaration indiquant si le véhicule spatial est simplement en orbite ou entièrement mis en service et en bon état.

Cela compte parce que le nom « Suncatcher » invite à un récit spécifique — collecte solaire, transmission d’énergie par faisceau, calcul orbital — et rien de tout cela n’est établi par un titre qui annonce qu’un prototype est en orbite. La lecture honnête est la suivante : un jalon a été atteint, et les conséquences d’ingénierie commencent maintenant.

Pourquoi « en orbite » est un jalon pour le logiciel sol

Pour une équipe de recherche, mettre un prototype en orbite est généralement un jalon matériel et de lancement. Pour l’organisation logicielle qui l’entoure, c’est le moment où un ensemble d’interfaces jusque-là théoriques deviennent des contrats actifs.

Trois choses changent en même temps :

La source de télémétrie devient physique. Avant le lancement, la télémétrie peut être simulée avec un banc de test. Après le lancement, le banc de test est une radio, et les modes de défaillance sont physiques : un passage qui ne s’élève jamais au-dessus du masque d’élévation, une capture qui démarre en retard, une trame bruitée qui passe un contrôle de longueur et échoue à une somme de contrôle.

Le temps devient une dépendance stricte. La prédiction de passage est un calcul dans le domaine temporel. Si l’horloge d’une station sol dérive d’une seconde, le suivi se dégrade ; si elle dérive d’une minute, vous manquez la fenêtre et il n’y a pas de nouvelle tentative avant l’orbite suivante.

L’idempotence cesse d’être facultative. Une trame peut arriver deux fois, arriver partiellement, ou échouer au décodage et nécessiter une réingestion à partir d’une capture brute. Les systèmes qui traitent l’ingestion en ajout seul tendent à accumuler silencieusement des enregistrements en double.

Rien de tout cela n’est exotique. C’est la discipline ordinaire de tout pipeline dont l’amont n’est pas fiable. Le geste utile consiste à mettre en place cette discipline avant le premier passage, pas après la première lacune de données.

Un modèle de segment sol réutilisable

Le modèle ci-dessous est délibérément générique. Il ne s’agit pas d’outillage officiel du Projet Suncatcher, et il ne suppose rien que l’annonce n’énonce pas. C’est une implémentation de référence pour un petit segment sol : prédiction de passage basée sur les TLE, une étape de capture et un chemin structuré d’ingestion de télémétrie.

Considérez-le comme un échafaudage que vous remplacez pièce par pièce à mesure que la documentation d’interface réelle arrive.

Prérequis

Avant d’installer quoi que ce soit, confirmez les éléments suivants :

• Système d’exploitation : une distribution Linux avec un gestionnaire de paquets à jour. Les commandes ci-dessous supposent un système dérivé de Debian ou Ubuntu.
• Python : 3.11 ou version ultérieure. La bibliothèque skyfield dépend d’un packaging moderne et de bibliothèques numériques.
• Discipline d’horloge : un client NTP tel que chrony. La prédiction de passage sur une horloge qui dérive est une blessure auto-infligée.
• Accès réseau : HTTPS sortant vers un catalogue public de satellites afin de récupérer les jeux d’éléments courants.
• Matériel SDR facultatif : un récepteur de classe RTL-SDR suffit pour valider le chemin de capture de bout en bout avant d’investir dans une radio de gamme supérieure.
• Disque : assez d’espace pour les captures IQ brutes. Elles augmentent vite, donc planifiez la rétention avant votre première longue capture.
• Une identité de satellite : un nom d’objet ou un numéro de catalogue fourni par votre opérateur ou votre propre entrée de catalogue. L’annonce n’en publie aucun, donc cela doit venir d’ailleurs.

Installation étape par étape

Commencez par installer les paquets système. Cela installe Python, un démon d’horloge, les outils SDR en espace utilisateur et un client graphique de prédiction de passage pour vérification manuelle.

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

Confirmez que l’horloge est disciplinée avant de faire confiance à une quelconque sortie temporelle.

chronyc tracking

Créez un environnement Python isolé afin que les dépendances du pipeline n’entrent pas en conflit avec les paquets système.

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

Mettez à niveau les outils de packaging dans l’environnement, puis installez les trois bibliothèques utilisées par les scripts de référence : skyfield pour la propagation orbitale, requests pour les appels au catalogue et au webhook, et pyyaml pour la configuration.

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

Vérifiez que l’environnement se résout correctement. Si l’import affiche une version, vous disposez d’une pile de propagation fonctionnelle.

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

Créez l’arborescence de répertoires que le reste de cet article suppose. Séparer la configuration, les données et les journaux garde les captures brutes hors de votre arborescence de code et simplifie les politiques de rétention.

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

Configuration

Créez un unique fichier de configuration. Chaque valeur que la source n’établit pas est laissée comme un espace réservé explicite plutôt qu’une valeur par défaut d’apparence plausible, afin que personne ne prenne une hypothèse pour un fait.

cat > suncatcher-ground/config/ground.yaml <<'YAML'
station:
  name: "station-01"
  latitude_deg: 0.0        # set to your ground station
  longitude_deg: 0.0       # set to your ground station
  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       # NOT published; take from the operator's ICD
  sample_rate_hz: 2400000
  output_dir: "data/raw"

telemetry:
  schema_version: 1
  max_frame_bytes: 512
  alert_webhook: "https://example.invalid/hooks/ground"  # replace or set null
YAML

Écrivez maintenant le script de prédiction de passage. Il charge le catalogue une fois, construit une vue topocentrique depuis votre station et échantillonne la prochaine fenêtre à une cadence fixe pour déterminer quand l’objet franchit le masque d’élévation. Remplacez le nom de l’objet par l’identifiant obtenu auprès de votre opérateur.

# 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}")

Écrivez ensuite le script d’ingestion. Le parseur de trames ci-dessous est intentionnellement une ébauche : il impose une longueur maximale et un emplacement pour une somme de contrôle, mais vous devez remplacer verify_checksum par le véritable schéma issu de la documentation d’interface. Garder cette fonction isolée signifie que le jour où l’ICD arrive, vous modifiez une fonction au lieu du 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:
    """PLACEHOLDER: replace with the checksum defined in the interface document."""
    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 exceeds configured maximum length")
    if not verify_checksum(frame):
        raise ValueError("checksum mismatch")
    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))

Exemples d’utilisation

Prédisez la prochaine journée de passages utilisables. C’est la commande à exécuter avant de planifier quoi que ce soit d’autre, et c’est aussi le moyen le plus rapide de confirmer que les coordonnées de votre station sont correctes.

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

Capturez les IQ bruts pendant un passage. La fréquence est lue depuis une variable d’environnement parce qu’elle n’est pas publiée dans l’annonce ; définissez-la à partir de la documentation de l’opérateur. Confirmez toujours que le dongle est visible avant une fenêtre critique en temps.

rtl_test -t

Ensuite, capturez en écrivant dans un fichier horodaté afin que les passages répétés ne s’écrasent jamais les uns les autres.

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

Faites passer une trame dans le parseur pour confirmer que votre logique de somme de contrôle se comporte comme prévu face à de vrais octets.

python ingest.py data/raw/frame_0001.bin

Enfin, si vous avez configuré un webhook, envoyez un signal de vie après chaque passage afin qu’une alerte manquante soit elle-même une alerte. Les pipelines silencieux sont ceux qui échouent pendant des semaines sans être remarqués.

# 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)

Ce qui reste ouvert

La chose la plus utile qu’un lecteur technique peut retirer de ce jalon est une carte claire des inconnues. La source confirme qu’un prototype est en orbite. Elle ne confirme ni statut opérationnel, ni retour de données, ni aucune affirmation de capacité. Tant qu’un identifiant d’objet et une documentation d’interface n’existent pas, chaque nombre de votre configuration — fréquence, modulation, format de trame, cadence des passages — est un espace réservé en attente d’être remplacé par quelque chose de faisant autorité.

Ce n’est pas une faiblesse de l’annonce. C’est simplement là où se situe la frontière des preuves publiques, et c’est la traiter comme telle qui garde un segment sol honnête.

Conclusion

Un satellite prototype en orbite, c’est une ligne de texte et une grande quantité d’ingénierie en aval. Le travail qui suit est peu glamour mais abordable : horloges disciplinées, prédiction de passage reproductible, captures qui ne s’écrasent jamais entre elles et un chemin d’ingestion dont les parties inconnues sont explicitement étiquetées comme inconnues.

Le pipeline de référence ci-dessus s’installe en quelques minutes et ne prétend pas en savoir plus que la source. Utilisez-le pour valider votre segment sol de bout en bout dès maintenant, conservez chaque valeur non publiée comme un espace réservé nommé, et intégrez la spécification d’interface réelle dès qu’elle existe.