Implementazione e validazione del
ricevitore VHF aeronautico
5.1. Il primo tentativo di waveform: ric_aeronautico_prova1
Il nostro punto di partenza per la realizzazione del ricevitore VHF aeronautico è stato la costruzione di una semplice waveform di prova che abbiamo chiamato ric_aeronautico_prova1 e che è riportata, così come viene visualizzata dall’ALF in Eclipse, in Fig. 5.1.
Fig. 5.1 – Ric_aeronautico_prova1
I componenti con i quali abbiamo realizzato questa prima waveform sono: l’USRP_Commander, il Decimator, il Butterworth_filter e l’am_demod. L’USRP_Commander ha la funzione di gestire e pilotare l’USRP2 offrendo al programmatore una lista di proprietà che sono riportate in Fig. 5.2. E’ per questo motivo che non è presente la freccia nera tra i primi due blocchi, infatti lo stream dei
campioni viene passato in ingresso al Decimatore dal Device USRP2 non dall’USRP_Commander che invece serve solo all’utente per pilotare l’USRP2. Inoltre, l’uscita dell’ultimo blocco, l’am_demod, è collegata al Device PlaybackSoundCard e quindi dopo la demodulazione AM, il segnale viene inviato alla scheda audio del PC.
Fig. 5.2 – Proprietà dell’USRP_Commander
I componenti di questa waveform erano già tutti presenti nel pacchetto OSSIE che è stato installato sul PC a parte il filtro di Butterworth che invece è stato creato nel lavoro di tesi [6].
Come riportato nel primo capitolo, il segnale fornito dalla USRP2 è uno
stream di campioni complessi (I,Q) interallacciati alla velocità di 100 MS/s, quindi la
banda che siamo in grado di rappresentare risulta pari a 100 Mhz. In questo momento, per noi, è sufficiente una banda di circa 3 Khz, che corrisponde alla banda del segnale audio che dovremmo riuscire ad ascoltare.
Per questo motivo, il tasso di decimazione dell’USRP2, ovvero rx_decim, come si nota dalle proprietà di Fig. 5.2, l’abbiamo settato a 400, il massimo valore
possibile. Di conseguenza, il flusso proveniente dall’USRP2 passa da 100 MS/s a 250 KS/s, questo significa una banda rappresentabile di 250 Khz, ancora molto più grande di quella desiderata.
Ecco il motivo che spiega l’introduzione del componente Decimator in cascata all’USRP_Commander. Questo componente, che effettua sullo stream di campioni che riceve al suo ingresso un’ulteriore decimazione, ha le proprietà rappresentate in Fig. 5.3.
Fig. 5.3 – Proprietà del Decimatore
A questo punto, abbiamo settato il tasso di decimazione del Decimatore, ovvero DecimateBy, a 10, in modo da ridurre ulteriormente la velocità del flusso dei campioni di un fattore dieci, portandola quindi a 25 KS/s. Non abbiamo potuto scendere ulteriormente con la velocità perché le specifiche della scheda audio, presente sul nostro PC, richiedono appunto un flusso di campioni a 25 KS/s, un diverso valore porterebbe ad un disaccoppiamento e quindi del rumore nell’ascolto del segnale audio.
Abbiamo quindi dovuto abbassare la velocità dello stream fornito dall’USRP2 da una parte, per via dei requisiti della scheda audio e dall’altra per riuscire il più possibile a limitare la banda del segnale ricevuto entro i 3 Khz richiesti, visto che come terzo blocco della nostra waveform avremmo inserito l’am_demod che, come è
evidente, più banda ‘inutile’ gli forniamo in ingresso e più rumore ci restituisce poi in uscita.
Ecco perché prima dell’am_demod abbiamo dovuto inserire un filtro di Butterworth passa basso che filtrasse esattamente una banda di 3 Khz, eliminando così tutto il rumore ‘fuori banda’. Le proprietà del filtro sono riportate in Fig. 5.4.
Fig. 5.4 – Proprietà del filtro di Butterworth
Settando la frequenza di taglio, cut_off_frequency, a 3000 Hz abbiamo cercato di rendere massimo il rapporto segnale-rumore in uscita al componente.
Inoltre abbiamo settato la velocità dello stream dei campioni, ovvero il sample_rate, a 25000, proprio quello in ingresso al componente e order, cioè l'ordine del filtro, a 15, in modo tale da avere un ripido fronte di discesa del filtro ed eliminare il più possibile il rumore.
Finalmente abbiamo potuto inserire, in cascata al filtro di Butterworth, il componente am_demod, che esegue la demodulazione AM del segnale come richiede lo standard VHF aeronautico e non possiede nessuna proprietà.
Un’altra possibilità che abbiamo valutato per realizzare questa prima
waveform è stata quella di settare rx_decim dell’USRP2_Commander a 400 e
velocità di 3012 S/s, quindi una banda di praticamente 3 Khz coincidente con la banda del segnale audio.
In questo modo avremmo potuto evitare il filtraggio passa basso prima del demodulatore AM e all’uscita di esso avremmo potuto inserire un interpolatore (componente già presente nel pacchetto OSSIE) che riportasse la velocità ai 25 Khz ottimali per la scheda audio.
Il problema di questa waveform è stato che nessun fattore intero, come richiesto dal componente Interpolator, ci riportava molto vicino ai 25 Khz richiesti dalla scheda audio e quindi l’adattamento risultava peggiore.
Quindi, visto che questa seconda opzione non portava al risparmio del numero di componenti per creare la waveform e creava invece disaccoppiamento con la scheda audio, non è stata ulteriormente esplorata.
5.1.1. Testing della waveform ric_aeronautico_prova1
Per verificare il funzionamento della waveform ric_aeronautico_prova1, abbiamo generato una portante sinusoidale, tramite il generatore di segnale, con una frequenza a nostro piacimento dello standard VHF aeronautico, 120 Mhz, e gli abbiamo fornito una potenza di -10dBm. Su questa portante abbiamo introdotto una modulazione di tipo AM con una profondità di modulazione pari a 0.85, come indicato dallo standard VHF aeronautico e come segnale modulante una sinusoide di 2 Khz, il valore centrale della banda del segnale audio da ricevere.
Dopo aver verificato la correttezza dei dati impostati tramite l’oscilloscopio, abbiamo settato le proprietà dell’USRP_Commander: rx_freq a 120 Mhz, rx_decim a 400 e il guadagno rx_gain a 95, come si può vedere dalla Fig. 5.2 e abbiamo provato ad ascoltare il segnale ricevuto tramite le cuffie. Effettivamente abbiamo sentito un fischio a 2 Khz ma con molto rumore di sottofondo ed era presente un disadattamento della scheda audio, nonostante la velocità del flusso dei campioni fosse quella ottimale, perché il segnale emetteva dei ‘clip’ ogni due secondi.
Per una verifica più accurata abbiamo lanciato l’ALF di Eclipse ed abbiamo installato la nostra waveform che è stata visualizzata sullo schermo. Grazie a questo
tool abbiamo potuto visualizzare lo spettro in uscita ad ogni componente e controllare
l’elaborazione che ognuno di essi eseguiva sul segnale.
Il tool ALF rappresenta il plot su una scala delle frequenze normalizzate alla frequenza con la quale i campioni vengono trasmessi fuori dalla porta di uscita del componente, nel nostro caso quindi la gamma di frequenze è divisa per 25000 per tutti i componenti. Inoltre, dato il fatto che le frequenze nel plot vengono rappresentate da -1 ad 1, il segnale modulante da noi utilizzato, 2 Khz, lo dovremmo ritrovare a 0.16, perchè deve essere diviso per 12500.
Fig. 5.5 – Plot in uscita al Decimatore
In Fig. 5.5 è rappresentato il plot in uscita al Decimatore. Come è possibile notare dalla figura, nello spettro sono presenti, a parte il rumore, la componente continua, il segnale modulante e le altre armoniche, dentro la banda di 25 Khz, provocate dal fatto che i segnali generati non sono infiniti ma hanno durata limitata.
Fig. 5.6 – Plot in uscita al filtro di Butterworth
In Fig. 5.6 è rappresentato il plot in uscita al filtro di Butterworth che evidenzia l’effettiva eliminazione del rumore ‘fuori banda’, eliminando tutte le armoniche del segnale e lasciando passare al blocco successivo solo la componente continua e il segnale modulante.
In Fig. 5.7, infine, è rappresentato il plot in uscita al demodulatore AM. Nello spettro sono ben evidenti la componente continua, il segnale modulante e altre armoniche che sono provocate dalla demodulazione AM, che essendo un’operazione non lineare, genera della potenza anche a frequenze diverse da quelle che riceve al suo ingresso.
Come è possibile notare dalle immagini sopra, è presente, nelle prime due, uno schift dell’intero spettro verso destra di circa 500 Hz, 0.05 sulla scala delle frequenze normalizzate, mentre dopo il demodulatore AM questo viene compensato.
5.1.2 Modifica alla waveform ric_aeronautico_prova1
La Fig. 5.7 indica molto chiaramente che il rumore presente nelle nostre cuffie è provocato dalle tante armoniche in uscita all’am_demod e dalla componente continua essenziale per una demodulazione di tipo AM.
Per questo motivo abbiamo apportato una modifica alla waveform ric_aeronautico_prova1 aggiungendo un componente in più in cascata all’ am_demod, il Butterworth_elimina_continua che esegue un filtraggio passa basso del segnale e vi toglie anche la componente continua, restituendo in uscita solo il segnale modulante più rumore. Questo componente l’abbiamo creato utilizzando il codice del filtro passa basso di Butterworth e aggiungendo nella parte finale delle semplici righe di codice che calcolano la media del segnale e poi la sottraggono al segnale stesso, eliminandone così il valor medio.
Il procedimento per eliminare la continua l’abbiamo realizzato in due modi diversi. Uno prevedeva il calcolo della media su un solo blocco di campioni del segnale in ingresso e l’altro invece il calcolo della media su di un certo numero di
blocchi e quindi un procedimento che piano piano andava a regime per trovare una media del segnale sempre più accurata. I risultati comunque erano praticamente identici, la differenza tra i due metodi, infatti, esisteva ma era poco apprezzabile dato che la dimensione del blocco è sufficiente per calcolare un buon valore medio del segnale e quindi abbiamo scelto la soluzione più semplice e meno costosa dal punto di vista computazionale, ovvero la prima.
Per verificare la waveform così modificata abbiamo settato, per il nuovo componente, le stesse proprietà del filtro passa basso di Butterworth. Quindi, sempre grazie all’ALF di Eclipse, abbiamo visualizzato il plot in uscita al Butterworth_elimina_continua, che è riportato in Fig. 5.8.
Fig. 5.8 – Plot in uscita al Butterworth_elimina_continua
Come si può ben notare dal plot sopra, il risultato desiderato è stato ottenuto e infatti il suono audio in uscita dalle cuffie risultava migliorato in termini di rumore. Rimaneva però sempre da risolvere il problema del disadattamento con la scheda
audio. Allora grazie allo WaveDash fornito da Eclipse, riportato in Fig. 5.9, abbiamo cambiato in real time le proprietà dei vari componenti, variando la dimensione del blocco dei campioni che viene passato tra i vari componenti, ovvero la rx_size (proprietà dell’USRP_Commander), i fattori di decimazione del Decimator e dell’USRP_Commander e le frequenze di cut-off dei due filtri ma il disadattamento non migliorava, anzi peggiorava. Abbiamo però notato che con la variazione delle frequenze di cut-off il rumore veniva migliorato e quindi abbiamo deciso di rimandare le prove tramite lo WaveDash a fine lavoro, quando la waveform sarebbe stata completa.
Fig. 5.9 – WaveDash della waveform modificata
5.2. Inserimento di un nuovo componente: FFT_vhf_aeronautico
Una modifica sostanziale alla waveform ric_aeronautico_prova1 è stata l’introduzione di un nuovo componente che abbiamo chiamato FFT_vhf_aeronautico
e che abbiamo inserito, nella catena di ricezione, a monte del Decimatore, come mostrato in Fig. 5.10. Questa nuova waveform l’abbiamo chiamata ric_vhf_aeronautico.
Fig. 5.10 – Ric_vhf_aeronautico
Abbiamo scritto il codice C++ di questo nuovo componente a partire dal codice di un componente già esistente, l’FFT_RX_Control che era stato creato nel lavoro di tesi [6].
La funzione principale dell’FFT_vhf_aeronautico, come già detto nel quarto capitolo, è quella di effettuare uno scanning di tutta la banda VHF aeronautica dedicata alle trasmissioni vocali che va da 118 a 137 Mhz e mostrare a video i canali attivi, cioè i canali che in quel momento sono interessati da una comunicazione. A questo punto l’operatore è in grado di poter scegliere quale, tra i canali attivi, voler ascoltare inserendo il relativo numero da tastiera. Dopo aver premuto il tasto invio, l’esecuzione del codice C del componente, che si era predisposto in attesa della scelta del canale, riprende e va a settare la frequenza di ricezione (rx_freq: proprietà del componente USRP_Commander, vedi Fig. 5.2) e il tasso di decimazione, rx_decim, dell’USRP_Commander rispettivamente alla frequenza del canale scelto e a 400, tramite la porta RX_Control. Da ora fino alla fine della ricezione del segnale audio, il nuovo componente risulta trasparente e il segnale ricevuto segue l’ordine dei componenti già presenti sulla waveform, con le stesse caratteristiche che aveva
precedentemente perché, grazie alla porta RX_Control, la velocità dello stream è stata riportata a 250 KS/s e la frequenza centrale quella di un solo canale. Quindi le proprietà di tutti gli altri componenti rimangono le stesse e non è stata necessaria nessuna modifica.
Quello che è cambiato dalla waveform ric_aeronautico_prova1 sono le proprietà iniziali settate sull’USRP_Commander, infatti per poter effettuare lo
scanning della banda di nostro interesse abbiamo dovuto settare la rx_freq a 127.5
Mhz, cioè quella centrale, e un tasso di decimazione pari a 5. In questo modo la banda che il sistema è in grado di rappresentare diventa 20 Mhz che contiene i 19 Mhz da noi desiderati.
L’FFT_vhf_aeronautico per effettuare la scansione della banda e individuare quali sono i canali attivi, esegue la Trasformata Discreta di Fourier (DFT) su un blocco di campioni del segnale in ingresso, la cui dimensione è definita dall’ USRP_Commander e restituisce un blocco di campioni in uscita di pari lunghezza. Tramite i campioni frequenziali così ottenuti, si calcola la potenza di ogni campione e l’energia di tutti i canali tramite il procedimento di channel sensing spiegato nel sottocapitolo 4.4. Per migliorare le prestazioni del ricevitore, il calcolo della potenza dei campioni viene ripetuto, tramite un ciclo for, per un certo numero it di iterazioni e i valori che si susseguono sommati insieme e salvati dentro un vettore. Completati il numero “it” di cicli, ogni elemento del vettore viene diviso per it trovando così i valori di potenza medi.
Come già accennato nel sottocapitolo 4.4, per un’affidabilità maggiore nel calcolo dell’energia del canale, è necessario capire il numero di campioni corrispondenti ad ogni singolo canale e cercare di rendere questo numero il più grande possibile. Il limite a tutto questo viene imposto dall’USRP_Commander che al massimo è in grado di inviare all’FFT_vhf_aeronautico blocchi da 8192 campioni (rx_size, proprietà dell’USRP_Commander). Quindi, con un numero così elevato di canali, 2280, come risulta nello standard del VHF aeronautico, ad ogni canale sono
dedicati soltanto tre campioni e i rimanenti poi non vengono utilizzati. Ecco che il ciclo for, con un numero di iterazioni “it” molto elevato, diventa assolutamente necessario per ottenere un risultato affidabile.
Per il testing della waveform ric_vhf_aeronautico, abbiamo settato gli stessi parametri che avevamo settato nel test della waveform precedente per il generatore di segnale e tutti i componenti a parte l’USRP_Commander al quale, come spiegato prima, abbiamo modificato il valore della frequenza centrale e il tasso di decimazione. Dal punto di vista teorico avrebbe dovuto funzionare, purtroppo però ci siamo imbattuti in problemi computazionali, perché con i parametri così settati nelle proprietà dell’USRP_Commander e più precisamente il tasso di decimazione pari a 5 e la lunghezza del blocco 8192, la waveform non riusciva a partire e il PC si bloccava. Abbiamo quindi cominciato a variare i valori delle due proprietà critiche rendendoci conto che aumentando il tasso di decimazione o diminuendo la dimensione del blocco sul quale l’FFT_vhf_aeronautico effettuava l’FFT, la
waveform riusciva ad essere lanciata e il PC non si bloccava.
Nonostante questi risultati però, il problema non poteva essere risolto perché aumentare il tasso di decimazione avrebbe significato riuscire a rappresentare una banda inferiore ai 19 Mhz richiesti dallo standard VHF aeronautico e quindi non riuscire a ricevere tutti i 2280 canali; mentre abbassare la dimensione del blocco significava non riuscire nemmeno a fornire un campione per canale e quindi un’ impossibile rivelazione dei canali attivi.
5.3. La versione finale della waveform: ric_vhf_aeronautico
Siamo stati quindi costretti a cambiare il modo con cui si effettuava il channel
sensing. Quindi, invece di ricevere i 19 Mhz di banda in un solo colpo, settando il
tasso di decimazione dell’USRP_Commander a 5 ed effettuando l’FFT con 8192 campioni sui 19 Mhz ricevuti, abbiamo deciso di ricevere diverse sezioni dell’intera banda e su ognuna di queste effettuare il channel sensing: con un ciclo for potevamo
di volta in volta cambiare la frequenza centrale dell’USRP_Commander, ricevere una nuova parte della banda totale ed eseguire solo su questa l’FFT e il calcolo dell’energia dei canali che erano presenti in questa porzione di banda. Il tutto veniva salvato in un vettore e quindi al termine del ciclo for, cioè dopo aver effettuato la scansione dell’intera banda di 19 Mhz, ottenevamo lo stesso risultato della waveform precedente, cioè un vettore di 2280 elementi, dove ogni elemento rappresentava l’energia di ogni canale. Il resto del codice C++ del componente rimaneva invariato.
Il vantaggio di questo nuovo metodo risiede nel fatto di poter settare nell’USRP_Commander un tasso di decimazione molto alto e quindi anche con 8192 campioni, come dimensione del blocco, il PC non presentava nessun problema computazionale.
Abbiamo quindi deciso di settare il tasso di decimazione dell’USRP_Commander a 400, in modo tale da ricevere una banda pari a 250 Khz e la lunghezza del blocco pari a 5000. In questo modo la distanza tra un campione e l’altro diventa di 50 Hz, per cui, facendo riferimento alla canalizzazione riportata nel terzo capitolo, tra le portanti che distano tra loro di 8,3 Khz vanno a finire 166 campioni, mentre dove distano 8,4 Khz ne vanno 168. Il numero di canali che stanno in 250 Khz è pari a 30.
Tenuto conto del fatto che il canale è centrato intorno alle frequenze della mappa, per il calcolo dell’energia è stato eseguito un ciclo for dove vengono sommate tra loro le potenze dei vari campioni prendendone la prima volta 166, poi di nuovo 166, poi ne vengono saltati due, che corrispondono a quelli centrali tra le portanti che distano 8,4 Khz e poi altri 166. Da qui in poi il ciclo si ripete fino all’esaurimento dei 30 canali. Questo è stato fatto per evitare il disiallineamento che avrebbe provocato proprio la mappa dei canali non omogenea ma periodica di periodo 3.
Per effettuare il testing di questa modifica, abbiamo settato il tasso di decimazione dell’USRP_Commander a 400, la dimensione del blocco a 5000 e la frequenza centrale a 118.120.850 Hz. Questo perché il primo canale da ricevere è
intorno alla portante di 118 Mhz, quindi la prima sottobanda da 250 Khz deve partire dal valore di 118 Mhz al quale viene sottratto metà della larghezza del canale e cioè 4150 Hz per ottenere 117.995.850 Hz. Quindi, il valore della frequenza centrale, sopra riportato, risulta essere la media tra 117.995.850 Hz e 118.245.850 Hz.
A questo punto poi sarà il codice C dell’FFT_vhf_aeronautico che alla fine di ogni ciclo setterà la portante dovuta all’USRP_Commander, cioè quella del passo precedente più 250 Khz e così dopo 76 cicli (19 Mhz / 250 Khz) l’FFT_vhf_aeronautico avrà effettuato lo scanning di tutti i 19 Mhz di banda, rilevando quali, dei 2280 canali, sono attivi. Al generatore di segnale invece, abbiamo variato la frequenza portante coerentemente con la mappa dei canali VHF aeronautici mentre abbiamo lasciato invariati il resto dei parametri.
Il risultato di questo test è stato abbastanza buono perché riconosceva come attivi i vari canali che venivano generati però, anche variando la soglia th (vedi sottocapitolo 4.4 per la modalità di calcolo) o il numero di iterazioni it, risultavano attivi almeno due canali, quello giusto e quello adiacente verso i valori di frequenza più alti. Quindi, inserendo una riga in più di codice che ci permetteva di visualizzare l’energia dei due canali, abbiamo notato che erano valori molto vicini tra loro e quindi non potevano essere discriminati variando semplicemente la soglia.
Allora, dopo aver trasmesso con il generatore di segnale la sola portante, quindi togliendo la modulazione AM, ci siamo accorti che era proprio lei che ‘sporcava’ moltissimo lo spettro ed era lei quindi la causa di tanta energia nel canale adiacente a quello che volevamo ricevere. Per questo abbiamo cominciato ad agire sulla frequenza del segnale modulante e anche sulla potenza di trasmissione associata alla portante riuscendo a trovare dei valori ottimi.
Infatti la nostra waveform funzionava correttamente con potenza di trasmissione pari a -60 dBm, frequenza segnale modulante 1 Khz, numero di iterazioni it = 10 e valore di confronto per le energie dei canali 375*th.
