Sottosistema di telecomunicazione UHF e protocollo di comunicazione per nanosatelliti modulari Prof. Leonardo Reyneri Prof. Claudio Sansoè Candidato: Antonio ARU Buongiorno, sono Antonio Aru, presento una tesi dal titolo Sottosistema di telecomunicazione UHF e protocollo di comunicazione per nanosatelliti modulari sviluppata nell’ambito del progetto Aramis del Politecnico di Torino

Panoramica Introduzione Protocollo complessivo proposto Classe dei nanosatelliti AraMiS Sistema GENSO (ESA) Protocollo radioamatoriale AX.25 Protocollo complessivo proposto Considerazioni iniziali Funzionamento Analisi delle prestazioni On-Board Radio Frequency module e test Hardware Implementazione del protocollo del livello data-link Test di laboratorio Questa discussione inizierà con una visione generale della classe dei nanosatelliti Aramis, successivamente verrà introdotto il sistema GENSO, quindi i protocolli radioamatoriali. …

AraMiS (POLITO) OBC and TT&C Tile Utilizzo: in orbite LEO (600 – 800 km) Architettura: modulare (tile) Tile Payload OBC and TT&C Tile 437 MHz, 9600 bps 2.4 GHz, 500 kbps Aramis è un progetto nato nel 2006 nel politecnico di Torino dopo l’esperienza del nanosatellite picpot. L’utilizzo previsto è per le orbite LEO. ARAMIS introduce una architettura modulare basata su elementi chiamati tile di cui possiamo vedere un esempio in figura. Le tile sono i moduli che sostanzialmente costituiscono i diversi sottosistemi che compongono il satellite e sono progettati per essere collocati nelle facce esterne, lasciando la parte interna vuota, cioè pronta per accogliere il payload definito dal committente. Per quanto riguarda il sottosistema di comunicazione, esso è costituito di due sistemi completamente indipendenti e ridonanti, nelle bande radioamatoriali a 437 MHz e a 2.4 GHz. Il primo sottosistema, quello a 437 MHz, è pensato per essere compatibile con il sistema GENSO, che vedremo di seguito, ed è quello su cui si concentra questa tesi.

Progetto GENSO (Global Educational Network for Satellite Operations) Scopo: estendere ad ogni Mission Controller l’accesso al proprio satellite anche quando questo non è direttamente in visibilità, attraverso la disponibilità di un network di ground station radioamatoriali remote Il sistema GENSO consiste di tre distinte componenti: Mission Control Client Ground Station Server Authentication Server GENSO nasce nel 2006 ed è coordinato dall’ESA. Ha lo scopo di consentire ai diversi Mission Controller che partecipano al programma, l’accesso al proprio satellite anche quando questo non è direttamente in visibilità, attraverso la disponibilità di un network di ground station radioamatoriali remote. Consiste di tre distinte componenti che possono interagire tra loro via Internet: il Mission Control Client, che è l’applicazione in esecuzione nel Mission Controller che vuole usufruire del servizio il Ground Station Server, che è l’applicazione in esecuzione nella generica stazione radioamatoriale che vuole offrire il proprio servizio ed infine l’Authentication Server, gestito dagli amministratori di GENSO, che ha il compito di autenticazione tra i due precedenti. Dato che il satellite deve interfacciarsi con i radioamatori, ci si è chiesti qual è il protocollo da loro utilizzato per le comunicazioni satellitari al quale adeguarci per il canale radio.

Indagine protocolli radioamatoriali 1962 Oscar1 e Oscar2 (beacon cw) 1962 Oscar3 (transponder lineare) 1974 Amsat-Oscar7 (RTTY AFSK) 1983 Amsat-Oscar10 (computer-to-computer BPSK a 400 bps) 1986 F0-12 (BBS PSK) Dal 1990 in poi: affermazione del protocollo AX.25 con modulazione prima AFSK a 1200 bps poi FSK a 9600 bps Transceiver + TNC (Terminal Node Controller) Dato che si deve essere compatibili con i radioamatori ci si è chiesti qual è il protocollo da loro maggiormente utilizzato per le comunicazioni satellitari. A tal fine si è condotta una ricerca dalla quale è emerso che questo è il protocollo AX.25 con modulazione FSK e data-rate 9600 bps. Vediamo un po’ più da vicino in cosa consiste il protocollo ax.25

AX.25 Permette: il trasferimento di pacchetti di dati incapsulati in frame connectionless per la ricetrasmissione di singoli frame (sola rilevazione degli errori sul frame) connected (frammentazione e recupero d’errore); Frame I: Il protocollo ax.25 permette il trasferimento di pacchetti di dati incapsulati in frame. Esso offre la possibilità di funzionare in modalità connectionless, per la ricetrasmissione di singoli frame e in tal caso effettua la sola rilevazione degli errori sul frame, oppure in modalità connected, e in tal caso gestisce anche le operazioni di frammentazione dei dati e di recupero dei frame corrotti. Il frame utilizzato nel protocollo ax.25 è quello in figura dove possiamo riconoscere: il campo FLAG che con la sua particolare sequenza indica al ricevitore quando è terminato un frame e ne sta iniziando un altro il campo Address che contiene gli indirizzi mittente e destinazione il campo Control che contiene i numeri di sequenza PID che nel caso connectionless viene fissato ad un valore predefinito Information contiene i dati di payload fino a 255 B FCS contiene il codice per il controllo dell’errore Ci si è resi conto che la modalità connected, all’attuale stato di sviluppo del sistema GENSO appare non totalmente compatibile. Si è quindi deciso di realizzare la comunicazione tra ground station e satellite utilizzando il protocollo ax.25 in modalità connectionless.

Architettura del sistema su modello a livelli protocollari In questa slide viene mostrata l’architettura del sistema di comunicazione mappata su una rappresentazione a livelli protocollari. Si osserva come la generica Ground Station radioamatoriale e l’interfaccia radio del satellite, chiamata On-Board Radio Frequency module, comunichino tra loro secondo le funzioni di livello data-link dato che utilizzano l’ax.25 connectionless. Di conseguenza il Mission Controller e l’OBC del satellite comunicano tra loro virtualmente secondo un protocollo definito ad-hoc che illustriamo di seguito.

Architettura complessiva del sistema Questo protocollo è stato sviluppato per essere compatibile con l’architettura complessiva mostrata in questa slide. Il segmento di Terra è definito da GENSO e come già visto è composto da una Mission Controller che interagisce via Internet con la generica ground station radioamatoriale remota aderente al sistema GENSO. Poi sul satellite consideriamo: l’On-Board Radio Frequency module che è l’interfaccia radio che deve comunicare direttamente con la generica ground station radioamatoriale. L’OBC nel quale sono in esecuzione i software che implementano il TelemetryCommandProcessor e l’HousekeepingProcessor, dove il TelemetryCommandProcessor ha i compiti di leggere, interpretare ed eseguire i comandi ricevuti in uplink, inserire i dati in memoria e generare e avviare le trasmissioni dei dati in downlink l’HousekeepingProcessor è responsabile di raccogliere le misure dai vari sensori distribuiti nel satellite e inserirli in memoria. Consideriamo infine un certo numero di periferiche, ovvero tile.

Il protocollo elaborato per i livelli superiori Tutti i comandi inviati in uplink generano dei dati che necessitano di essere ricevuti a Terra REQUISITO: possibilità di controllare l’avvio della trasmissione in downlink dei dati generati in seguito al comando, quando vi è una stazione GENSO che può riceverli. Categorie di comandi: Comandi a tempo di esecuzione breve (SHORT) Comandi a tempo di esecuzione lungo (LONG) STRATEGIA: SHORT: i dati vengono trasmessi automaticamente dopo la ricezione del comando. LONG: i dati generati vengono trattenuti in memoria e verranno trasmessi solo in seguito alla ricezione da Terra di un successivo comando di richiesta (getData). Tutti i comandi che vengono inviati in uplink dal Mission Controller quando vengono eseguiti dal TelemetryCommandProcessor in generale produrranno come risposta dei dati che necessitano di essere ricevuti a Terra. Il requisito richiesto al protocollo è che consenta di controllare l’avvio della trasmissione dei dati in downlink specificatamente quando vi è una stazione GENSO che in quel momento può riceverli. Il primo passo verso la definizione del protocollo che soddisfa il requisito è stato quello di suddividere i comandi in due categorie: quelli i cui dati sono immediatamente disponibili, ad esempio perché già presenti in memoria, e quelli i cui dati non sono immediatamente disponibili, ad esempio perché seguono a esecuzioni effettivamente lunghe o schedulate in un istante futuro. Chiameremo quindi: SHORT i comandi a tempo di esecuzione breve e LONG i comandi a tempo di esecuzione lungo La strategia con cui si è scelto di soddisfare Il requisito è differente a seconda del comando: per i comandi SHORT il requisito risulta automaticamente soddisfatto autorizzando la trasmissione dei dati direttamente dopo la ricezione del comando stesso. Questo funziona perché in generale, la stessa stazione GENSO che ha trasmesso il comando, un istante dopo sarà ancora in visibilità per poter ricevere la risposta. lo stesso non si può dire per i comandi LONG, quindi per soddisfare il requisito in relazione a questi si è pensato di conservare in memoria i dati generati fino ad un successivo comando di richiesta chiamato GetData.

Gestione di un comando SHORT timer N(S) + cmdShort_code verifica CRC verifica N(S) Frame ax.25 polling MCC GSS Canale RF OBRF TCP MEM In riferimento alla architettura complessiva vista prima, vediamo ora come funziona il protocollo nei due casi principali di utilizzo. Per primo vediamo la gestione di un comando SHORT… ACK_DATA

Gestione di un comando LONG 1/3 timer N(S) + cmdLong_code + appNum + params verifica CRC verifica N(S) Frame ax.25 polling Start exec MCC GSS Canale RF OBRF TCP TILE n La gestione di un comando LONG è diversa. Come abbiamo detto il downlink dei dati avviene in una fase successiva in seguito ad un apposito comando di richiesta. Le informazioni inviate al g.s. ora hanno un parametro in più: l’Application Number, un numero che verrà utilizzato per assegnare un nome ai dati generati in seguito all’esecuzione di tale LONG, come si vedrà necessario per potersi a questi riferire in un successivo comando di richiesta. CMD_RECEIVED

Gestione di un comando LONG 2/3 timer interrogazione MCC GSS Canale RF OBRF TCP TILE n DATA NULL Da questo momento in poi la tile interessata dal comando LONG appena mandato in esecuzione entrerà in una lista di tile che hanno delle esecuzioni in corso e che il TelemetryCommandProcessor interrogherà periodicamente allo scopo di … MEM

Gestione di un comando LONG 3/3 timer N(S) + getData_code + applNum MCC GSS Canale RF OBRF TCP MEM DATA_NRDY / ACK_DATA

Gestione degli errori 1/2 La gestione degli errori si basa su un meccanismo a “conferma positiva o ritrasmissione” Perdita in uplink o downlink → il Mission Controller non riceve un ACK_DATA o un CMD_RECEIVED entro un tempo di time-out → ritrasmette una copia del comando Perdita in downlink → il satellite riceve il comando per la seconda volta: La ricezione di una copia di un comando SHORT comporta la riesecuzione identica La ricezione di una copia di un comando LONG non comporta la riesecuzione, ma la generazione di un messaggio CMD_DUPLICATED

Definizione dei pacchetti Due tipi di pacchetto in uplink: 1) backdoorCommand 2) ordinaryCommand (SHORT / LONG) SHORT: getData, getFrag, basicTelemetry, … LONG: orientation, image, … Due tipi di pacchetto in downlink: 1) pureNACK 2) ordinaryDownlink (DATA, MESSAGE) DATA: beacon, ack_data, ack_frag Message: DATA_NRDY, BAD_CMD, UN_CMD_NUM, … Per il protocollo visto, sono stati definite in UML tutte le entità coinvolte, i formati dei pacchetti e i diagrammi di sequenza per tutti i casi d’uso. Questo ci ha permesso di verificare tutte le interazioni e quindi il funzionamento teorico e di avviarci verso fasi più avanzate di sviluppo. In particolare i pacchetti definiti sono classificabili in due categorie per l’uplink e due per il downlink. I backdoor … Gli ordinaryCommand … Poi in downlink: I pureNACK … I pacchetti appartenenti alla categoria degli ordinaryDownlink sono quelli che i dati e tutti i messaggi che consentono il corretto funzionamento del protocollo stesso. Negli esempi abbiamo visto solo i messaggi CMD_RECEIVED e CMD_DUPLICATED, ma nel funzionamento completo sono definiti molti altri tipi di messaggio che il satellite può trasmettere verso terra, quali DATA_NRDY che viene usato quando i dati .., oppure Questi possono essere classificati in due categorie per l’uplink e due per il downlink, ma di cui per ragioni di tempo non forniamo ulteriori dettagli.

Analisi delle prestazioni Ip: comando SHORT Definiamo: Request-Delivery Time (RDT): tempo che intercorre tra l’inizio della trasmissione del comando e la fine della ricezione della risposta. timer TInternet_up (Ttx+Tp)up Tpoll+Tread MCC GSS Canale RF OBRF TCP MEM TInternet_down (Ttx+Tp)down Tsend

Analisi delle prestazioni Rb_int = 100 kbps Ttimer = 0.06 s (Ttimer > 0.04 s) TInternet_up = TInternet_down = 50ms d = 800 Km Dcom = Dmsg = 255 B Lsync+Lheader+Lpayload = 293 B → RDT = 0.656 s Si conclude RB’ = Lpayload /RDT = 3.1 kbps Rb_int=70÷150kbps Ttimer=0.06÷0.11s Questo grafico riporta il Request-Delivery Time in funzione della velocità dei dati tra OBRF e OBC e il periodo del timer. Al crescere della data-rate interna e al diminuire del tempo di timer il Request-Delivery Time chiaramente decresce. Fissata una data rate interna di 100 kbps e dimensionato di conseguenza il tempo di timer a 0.06 s, considerato il tempo di transito in Internet di 50 ms, distanza 800 Km e frame in up e downlink pieni, si ottiene un Request-Delivery Time di 0.656 s. Rapportandolo ai dati di payload trasportati in up o in downlink ci fornisce un goodput di 3.1 kbps a f sono variabili dimensionate per ottimizzare il RDT Comando SHORT di richiesta e dato recuperato occupano interamente un frame.

On-Board Radio Frequency module (OBRF) OBC Infine qualche parola sull’attività di laboratorio. In figura possiamo vedere lo schema a blocchi del prototipo usato in laboratorio e di cui ne è ho costruito un secondo esemplare. Esso è costituito da: il microcontrollore che … il transceiver che …, il power amplifier che fornisce una potenza media fino a 3 W il commutatore d’antenna. Sotto invece possiamo vedere la foto del prototipo usato in laboratorio per i test di cui si parlerà alla fine.

Transceiver: TI CC1020 Microcontrollore: TI MSP430 Caratteristiche: - ridotta tensione di alimentazione - ridotto consumo di corrente - pochi componenti esterni - dimensioni contenute Compiti transceiver: Conversione tra sequenze binarie e forme d’onda a RF Compiti del MCU: 1) configurare il transceiver (modi e parametri di funzionamento) 2) gestire lo stream in ricezione e trasmissione 3) interfacciarsi con l’OBC Il un cuore dell’OBRF è la coppia costituita dal transceiver CC1020 e il microprocessore MSP430. Il compito del transceiver è quello di realizzare la ricetrasmissione dei bit in modulazione FSK, mentre quello del microcontrollore è di creare i frame ax.25 e di configurare il modo di funzionamento del transceiver (cioè ricezione e trasmissione) e i relativi parametri durante tutte le fasi della comunicazione decise dal livello protocollare superiore.

Collaudo e test del OBRF TNC PK-96 Tranceiver CC1020 MSP-430 CC1020 MSP-430 Allo stato attuale di sviluppo hardware si sono potuti eseguire diversi test di trasmissione e ricezione di frame ax.25, quindi a livello data-link, nelle due configurazioni rappresentate in questa slide: comunicazione tra stazione di radioamatore e prototipo comunicazione tra un prototipo e l’altro. Si è verificato in entrambi i casi il corretto funzionamento e si sono individuate alcune criticità che peggiorano la percentuale di frame ricevuti correttamente.

Possibili sviluppi Valutazione di una soluzione alternativa che prevede l’uso del preesistente protocollo AX.25 in modalità connected direttamente tra ground station e OBRF → Studio comparato delle prestazioni dei due protocolli (ad es. mediante simulatori a eventi discreti)

Domande?