Esercitazione: Informazioni su RF virtuale (vRF) tramite la demodulation di Aqua usando GNU Radio

In Esercitazione: Downlink dei dati provenienti da un satellite pubblico, i dati del satellite Aqua della NASA vengono scollegati tramite un modem gestito, il che significa che il segnale RF non elaborato ricevuto dal satellite Aqua dalla stazione di terra viene passato attraverso un modem gestito da Azure Orbital. L'output di questo modem, sotto forma di byte, viene quindi trasmesso alla macchina virtuale dell'utente. Come parte del passaggio Configurare un profilo di contatto per una missione di downlink satellite pubblico, la configurazione demodulation è stata impostata su Aqua Direct Broadcast, che è ciò che è abilitato e configurato il modem gestito per demodulare/decodificare il segnale RF ricevuto da Aqua. Usando il concetto vRF, non viene usato alcun modem gestito e viene invece inviato il segnale RF non elaborato alla macchina virtuale dell'utente per l'elaborazione. Questo concetto può essere applicato sia al downlink che all'uplink, ma in questa esercitazione viene esaminato il processo di downlink. Creiamo una vRF, basata su GNU Radio, che elabora il segnale RF non elaborato e agisce come modem.

Questa guida illustra come eseguire queste operazioni:

Prerequisiti

• Esercitazione completa : Downlink dei dati dal satellite pubblico Aqua della NASA, perché questa esercitazione presuppone che il veicolo spaziale e la macchina virtuale siano già stati configurati.

Comprendere le limitazioni e i compromessi dell'uso di vRF

Prima di approfondire l'esercitazione, è importante comprendere il funzionamento di vRF e come viene confrontato con l'uso di un modem gestito. Con un modem gestito, l'intero livello fisico (PHY) si verifica all'interno di Azure Orbital, ovvero il segnale RF viene immediatamente elaborato all'interno delle risorse di Azure Orbital e l'utente riceve solo i byte di informazioni prodotti dal modem. Scegliendo vRF, non è presente alcun modem gestito e il segnale RF non elaborato viene trasmesso all'utente dal digitalizzatore della stazione di terra. Questo approccio consente all'utente di eseguire il proprio modem o di acquisire il segnale RF per un'elaborazione successiva.

I vantaggi di vRF includono la possibilità di usare modem a cui Azure Orbital non supporta o ha accesso. vRF consente inoltre di eseguire lo stesso segnale RF tramite un modem durante il tentativo di parametri diversi per ottimizzare le prestazioni. Questo approccio può essere usato per ridurre il numero di passaggi satellite necessari durante i test e velocizzare lo sviluppo. A causa della natura dei segnali RF non elaborati, le dimensioni del pacchetto/file sono in genere maggiori dei byte contenuti all'interno del segnale RF; di solito tra 2-10x più grande. Altri dati indicano che la velocità effettiva di rete tra la macchina virtuale e Azure Orbital può potenzialmente essere un fattore di limitazione per vRF.

In questa esercitazione si apprenderà come funziona vRF. Al termine di questa esercitazione sono inclusi diversi dettagli specifici di RF e digitalizzatore che sono di interesse per un utente vRF.

Ruolo di DIFI all'interno di vRF

Le stazioni di terra di Azure Orbital sono costituite da digitalizzatori che usano DIFI per inviare e ricevere segnali RF digitalizzati. Il protocollo DIFI Packet Protocol, tecnicamente definito "IEEE-ISTO Std 4900-2021: Digital IF Interoperability Standard", definisce un'interfaccia del piano dati destinata alla trasmissione e alla ricezione di dati IF digitalizzati (ad esempio i campioni IQ) e i metadati corrispondenti su reti IP standard. Anche se DIFI è uno standard "IF", anche gli esempi di IQ in baseband possono essere trasmessi con DIFI, come avviee con Azure Orbital. Il caso d'uso principale dei pacchetti DIFI è quello di creare un'interfaccia tra digitalizzatori di stazione di terra satellite (transceiver) e modem software, abilitando l'interoperabilità e combattendo il blocco fornitore che affligge l'industria satellite.

Il protocollo DIFI Packet Protocol contiene due tipi di messaggio principali: pacchetti di dati e pacchetti di contesto. A causa di motivi hardware legacy, esistono due versioni diverse di pacchetti di contesto. Le stazioni di terra di Azure Orbital usano i pacchetti di contesto DIFI v1.1 aggiornati per i segnali X-Band e il formato legacy per i segnali S-Band. Se usi il pacchetto gr-difi GNU Radio, vuoi assicurarti di selezionare il formato da 108 byte per X-Band e il formato a 72 byte per S-band. Per le vRF non GNU Radio è necessario assicurarsi che la versione corretta di DIFI venga usata per i pacchetti di contesto, v1.1 è disponibile qui e la versione legacy può essere dedotta da questa sezione di codice. Altre considerazioni sono incluse nella vRF all'interno di Riferimento AOGS alla fine di questa esercitazione.

Passaggio 1: Usare AOGS per pianificare un contatto e raccogliere dati Aqua

Prima di tutto, rimuovere il modem gestito e acquisire i dati RF non elaborati in un file pcap. Eseguire i passaggi elencati in Tutorial: Downlink data from NASA's Aqua public satellite but during step Configure a contact profile for an Aqua downlink mission leave the Demodulation Configuration blank and choose UDP for Protocol.Execute the steps listed in Tutorial: Downlink data from NASA's Aqua public satellite but during step Configure a contact profile for an Aqua downlink mission leave the Demodulation Configuration blank and choose UDP for Protocol.Execute the steps listed in Tutorial: Downlink data from NASA's Aqua public satellite but during step Configure a contact profile for an Aqua downlink mission leave the Demodulation Configuration blank and choose UDP for Protocol. Infine, verso la fine, anziché il socat comando (che acquisisce pacchetti TCP), eseguire sudo tcpdump -i eth0 port 56001 -vvv -p -w /tmp/aqua.pcap per acquisire i pacchetti UDP in un file pcap.

Dopo un passaggio satellite, è necessario avere un file /tmp/aqua.pcap di dimensioni da 10 a 20 GB (a seconda dell'elevazione massima). Questo file contiene pacchetti DIFI contenenti il segnale RF non elaborato ricevuto dalla stazione di terra, sotto forma di campioni di IQ.

Passaggio 2: Estrarre gli esempi di IQ dai pacchetti DIFI

Quindi estraiamo gli esempi di IQ e li salviamo in un formato più tradizionale; un file di IQ binario. I passaggi seguenti possono essere eseguiti in qualsiasi macchina virtuale/computer con una copia del file aqua.pcap creato. Questi passaggi implicano l'uso di uno script Python breve gestito dal CONSORZIO DIFI per estrarre gli esempi di IQ dai pacchetti DIFI UDP in un file IQ.

1. Scaricare o copiare il codice seguente in un nuovo script Python.
2. Modificare filename in modo che corrisponda ovunque sia stato salvato il file pcap (/tmp/aqua.pcap).
3. Eseguire lo script Python usando python3 difi_to_binary_iq.pye deve creare un nuovo file nella stessa directory del file pcap, con un'estensione .cs8 . Questo file è il file IQ binario, che contiene i campioni RF digitalizzati come numeri interi a 8 bit e nient'altro. L'esecuzione dello script richiede tempo e l'esecuzione del file diventa più grande. Al termine dello script, il file corrisponde approssimativamente alla stessa dimensione del file pcap. È possibile arrestare lo script prima del completamento (con control-C) e continuare l'esercitazione; l'intera durata del contatto non è necessaria per il resto dell'esercitazione.
4. (Facoltativo) Se si vuole visualizzare il segnale, installare Inspectrum usando https://github.com/miek/inspectrum/wiki/Build#building-on-debian-based-distros quindi eseguire Inspectrum usando inspectrum /tmp/aqua.pcap.cs8 (usando il percorso del nuovo .cs8 file). Una volta nell'interfaccia utente grafica Inspectrum, è possibile regolare e Power Min visualizzare Power Max l'intervallo dinamico completo del segnale.

Se si vogliono anche gli esempi di IQ in formato float32 anziché int8 (alcuni software consentono solo di caricare il formato float32), è possibile usare il frammento di codice Python seguente:

import numpy as np
samples = np.fromfile('/tmp/aqua.pcap.cs8', np.int8) / 127.0
samples = samples.astype(np.float32)
samples.tofile('/tmp/aqua.pcap.cf32')

Verrà usata la versione float32 per il passaggio successivo, in quanto semplifica il flusso di radio GNU.

Passaggio 3: Demodulare il segnale Aqua in GNU Radio

Successivamente creiamo il modem vRF effettivo, basato su GNU Radio, usato per demodulare il segnale Aqua.

GNU Radio è un toolkit di sviluppo software gratuito e open source che fornisce blocchi di elaborazione dei segnali e molte applicazioni DSP (Digital Signal Processing). Può essere usato con hardware RF a basso costo disponibile per creare radio definite dal software o senza hardware in un ambiente simile alla simulazione. GNU Radio è ampiamente utilizzato in ambienti di ricerca, industria, università, governo e hobbyist per supportare sia la ricerca di comunicazioni wireless che i sistemi radio reali. In questa esercitazione si usa GNU Radio per demodulare Aqua (ovvero GNU Radio funge da modem).

Anche se GNU Radio può essere usato in modalità headless, in questa esercitazione si usa l'interfaccia utente grafica di GNU Radio (ovvero, interfaccia desktop), quindi è necessario copiare /tmp/aqua.pcap.cf32 in una macchina virtuale con inoltro X11 o computer con desktop Ubuntu 20/22. Il comando scp può essere usato per copiare il file da una macchina virtuale in Azure in un computer di sviluppo locale.

Installare GNU Radio

Se si usa Ubuntu 22, eseguire sudo apt-get install gnuradio. Se invece si usa Ubuntu 20, usare i comandi seguenti per installare GNU Radio:

sudo add-apt-repository ppa:gnuradio/gnuradio-releases
sudo apt-get update
sudo apt-get install gnuradio python3-packaging

Verificare che GNU Radio sia installato correttamente e che gli elementi grafici funzionino usando gnuradio-companion. Verrà visualizzata una finestra simile alla seguente:

Se l'albero a blocchi a destra non viene visualizzato, è possibile visualizzarlo usando l'icona della lente di ingrandimento in alto a destra.

Eseguire il flussografo Aqua

Un'applicazione GNU Radio è denominata "flowgraph" e in genere elabora o genera un segnale RF. Il flowgraph iniziale da usare può essere scaricato qui. Aprire questo .grc file all'interno di GNU Radio e dovrebbe essere visualizzato il flussografo seguente:

Il flussografo inizia leggendo nel file IQ, convertendolo da interleaved integer a 8 bit al tipo di dati complesso di GNU Radio, quindi ricampiona il segnale da passare dall'originale 18,75 MHz a 15 MHz, che è un numero intero di campioni per simbolo. Questo ricampionare potrebbe essere un po 'confuso perché nel profilo contatto è stata specificata una larghezza di banda di 15 MHz. Come illustrato di più alla fine di questa esercitazione, per i segnali X-Band il digitalizzatore usa una frequenza di campionamento pari a 1,25 volte la larghezza di banda specificata. Si scopre che in questo flussografo vogliamo una frequenza di campionamento di 15 MHz, in modo che abbiamo esattamente due campioni per simbolo; pertanto dobbiamo ricampionare da 18,75 MHz a 15 MHz. A questo punto è presente un blocco AGC (Automatic Gain Control) per normalizzare il livello di alimentazione del segnale. Il filtro del coseno generato dalla radice funge da filtro corrispondente. Il ciclo Costas esegue la sincronizzazione della frequenza per rimuovere eventuali piccoli offset di frequenza causati dall'errore dell'oscillatore o dalla correzione doppler imperfetta. I tre blocchi successivi vengono usati perché Aqua usa L'offset QPSK (OQPSK) anziché il normale QPSK. La sincronizzazione dei simboli viene quindi eseguita in modo che i simboli OQPSK vengano campionati ai picchi. È possibile visualizzare questo campionamento di QPSK usando il blocco Sink Di costellazione (viene mostrato un esempio di output). Il resto del flussografo interlea le parti reali e immaginarie e le salva come int8 (chars/byte) che rappresentano i simboli morbidi. Anche se potrebbe convertire questi simboli soft in 1 e 0, l'elaborazione successiva trae vantaggio dalla presenza dei valori completi dei simboli.

Prima di eseguire il flowgraph, fare doppio clic sul blocco Origine file e aggiornare il percorso in modo che corrisponda a ovunque sia stato salvato /tmp/aqua.pcap.cf32. Fare clic sul pulsante play nella parte superiore per eseguire il diagramma di flusso. Se i passaggi precedenti hanno avuto esito positivo e il contatto Aqua ha avuto esito positivo, dovrebbe essere visualizzato il seguente grafico spectrale di potenza (PSD) e IQ plot:

I tuoi potrebbero variare, in base alla forza che il segnale è stato ricevuto. Se non è presente alcuna GUI, controllare l'output di GNU Radio in basso a sinistra per individuare gli errori. Se l'interfaccia utente grafica viene visualizzata ma assomiglia a una linea rumorosa orizzontale (senza gobba), significa che il contatto non ha effettivamente ricevuto il segnale Aqua. In questo caso, verificare che il rilevamento automatico sia abilitato nel profilo contatto e che la frequenza centrale sia stata immessa correttamente.

Il tempo necessario per completare GNU Radio è basato sul tempo di esecuzione dello script pcap_to_iq, combinato con la potenza della CPU del computer/macchina virtuale. Durante l'esecuzione del flowgraph, il segnale RF archiviato in /tmp/aqua.pcap.cf32 e la creazione del file /tmp/aqua_out.bin, che contiene l'output del modem. È possibile copiare il file .bin dalla macchina virtuale.

Questa esercitazione verrà terminata qui. Se si è interessati a decodificare i byte nelle immagini, è possibile usare gli strumenti della NASA o strumenti open source, ad esempio altillimity/X-Band-Decoders.

(Facoltativo) Passaggio 4: Eseguire il flusso di radio GNU live

Questa esercitazione fino a questo punto rappresenta la parte di progettazione/test della creazione di un vRF. Questo flusso di radio GNU viene trasformato in modo che possa essere eseguito in tempo reale nella macchina virtuale, simile a un vero modem vRF.

Gestire l'input

In precedenza, il pacchetto DIFI pcap viene convertito manualmente in un file IQ binario, quindi caricato il file IQ binario in GNU Radio con il blocco Origine Fink. È possibile semplificare il flussografo usando un blocco all'interno di gr-difi (gestito da Microsoft) progettato per ricevere pacchetti DIFI in GNU Radio! Questo blocco aggiunto richiede l'installazione di un modulo GNU Radio out-of-tree (OOT), simile a un plug-in per GNU Radio:

sudo apt-get install python3-pip cmake liborc-dev doxygen
sudo pip install pytest pybind11
cd ~
git clone https://github.com/DIFI-Consortium/gr-difi
cd gr-difi
mkdir build
cd build
cmake -DCMAKE_FIND_ROOT_PATH=/usr ..
make -j4
sudo make install
sudo ldconfig

Dopo questi passaggi, dovrebbe essere possibile riaprire GNU Radio e visualizzare i nuovi blocchi (origine DIFI e sink DIFI) elencati nell'albero dei blocchi. Nel flowgraph usato durante la sezione precedente seguire questa procedura:

1. Sostituire il blocco Origine file con un blocco di origine DIFI
2. Fare doppio clic sul blocco di origine DIFI per modificarne i parametri
3. L'indirizzo IP di origine deve essere l'indirizzo IP dell'interfaccia eth0 della macchina virtuale
4. La porta deve essere 56001, proprio come è stato usato nel passaggio tcpdump
5. Impostare DIFI Stream Number (Numero di flusso DIFI) su 0. Tutti gli altri parametri possono essere lasciati predefiniti

Se si vuole testare questo flowgraph nel computer di sviluppo, è necessario uno strumento come udpreplay per riprodurre il pcap registrato. In caso contrario, è possibile attendere di testare questa parte fino a quando il flussografo non viene usato in tempo reale nella macchina virtuale connessa ad Azure Orbital. Questa limitazione è un motivo per cui consente di registrare il segnale durante la fase di sviluppo e test vRF.

Gestire l'output

È possibile scegliere di lasciare il sink di file alla fine e recuperare il file registrato ogni passaggio, ma molte applicazioni richiedono lo streaming dei byte dal modem. Un'opzione consiste nell'usare il blocco sink TCP al posto del sink di file. Il blocco sink TCP può essere configurato in modalità server o client, a seconda del lato in cui deve essere stabilita la connessione iniziale. Impostare Tipo di input su Byte e il sink TCP trasmette i byte su un payload TCP non elaborato.

Il sink PUB ZMQ è un'altra opzione, ovvero una libreria di messaggistica che si trova sopra la comunicazione TCP o interprocesso (IPC), per un comportamento più complesso, ad esempio PUB/SUB.

Se lo si lascia come sink di file, è consigliabile aggiungere alcune righe di Python alla fine del flussografo (al termine) che copia il file creato in un nuovo percorso.

Eseguire il flowgraph in modalità headless

È possibile che la macchina virtuale che riceve il flusso Di Azure Orbital non supporti un ambiente desktop, causando l'arresto anomalo di GNU Radio. È necessario configurare questo flowgraph per evitare l'uso delle interfacce utente utente.We must configure this flowgraph to avoid using GUIs.

1. Modificare il blocco Opzioni in alto a sinistra
2. In Genera opzioni scegliere Nessuna GUI
3. In Opzioni esecuzione scegliere Esegui al completamento
4. Premere OK

Questi passaggi consentono di eseguire il flowgraph come script Python senza GUI e quando il socket in ingresso chiude automaticamente il flussografo.

Eseguire il flussografo live

Dopo aver configurato il flowgraph con l'origine DIFI e in modalità headless, è possibile eseguire il flowgraph live nella macchina virtuale. In GNU Radio Companion (GRC), ogni volta che si preme il pulsante di riproduzione, viene creato un file .py nella stessa directory. Questo script Python deve essere copiato nella macchina virtuale. Se GNU Radio e gr-difi sono stati installati correttamente, dovrebbe essere possibile eseguire lo script Python usando python yourflowgraph.py e attende l'avvio del flusso DIFI da Azure Orbital. È possibile aggiungere qualsiasi codice Python che si vuole usare per questo script Python, ad esempio copiare il file risultante in un nuovo percorso per ogni passaggio. Nota: se si rigenera lo script Python all'interno dell'archiviazione con ridondanza geografica, questo nuovo codice Python deve essere aggiunto di nuovo manualmente.

Se i passaggi precedenti hanno funzionato, è stato creato e distribuito un vRF downlink basato su GNU Radio!

Informazioni di riferimento su vRF all'interno di AOGS

In questa sezione vengono forniti diversi dettagli specifici di RF/digitalizzatore che sono di interesse per un utente o una finestra di progettazione vRF.

Sul lato downlink, un vRF riceve un segnale da Azure Orbital. Un flusso DIFI viene inviato alla macchina virtuale dell'utente da Azure Orbital durante un contatto satellite. L'utente dovrebbe acquisire il flusso in tempo reale, registrandolo o elaborandolo in tempo reale. Gli esempi includono l'uso di tcpdump, socat o inseriti direttamente in un modem. Di seguito sono riportate alcune specifiche relative al modo in cui la stazione di terra di Azure Orbital riceve ed elabora il segnale:

• La frequenza centrale è specificata nel profilo contatto
• La larghezza di banda del segnale (BW) è impostata nel profilo contatto e la frequenza di campionamento è 1.25*BW per X-Band e 1.125*BW per i contatti S-Band
• Il flusso DIFI usa una profondità a 8 bit (2 byte per ogni esempio di IQ)
• La modalità di guadagno del digitalizzatore è impostata per l'uso del controllo del guadagno automatico (AGC) con una destinazione di alimentazione pari a -10 dBFS
• Non viene usata alcuna inversione spettrale
• Non viene usato alcun offset di frequenza
• Le dimensioni MTU della macchina virtuale utente devono essere impostate su 3650 per X-Band e 1500 per S-Band, ovvero le dimensioni massime dei pacchetti provenienti da Azure Orbital

Sul lato uplink, l'utente deve fornire un flusso DIFI ad Azure Orbital durante il passaggio, affinché Azure Orbital trasmetta. Le note seguenti potrebbero essere interessanti per una finestra di progettazione vRF uplink:

• La frequenza centrale è specificata in Profilo contatto
• La frequenza di campionamento del segnale viene impostata tramite il flusso DIFI (anche se una larghezza di banda viene fornita come parte del profilo di contatto, è puramente per la configurazione di rete in background)
• La profondità del bit viene impostata tramite il flusso DIFI, ma Azure Orbital prevede 8 bit
• L'ID flusso DIFI deve essere impostato su 0
• Analogamente al downlink, la dimensione MTU deve essere 1500 per S-Band e fino a 3650 per X-Band (scelta)
• Non viene usata alcuna inversione spettrale
• Non viene usato alcun offset di frequenza

Passaggi successivi

Per distribuire facilmente i componenti downstream necessari per ricevere ed elaborare i dati di osservazione terrestre spaziali tramite Azure Orbital Ground Station, vedere:

• Integrazione di Azure Orbital