CAPITOLO 2
SOFTWARE DEFINED RADIO
Introduzione
A far data dall’inizio degli anni novanta del secolo appena trascorso, a partire cioè dalla nascita del progetto di ricerca denominato SpeakEasy I, va sotto il nome di Software Defined Radio (SDR), o più semplicemente di Software Radio, qualunque apparato per radiocomunicazioni le cui funzionalità di livello fisico siano implementate mediante la programmazione di un dispositivo hardware completamente gestibile via software [12]. Citando Eric Blossom, fondatore del progetto GNURadio (che verrà analizzato in dettaglio nel seguito), potremmo dire che l’idea alla base della filosofia SDR è quella di ”portare il software il più possibile vicino allo spettro elettromagnetico”, in altre parole lo sforzo nella progettazione dell’architettura fisica di un sistema SDR consiste nell’eliminare, entro i limiti imposti dallo stato dell’arte delle tecnologie microelettroniche, qualunque componente hardware che sia application specific sostituendolo con dispositivi interamente riprogrammabili e quindi adatti ad una gamma molto ampia di impieghi applicativi, possibilmente anche non previsti in fase di progetto [13].
2.1 Obiettivi della SDR e suoi Possibili Impieghi
Una tale flessibilità non è ovviamente un vantaggio trascurabile se si pensa alla rapidità con cui, ai giorni nostri, si evolvono le tecniche di codifica e modulazione esistenti e se ne aggiungono di nuove.
Si consideri ad esempio quale vantaggio comporti, in ambito militare, disporre di ricetrasmettitori riconfigurabili che consentano di sostituire interamente le proprie tecniche di trasmissione dell’informazione, una volta che quelle in uso siano state compromesse da un’intrusione del nemico, oppure, parimenti, quanto possa essere utile, una volta venuti a conoscenza delle tecniche impiegate dall’avversario, utilizzare hardware già dislocato sul territorio per intercettarne le comunicazioni.
Non stupisce dunque che il primo impulso allo sviluppo di progetti di ricerca in fatto di software
radio sia venuto da ambienti militari.
Non è tuttavia necessario esplorare scenari di tipo battlefield per poter pensare di impiegare le tecnologie software radio al massimo delle loro possibilità: dispositivi handheld realizzati con un
frontend a radiofrequenza specifico per la loro banda di funzionamento e con tutto il resto dello stack OSI implementato in software abbatterebbero di fatto le limitazioni al loro utilizzo imposte
dalla variazione degli standard in uso su base geografica, estendendo così a dismisura le possibilità di mercato del singolo prodotto e lasciandone inalterati (o anche riducendone) i costi di sviluppo. Inoltre, l’industria produttrice di apparati per telecomunicazioni potrebbe trovare di non poco interesse la produzione di componenti per reti wireless capaci di adattarsi alle rapide innovazioni tecnologiche tramite il semplice aggiornamento del firmware installato, magari anche eseguito da un centro di controllo remoto.
Altro vantaggio per niente trascurabile è la possibilità di rendere interoperabili apparati che normalmente non lo sarebbero; in altri termini, potendo gestire e riconfigurare completamente l’hardware responsabile del layer fisico di un modem wireless installato su un pc portatile, esso potrebbe diventare capace di sfruttare la connettività offerta da qualunque rete si rendesse disponibile nelle varie situazioni di funzionamento [13]. In ogni caso l’opportunità in assoluto più coinvolgente e stimolante offerta dalla software radio, e in particolare da una piattaforma per
software radio che sia open source, consiste nella capacità che essa ha di fornire strumenti di
ricerca e sviluppo di tecniche di trasmissione a radiofrequenza, a costi molto contenuti, pressochè a chiunque, mettendo il singolo, o il gruppo di sviluppatori, nella condizione di trovarsi limitato
molto più facilmente dalle proprie conoscenze ecompetenze che non dalle effettive possibilità economiche.
2.2 Architettura Generale di un Sistema SDR
Dal punto di vista architetturale, un sistema SDR può essere modellato secondo il seguente schema:
Figura 1 - Architettura generale di un sistema SDR
Come si nota in figura 1, esistono due percorsi paralleli, uno di trasmissione, l’altro di ricezione, che interessano l’informazione in versi opposti, ossia da e verso il computer host rispettivamente. Il flusso di segnale può essere sia half che full-duplex, a discrezione del progettista, all’interno della porzione di sistema costituita dalla periferica specifica per software radio, ma dovrà necessariamente essere half duplex una volta giunti all’interno del computer host. Questo infatti dovrà dedicare dei timeslot interallacciati all’elaborazione dei campioni relativi ora al lato RX, ora al lato TX.
La separazione tra computer general purpose e periferica (o in ogni caso porzione di sistema) dedicata all’applicazione SDR si ha all’altezza dell’interfaccia tra il BUS (tipicamente PCI o USB) e il primo blocco funzionale della periferica stessa [14,15].
Nel percorso lungo il lato RX dall’antenna verso il computer si incontra per primo il front-end a RF, specifico per l’intera banda di funzionamento, che tipicamente è provvisto di un filtro a basso Q che ne effettua la pre-selezione.
Questo riceve in ingresso dal programma una frequenza centrale compresa tra gli estremi del filtro a basso Q e ne esegue la traslazione a frequenza intermedia, traslando rigidamente attorno ad essa anche il resto delle componenti spettrali della banda selezionata.
Il tutto è implementato secondo lo schema in figura 2, mediante mixer, oscillatore locale a frequenza variabile e, se le frequenze di funzionamento sono sufficientemente alte da richiederlo, LNA collocato in testa alla catena, allo scopo di mantenere bassa la cifra di rumore complessiva del sistema.
Figura 2 - Schema della Conversione a Frequenza Intermedia
È possibile assicurarsi della rigidità della traslazione ottenuta mediante il sistema di cui sopra, considerando la seguente trasformazione come applicata ad ogni generica componente frequenziale
RF
f presente nella banda d’interesse e osservando che le coppie di oscillazioni risultanti si troveranno sempre a distanza fLO dall’oscillazione di partenza, qualunque sia la frequenza di quest’ultima. = + ∗ + = − − 2 2 ) 2 sin( * ) 2 cos( 2 2 2 2 fRFt j fRFt j fLOt j fLOt j LO RF e e e e t f t f π π π π π π = + + + = − − − + − + 4 ) ( 2 ) ( 2 ) ( 2 ) (
2 fRF fLOt j fRF fLOt j fRF fLOt j fRF fLOt j e e e e π π π π = 4 4 ) ( 2 ) ( 2 ) ( 2 ) (
2 fRF fLOt j fRF fLOt j fRF fLOt j fRF fLOt j e e e e + − + − + − − + + π π π π =
t f fRF LO) ( 2 cos( 2 1 + = π ) + cos(2 ( ) ) 2 1 t f fRF − LO π
Una volta ottenuto lo shift a frequenza intermedia, il segnale viene passato ad un convertitore AD che ne opera la digitalizzazione affinchè possa essere trattato via software, ossia gestito dalla successiva catena in formato digitale.
In tale passaggio sarà dunque richiesto il rispetto della condizione di Nyquist per segnali di tipo passabanda, ovvero sarà possibile digitalizzare segnali con larghezza di banda fino a fC 2, essendo
C
f la frequenza di campionamento dell’ADC.
L’FPGA (Field Programmable Gate Array), collocato subito in cascata all’ADC, opera la decimazione, necessaria qualora la banda che si desidera processare sia inferiore a quella fornita dal frontend a RF, e l’ulteriore shift (digitale) in banda base.
All’interno dell’ FPGA è anche possibile configurare circuiti che operino ulteriore pre-processing sul segnale fin qui ottenuto.
Può inoltre essere presente un DSP che esegua algoritmi di processing vero e proprio prima di fornire il flusso di campioni all’hardware general pur pose; tuttavia, se si dispone della necessaria capacità di calcolo, tale operazione può anche essere differita fino all’ingresso nel computer host e delegata a quest’ultimo.
Segue una interfaccia che si occupa di interconnettere la periferica SDR al bus (tipicamente USB o PCI) del computer host, raccordando i flussi di campioni nelle due direzioni.
Il cuore dell’intero sistema è, infine, il comuter host che si fa carico dell’esecuzione di tutte le operazioni ”non ripetitive”, ovvero di quelle operazioni che sono fortemente variabili in funzione dell’uso contingente per cui l’utente sceglie di impiegare il dispositivo SDR.
Essendo dunque il computer alleggerito di compiti gravosi e scarsamente application specific, risulta possibile realizzare sistemi dotati di grande flessibilità ma anche di prestazioni ragguardevoli, e diviene realistica la realizzazione via software di applicativi ad alto costo computazionale.
Il lato TX del sistema è esattamente simmetrico a quello dedicato alla ricezione, ovvero: è il computer host a fornire i campioni del segnale modulatoda trasmettere, l’ FPGA opera la conversione da banda base a frequenza intermedia, il convertitore non è ovviamente ADC ma DAC e il front-end a RF converte il segnale analogico ottenuto, da frequenza intermedia alla frequenza
RF
Tipicamente un amplificatore di potenza, lineare per non danneggiare le modulazioni AM, viene aggiunto dopo il front-end di trasmissione allo scopo di ottenere in antenna la potenza di segnale desiderata.
2.3 Il Progetto GNURadio
Eric Blossom e la nascita del Progetto GNURadio
La nascita del progetto GNURadio risale al 1998 quando John Gilmore, filantropo statunitense dalle notevoli disponibilità economiche (quinto lavoratore in ordine di tempo assunto da Sun Microsystems all’indomani della sua fondazione, fondatore egli stesso di Cygnus Support), decide di supportarne l’avvio con una donazione di 280,000 dollari [16].
La somma viene affidata a Eric Blossom, ingegnere informatico di Berkeley con ragguardevole esperienza in fatto di networking, software per telecomunicazioni e crittografia.
Lo scopo di questo primo investimento è la creazione del codice di base, quello che poi diverrà la libreria gnuradio-core, nonchè provvedere a tutto quanto risulta necessario ad un progetto software
open-source di dimensione planetaria.
La crescita è rapida e ben presto GNURadio viene incluso tra i progetti GNU ufficiali, tutto il software prodotto viene dunque distribuito sotto la ben nota GNU General Public License, caratteristica dei contenuti open source e, più in generale, dei Creative Commons di qualunque natura.
In origine il codice sorgente di GNURadio nasce come un’emanazione del codice Pspectra, toolkit per la realizzazione di applicazioni software radio sviluppato presso l’MIT nell’ambito del progetto
SpectrumWare; il codice di Blossom condivide infatti con quest’ultimo sia una struttura a moduli
intercambiabili con istruzioni eseguite in pipeline, sia l’impiego del linguaggio di scripting ”Python” per l’assemblaggio dei singoli moduli.
Nel 2004 GNURadio ha subito una riscrittura pressochè totale ma, ciò nonostante, probabilmente in virtù della sua notevole praticità e flessibilità, la maggior parte dell’architettura derivata da Pspectra è rimasta inalterata.
È altresì interessante notare come proprio Pspectra si trovi alla base non soltanto del codice
Obiettivi: la filosofia GNULinux e lo Spettro EM
Come qualunque altro progetto open source, GNURadio ha per obiettivo la scrittura collettiva, coordinata e coerente di software che possa essere distribuito a titolo gratuito.
Lo scopo è quello di diffondere il più possibile sia la conoscenza tecnica connaturata al singolo progetto, sia la possibilità di usufruire degli applicativi prodotti nell’ambito del progetto stesso, traendone beneficio.
Dunque, l’utente di software open source non è un semplice utente di tecnologie informatiche, tipicamente, infatti, egli si avvicina al progetto come semplice utilizzatore del prodotto che esso fornisce ma poi, una volta presa confidenza col problema in questione, questi viene invitato a contribuire allo sviluppo di nuovo software e dunque a comprendere in profondità il funzionamento degli strumenti che utilizza, onde la necessità che tutto quanto il codice sorgente sia facilmente leggibile e a disposizione di chiunque sia interessato.
Se quindi immaginiamo di applicare questa filosofia di lavoro non soltanto ad un generico applicativo software (o ad un sistema operativo come Linux), ma anche allo spettro elettromagnetico, comprendiamo pienamente l’idea fondante di GNURadio: fornire, a chiunque disponga della necessaria conoscenza di base, la possibilità di interagire con lo spettro EM, diffondendo così la conoscenza tecnica dei sistemi di trasmissione ed aumentando il numero delle persone in grado di concepire ”buone idee” per l’impiego delle radiofrequenze [14, 18].
2.4 L’Hardware del Progetto GNURadio
Sarebbe comunque un errore pensare che il progetto GNURadio sia soltanto un progetto software; esso infatti, grazie al lavoro di Matt Ettus (ingegnere elettronico fondatore di Ettus research LLC), vede lo sviluppo anche di una piattaforma hardware ben interfacciata con le librewrie software preesistenti.
Tale piattaforma è costituita da una motherboard denominata USRP (Universal Software Radio
Peripheral), che implementa le funzionalità non specifiche per le singole porzioni di spettro EM, e
da diverse daughterboard intercambiabili che costituiscono invece i front-end di ricezione e trasmissione impiegati per le singole bande a radiofrequenza.
La motherboard USRP
Con un prezzo al pubblico che attualmente si aggira intorno ai 550 dollari, l’USRP è la parte più dispendiosa dell’intero sistema ma, se confrontata con qualunque hardware SDR commerciale, risulta sorprendentemente economica, nonchè alla portata non solo del singolo sviluppatore ma persino del singolo studente. Anche le dimensioni fisiche sono contenute, eesendo la scheda un quadrato di circa 20 cm di lato e si interfaccia con il computer host tramite un bus seriale USB 2.0 [14].
La figura 4 mostra l’ USRP sprovvista delle daugtheboards
Sono ben visibili al centro l’FPGA ALTERA mod. Cyclone, con a destra e a sinistra i due integrati che implementano le conversioni AD e DA, più in basso il chip della Cypress che costituisce l’interfaccia USB 2.0 da e verso il PC e, in corrispondenza dei quattro angoli, i quattro slot pronti per ospitare le daughterboard di trasmissione e ricezione.
Per quanto concerne il ramo di ricezione, l’USRP è un sistema di acquisizione dati che si occupa di campionare e quantizzare il segnale a frequenza intermedia fornito dal front-end, di eseguirne lo shift digitale in banda base e di fornire i campioni così ottenuti al computer host, via USB 2.0. Relativamente al ramo di trasmissione, invece, l’USRP riceve i campioni del segnale in banda base sintetizzato dagli algoritmi software in esecuzione nel computer host, li converte a frequenza intermedia, li interpola ed affida il segnale analogico prodotto al front-end di trasmissione e quindi, in cascata, ad un’eventuale catena di amplificazione.
L’USRP è dotata di due canali di ricezione e due di trasmissione, tutti indipendenti ed associati ciascuno ad un singolo slot, ovvero alla daughterboard di volta in volta installata in quello slot. Ciascun canale di ricezione è dotato di due ADC a 64 Msps con risoluzione di 12 bit, in grado cioè di digitalizzare ciascuno una banda di 32 MHz.
Normalmente viene eseguito un campionamento complesso, associando ad un ADC il canale I e all’altro il canale Q, il che significa poter arrivare a digitalizzare una banda di 64 MHz.
È possibile effettuare un campionamento di tipo passa-banda, tuttavia è da tener presente che il costruttore fornisce una frequenza di 100 MHz come limite massimo oltre il quale questo risulta inaffidabile a causa dell’eccessiva degradazione del rapporto segnale/rumore.
Sarà quindi necessario mantenere la frequenza intermedia fIF in uscita dal front-end al di sotto di tale limite.
L’ADC ha un range di ampiezza completo di 2 Volt picco-picco ed è inoltre preceduto da un amplificatore a guadagno programmabile (max 20dB) che consente di sfruttarne l’intera dinamica anche qualora il segnale in ingresso sia particolarmente debole.
Lungo il ramo di trasmissione sono presenti quattro convertitori DAC, due per canale, con frequenza di clock 128 MHz (e dunque frequenza di Nyquist 64 MHz) e risoluzione 14 bit. L’intervallo per la scelta della frequenza intermedia di uscita è tuttavia ristretto al range [0, 50] MHz per facilitare i successivi filtraggi che precedono, nel front-end di trasmisione, lo shift a fRF. Il DAC può fornire un potenza di uscita di 10 dBm ed è seguito da un amplificatore a guadagno programmabile analogo a quello del lato RX.
Probabilmente la parte più importante di tutta quanta l’USRP è l’FPGA: posto al centro della scheda, essa si occupa di svolgere operazioni ripetitive e ad alto costo computazionale (high
bandwidth math, per citare il datasheet fornito da Ettus Research LLC. ) alleggerendo l’hardware
USB 2.0. (L’FPGA è infatti direttamente connessa al chip Cypress FX2 che implementa l’interfaccia USB)
Per quanto concerne il path di ricezione, l’FPGA contiene i Digital Down Converter (DDC): nella configurazione standard prevista dalle librerie del progetto, il primo blocco funzionale è costituito da degli shifter digitali che traslano i campioni dei flussi I e Q fino alla banda base, tramite le necessarie moltiplicazioni complesse. In cascata agli shifter sono presenti i decimatori, che operano secondo un fattore di decimazione N che dovrà essere intero e pari.
I decimatori sono implementati mediante l’impiego di filtri CIC (Cascaded Integrator Comb) che si occupano sia di compiere il filtraggio passabasso necessario per non avere aliasing dalla successiva decimazione, sia di ridurre effettivamente il rate di uscita dei campioni, scartandone il numero richiesto.
I filtri CIC, essendo realizzati mediante il solo impiego di sommatori e ritardi, consentono di raggiungere prestazioni a runtime decisamente elevate.
Lo schema a blocchi del DDC è riportato in figura 5:
I DDC presenti nel progetto sono 4 (anche se nelle implementazioni correnti ne vengono programmati soltanto 2), ciascuno dotato di due ingressi I e Q.
Tra gli ADC e i DDC è interposto un multiplexer (come mostrato in figura 6) che consente di connettere l’uscita di qualunque ADC all’ ingresso di qualunque DDC, fornendo una notevole libertà nella definizione dei canali di ricezione (reali o complessi; provenienti da uno o da due
front-end). Il settaggio del multiplexer viene eseguito direttamente in fase di scripting Python, tramite il
metodo usrp.set mux() presente nella libreria gr-usrp.
Figura 6 - Multiplexer interposto tra i front-end e i DDC
Purtroppo un fattore limitante di rilievo è costituito dalla larghezza di banda disponibile sul BUS USB che, nella sua versione 2.0, è in grado di fornire fino ad un massimo di 32 MiBps. Ciò significa che, essendo i campioni rappresentati come interi con segno su 16 bit in formato complesso IQ (16 bit per il flusso I e 16 bit per il flusso Q), il massimo sample rate disponibile è 8 Msps complessi, ovvero una banda spettrale di larghezza massima 8 MHz, sebbene l’ USRP possa permettersene 64.
Qualora si impieghino canali multipli (fino a 4 secondo le specifiche di progetto), i campioni in uscita sul bus sono interallacciati secondo la trama:
Relativamente al Path di trasmissione, i soli blocchi presenti all’interno dell’ FPGA sono gli interpolatori, mentre i Digital Up Converter (DUC) si trovano all’interno dei chip AD9862 collocati ai lati dell’ FPGA.
L’uscita di ciascun interpolatore può essere instradata verso uno qualunque dei DUC tramite un
multiplexer simile a quello di ricezione.In sintesi, quanto detto riguardo alla struttura della motherboard puòessere visualizzato tramite lo schema di figura 7 [14,19].
Figura 7 - Schema a blocchi dell’intera USRP
2.5 Il Software del Progetto GNURadio
Prevedibilmente, la parte principale di un sistema per software radio è appunto il suo software, e GNURadio non fa certo eccezione.
Vediamone dunque i dettagli.
Scripting Python, Programmazione C++, interfaccia SWIG
Come già ricordato durante la trattazione precedente, l’architettura fondamentale del software GNURadio è la stessa del toolkit per software defined radio denominato Pspectra e sviluppato allo MIT nell’ambito del progetto SpectrumWare [15].
L’analogia tra i due progetti consiste principalmente nell’idea decisamente pratica ed efficiente di combinare, nella realizzazione del sistema SDR complessivo, l’impiego di due linguaggi di
programmazione. Uno di questi è un vero e proprio linguaggio per la compilazione di programmi eseguibili in codice macchina, il C++, mentre l’altro, il Python, è un linguaggio di scripting, ovvero non prevede la compilazione di un codice sorgente ma, a runtime, le righe di codice vengono affidate ad un interprete che si occupa di istruire la macchina conformemente al loro contenuto. Da tale descrizione risulta chiaro come, a parità di algoritmo da eseguire, il C++ sia decisamente più performante del Python; si capisce anche però come invece sia Python a vincere in fatto di flessibilità e riconfigurabilità ad alto livello della struttura del programma.
Considerando che un sistema SDR richiede proprio entrambe queste caratteristiche, nasce spontanea l’esigenza di disporre di entrambi i linguaggi di programmazione. E infatti è proprio questa la scelta che è stata compiuta. La struttura di GNURadio si compone infatti di Moduli software che implementano i reali blocchi funzionali del sistema ed hanno, tipicamente, un costo computazionale piuttosto rilevante.
Tali moduli vengono dunque scritti in C++ allo scopo di massimizzarne l’efficienza e sono messi gratuitamente a disposizione di tutti i partecipanti al progetto, che potranno utilizzarli all’interno delle loro applicazioni.
Le applicazioni sono invece scritte in Python (in wxPython se si desidera aggiungere anche un’interfaccia grafica), esso infatti viene utilizzato per l’implementazione del flow graph, il diagramma di flusso che interconnette i vari blocchi funzionali definendo e rendendo effettivamente operativa l’applicazione desiderata [13,15].
Essendo poi irrisorio il costo computazionale dell’interconnessione dei singoli blocchi, eventuali inefficienze del Python risultano ininfluenti, e comunque agiscono soltanto una tantum, ovvero all’avvio dell’applicazione.
Si riesce così a coniugare la grande flessibilità e pulizia del linguaggio di scripting con l’efficienza dei singoli blocchi funzionali, già compilati in codice macchina e disponibili tra le librerie del progetto.
Per un esempio di scripitng Python si veda il capitolo 3.
Resta il problema di come interfacciare blocchi di codice binario e scripting testuale: tale problema è affidato ad un ulteriore layer di software, denominato SWIG, anch’esso open source e invocato soltanto durante la fase di inizializzazione dell’applicazione.
In sintesi si può quindi affermare che, salvo casi specifici di variazione del flow-graph ”on the fly”, durante la fase di inizializzazione, SWIG e Python allestiscono la struttura complessiva di un sistema i cui singoli componenti, una volta inizializzati, operano al massimo delle possibilità offerte dall’hardware general purpose.
Alcune Notizie sul Python. Python è un linguaggio di scripting open source e multipiattaforma, utilizzato per applicazioni a medio-basso costo computazionale quali ad esempio: accesso a database (molto spesso via web), sviluppo di contenuti web (e.g. Plone è uno strumento di Pyhon), sviluppo di interfacce grafiche, scripting per calcolo tecnico-scientifico, gestione di socket in applicazioni di rete.
Python nasce per sistemi Unix-like ma funziona anche sotto Windows e MacOs, pertanto esso consente al software GNURadio di poter essere utilizzato e scritto anche su piattaforme diverse da quella nativa GNU/Linux.
Tra gli utilizzatori più noti di Python figurano[20,21]:
• la NASA
• il New York Stock Exchange
• AstraZenca
• Honeywell
Le Librerie del Software Gnuradio
Il toolkit GNURadio è diviso in librerie che assolvono a specifiche funzioni, ciascuna di esse viene fornita all’utente/partecipante del progetto sotto forma di codice sorgente che l’utente stesso può leggere, e modificare se lo ritiene opportuno, prima di passare a compilarlo e installarlo sulla propria macchina.
Di seguito si fornisce una breve sintesi delle funzioni delle librerie più importanti.
• gnuradio-core: è la libreria principale, contiene la maggior parte del software eseguito a runtime e tutti i blocchi di signal processing software;
• usrp: contiene il codice per l’inizializzazione e il controllo dell’ USRP, per la programmazione dell’ FPGA e il firmware;
• gr-usrp: è la libreria contenete l’interfaccia tra l’ USRP ed il codice GNURadio;
• gr-wxgui: contiene il framework per la realizzazione delle interfacce grafiche utente da includere nelle applicazioni gnuradio e, inoltre, i blocchi necessari a visualizzare l’andamento del segnale acquisito (in realtime) sia nel dominio del tempo che nel dominio della frequenza [22].
Operatori Matematici già implementati
Allo stato delle cose sono già disponibili come blocchi funzionali implementati all’interno della libreria gnuradio-core, i seguenti operatori matematici:
• Sommatore di sequenza costante ad un flusso di campioni;
• Sommatore di n flussi di campioni (richiesto lo stesso sample rate e lo stesso formato dei dati);
• Moltiplicatore per sequenza costante;
• Moltiplicatore di n flussi di campioni (richiesto lo stesso sample rate e lo stesso formato dei dati);
• Divisore di n flussi di campioni (richiesto lo stesso sample rate e lo stesso formato dei dati);
• Funzione logaritmo (calcola il logaritmo in base 10 di un flusso di campioni reali con rappresentazione in virgola mobile);
L’impiego di tali operatori avviene secondo la convenzione del progetto GNURadio, ovvero definendo i blocchi tramite parametri d’ingresso da fornire alle classi C++ che li implementano e, successivamente, includendo tali blocchi all’interno del flow-graph dell’applicazione che si intende realizzare.
Esistono inoltre blocchi che rendono disponibili conversioni fra i vari formati in cui i flussi di campioni possono essere rappresentati [3, 6], ovvero:
• Campioni complessi in formato rettangolare;
• Campioni complessi in formato polare (ampiezza e fase);
• Campioni interi con segno;
• Campioni reali in virgola mobile;
Filtri già implementati
Sono presenti anche diversi blocchi dedicati al filtraggio, in particolare sono stati definiti i seguenti filtri:
FIR • Passa Basso • Passa Alto • Passa Banda • Elimina Banda • di Hilbert • a Coseno Rialzato
• Gaussiano
Le classi che li implementano ricevono in ingresso i parametri significativi del filtro FIR, ovvero il numero di coefficienti della sequenza temporale mediante la quale si esegue il filtraggio, le frequenze di cut off, la larghezza della banda di transizione, un eventuale guadagno diverso da 0 dB, e, dove necessario, la finestra di troncamento da utilizzare [3] (Hamming, Hanning, Blackman o rettangolare).
I I R
Per la definizione dei filtri IIR esiste una classe che riceve in ingresso i vettori dei coefficienti della corrispondente equazione alle differenze, un vettore per i termini autoregressivi e uno per i termini regressivi dell’ingresso, secondo la generica equazione alle differenze:
1.
∑
∑
= = − = − − M K K N K Ky n k b x n k a n y 10 1 ] [ ] [ ] [cui corrisponde la funzione di sistema razionale fratta:
2.
∑
∑
= − = − − = N K K K M K K K z a z b z H 1 0 1 ) (2.6 Front-end a RF
Una parte indispensabile per il funzionamento del sistema SDR basato sull’USRP sono i front-end per la ricezione e la trasmissione dei segnali a radiofrequenza.
Attualmente ne esistono un buon numero, complessivamente in grado di coprire una banda che si estende dalla continua fino a 2.9 GHz, tuttavia la Ettus Research LLC ha annunciato che diversi altri si trovano in fase avanzata di progetto e che, una volta ultimati, sarà possibile accedere ad ulteriori, significative porzioni di spettro.
I front-end (daughterboards) disponibili sono di tre tipi: ricevitori, trasmettitori e ricetrasmettitori. Questi ultimi, una volta collocati sulla motherboard, occupano due slot, uno di trasmissione ed uno di ricezione.
Tutti i front-end sono alimentati direttamente dalla scheda madre.
In figura 8 appare una USRP equipaggiata con un ricetrasmettitore, un ricevitore ed un trasmettitore:
La figura 9 mostra invece una USRP con i 4 front-end separati.
Sono montati due esemplari per ciascuna delle due daughterboards Basic Rx e Basic Tx.
I front-end attualmente disponibili sono:
Basic Daughterboard (TX e RX): Daughterboard presenti sia in versione RX che TX, di fatto non
costituiscono un front-end ma forniscono un interfaccia per collegare all’USRP un qualche tipo di
front-end esterno e maggiormente complicato di quelli disponibili, il collegamento con quest’ultimo
avviene tramite connettore SMA. È anche possibile servirsene per collegare un generatore di segnale.
LFRX, LFTX: Anch’esso presente sia come trasmettitore che come ricevitore, consente di operare in una banda che va dalla continua fino a 30MHz. È dotato di sintonizzatore e dunque costituisce un vero e proprio front-end a RF.
TVRX: È una daughterboard per sola ricezione capace di operare tra 50 e 900 MHz, consente dunque l’accesso, tra l’altro, alle trasmissioni commerciali a modulazione di frequenza, alle trasmissioni televisive, nonchè alle trasmissioni amatoriali e di pubblica utilità in banda VHF e UHF.
DBSRX: Daughterboard per sola ricezione con banda 800 MHz - 2.4 GHz, usata spesso nell’ambito del progetto per applicazioni GSM e monitoraggio di reti IEEE 802.11. Di fatto è pensata per consentire la ricezione delle prime due bande ISM.
Ricetrasmettitori: Vi sono poi le daughterboard integrate per trasmissione e ricezione, generalmente capaci di operare su bande più strette delle precedenti e con potenze di uscita comprese tra 20mW e 200mW.
Segue un breve prospetto degli esemplari ad oggi parte del progetto:
• RFX400 – 400-500 MHz, 100 mW • RFX900 – 800-1000 MHz, 200 mW • RFX1200 – 1150-1450 MHz, 200 mW • RFX1800 – 1.5-2.1 GHz, 100 mW • RFX2400 – 2.3-2.9 GHz, 20 mW
L’aspetto di una qualsiasi di tali schede di trasmissione è riconducibile a quanto mostrato nella figura seguente che, a onor di cronaca, ritrae la RFX1200.
