# Telemetria per un CanSat: ground station, pacchetti e checksum

> Nel 2018 ho scritto la ground station di telemetria per un progetto CanSat per la competizione AIAA: pacchetti seriali con checksum, strumenti di volo in JavaFX e un file di log per ogni sessione. Cosa rifarei uguale e cosa no.

- URL: https://mojtabaamini.com/writing/cansat-telemetry
- Language: it
- Author: Mojtaba Amini, AI Software Engineer (Verona, Italy)
- Details: Sep 2026 · 6 min di lettura · Embedded · Aerospace

Un CanSat è un piccolo satellite didattico grande quanto una lattina: viene lanciato in quota e durante la discesa deve trasmettere a terra i suoi dati. Nel 2018, durante gli studi di ingegneria aerospaziale alla Sharif University of Technology, ho sviluppato la ground station di telemetria per un progetto CanSat pensato per la competizione dell'AIAA. Il codice è pubblico sul mio GitHub.

Il cuore è il formato dei pacchetti. Ogni pacchetto di telemetria arriva dalla porta seriale con una dimensione fissa di 100 byte, si apre con un valore di controllo iniziale (201) e si chiude con uno finale (254). Dentro ci sono l'identificativo della squadra, il tempo di missione, il contatore dei pacchetti, altitudine, pressione, temperatura, tensione della batteria, i dati GPS con il numero di satelliti, beccheggio e rollio, la velocità di rotazione delle pale e la direzione della telecamera.

I delimitatori e il contatore sembrano dettagli, ma sono ciò che permette di fidarsi dei dati. Un collegamento radio perde e corrompe byte: con un inizio e una fine noti il ricevitore si risincronizza, e con il contatore sa quanti pacchetti ha perso invece di interpolare in silenzio. La regola è sempre la stessa: un pacchetto che non supera i controlli si scarta e si conta, non si mostra.

La ground station, in JavaFX, riceve i pacchetti tramite la libreria jSerialComm e li mostra su strumenti pensati per chi segue il volo: un altimetro, una bussola e un orizzonte artificiale. Prima di mostrarli li scrive su un file CSV, uno per ogni sessione con data e ora nel nome. I log delle prove su un banco vincolato registrano anche accelerometri e giroscopi, quattro celle di carico, velocità dell'aria, angoli di assetto e posizioni delle superfici di comando.

Rifarei uguale la scelta di registrare tutto e subito, con i dati grezzi. Cambierei invece tre cose: un vero checksum calcolato sul contenuto del pacchetto, oltre ai valori fissi di inizio e fine; la possibilità di riprodurre un file CSV come se fosse un volo, per testare l'interfaccia senza hardware; e un formato dei pacchetti documentato e versionato, condiviso tra firmware e ground station.

Sono le stesse regole che applico oggi alla telemetria industriale, ai dati CAN delle batterie e ai dispositivi IoT: pacchetti riconoscibili, perdite contate, dati grezzi conservati. Ne parlo anche nell'articolo [dal sensore alla dashboard](https://mojtabaamini.com/writing/sensor-to-dashboard) e nella pagina sui [sistemi embedded e IoT](https://mojtabaamini.com/servizi/sistemi-embedded-iot).

Servizio correlato

- [Sistemi embedded, IoT e acquisizione dati](https://mojtabaamini.com/servizi/sistemi-embedded-iot): Firmware C/C++, sensori, CAN bus e telemetria, fino ai modelli AI sui dati raccolti.