Capitolo 4
Il simulatore
4.1 – Funzionamento del simulatore
Nel capitolo precedente abbiamo analizzato i vari algoritmi utilizzati dal simulatore, il cui schema di funzionamento si andrà ora a descrivere.
Il programma sviluppato nell’ambito di questa tesi riproduce il segnale GPS che un ricevitore vedrebbe in una determinata posizione del globo terrestre
e ad una certa data.
Per far ciò si è scomposto il problema in due fasi, indicate in Fig. 4.1, la prima di inizializzazione e la seconda di generazione dei segnali satellitari.
4.1.1 – Fase di inizializzazione
Lo step iniziale prevede il passaggio al programma della data e della posizione di interesse, inclusi l’effemeride e gli almanacchi relativi. Quindi si ricavano i dati di almanacco per tutti i 32 satelliti, successivamente inseriti nei subframe 4 e 5 secondo le indicazioni dei Parr. 3.2.6, 3.2.7. Se ci sono satelliti non funzionanti, non ci saranno neanche dati di almanacco disponibili e in tal caso si utilizzeranno valori pseudocasuali ponendo a zero il campo health del satellite relativo e indicando, così, al ricevitore di scartare quanto ricevuto perché non significativo.
A questo punto si passa al calcolo dei satelliti in visibilità come visto nel Par. 3.4 e, per ogni satellite visibile nel posto e all’ora voluti, si leggono i relativi dati di effemeride, calcolando e memorizzando le seguenti quantità:
il codice C/A (Par. 3.1)
le pagine, in numero prestabilito, dei dati da trasmettere (Par. 3.2) lo spostamento frequenziale per effetto Doppler (Par. 3.9)
i ritardi atmosferici e di sfasamento dei clock (Parr. 3.7, 3.8).
Fig. 4. 1 – Schema a blocchi del simulatore
Il codice P non viene generato in quanto sostituito da una sequenza pseudorandomica di chip per i motivi già discussi nel Par. 3.1.
4.1.2 – Fase di generazione dei segnali
Utilizzando i dati calcolati al passo precedente si genera, per ogni satellite individuato dall’algoritmo di visibilità, il segnale in banda base, sommando in modulo 2 i dati delle pagine ai chip del codice (C/A o P(Y) a seconda dei casi) e ottenendo così, nell’ipotesi di usare in trasmissione un filtro rect, il simbolo effettivamente trasmesso. A questo punto si realizza il sovracampionamento replicando tale simbolo tante volte quante ne stabilisce la fC calcolata nel Par. 3.5.
Poiché la frequenza di chip è di 1.023 MHz (il discorso qui fatto per il codice C/A può essere riproposto con leggere variazioni anche per il codice P(Y)) si dovrebbero avere
67 campioni/simbolo
C CHIP
f
f = .
In realtà si deve considerare l’effetto Doppler che, come già detto, altera tale numero in misura diversa per ogni satellite. Infatti, per ogni chip si ha un numero di cicli di portante pari a
20.46 MHz 20 cicli/chip 1.023 MHz IF CHIP f f = = ,
ma, se alla portante andiamo ad aggiungere, a titolo esemplificativo, 10 Hz di spostamento Doppler, la durata di 20 cicli e, quindi, di un chip diventa
20 10 Hz) Dopp IF Dopp f f + f ( =
ed in tale intervallo, campionando con passo fC si ottengono
20 66.9672... campioni/chip C IF Dopp f f f ⋅ = + e non più i 67 prima calcolati.
Avendo ogni satellite uno scostamento Doppler diverso dagli altri, si desume che anche il numero di campioni per chip assumerà valori diversi.
Di questo fenomeno nel simulatore si tiene appositamente conto e per ulteriori considerazioni si rimanda al Par.4.2.
L’analisi spettrale, tramite algoritmo FFT,dei singoli segnali così ottenuti
produce lo spettro raffigurato in Fig. 4.2, tipico di un sistema CDMA.
Lo step successivo consiste nel traslare quanto si trasmette a RF, moltiplicando i campioni per il coseno o il seno della portante a seconda che si abbia a che fare con la parte in fase o in quadratura del segnale.
Da ultimo si aggiunge il rumore e, quindi, i vari ritardi (propagazione, atmosferici, sfasamento dei clock) precedentemente relativizzati rispetto a quello del satellite più vicino al ricevitore. il quale risulterà avere sempre, di conseguenza, ritardo nullo.
L’operazione conclusiva della fase di generazione prevede la somma dei singoli segnali per realizzare il segnale digitale globale effettivamente trasmesso e visto dall’ utente GPS.
-120 -100 -80 -60 A m pi ez z a ( d B ) 60x106 50 40 30 20 10 0 Frequenza (Hz)
Per avere dei riscontri sulla buona costruzione dei segnali, quanto generato viene fatto passare attraverso un ricevitore ideale, perfettamente sincronizzato con uno dei satelliti a scelta dell’utente.
Prove effettuate con tale ricevitore hanno permesso di fare una serie di controlli che hanno avuto esito positivo, come dimostrato dal report riportato in Fig. 4.3
Tale file è il prodotto di una funzione interna al ricevitore che si accerta della corretta ricezione di preamboli e parità e dimostra che i parametri ricevuti sono effettivamente uguali a quelli trasmessi (il test è stato fatto a campione, prendendo alcuni parametri in maniera casuale, ma ben distribuiti all’interno del segnale per avere una copertura sufficiente).
Contestualmente a tali controlli si è anche effettuato il calcolo della BER
che ha prodotto la curva di Fig. 4.4 perfettamente corrispondente a ciò che ci si aspetterebbe da un’applicazione GPS che garantisce il perfetto recupero del sincronismo e, perciò, dell’intero guadagno di codice. Ovviamente tale situazione è puramente ideale per cui si discosta dalla curva che si troverebbe nella realtà. 2 3 4 5 6 7 0.001 2 3 4 5 6 7 0.01 2 3 4 5 BER 27 26 25 24 23 22 21 20 C/N0 [dB] Fig. 4. 4 – Curva di BER
4.2 – Simulatore e situazione reale
Per rendere più realistico il simulatore occorrerebbe fare alcune modifiche e aggiunte al programma fin qui esposto. Innanzitutto si dovrebbe
realizzare un filtro in trasmissione diverso da quello rect e che si avvicini ai filtri effettivamente usati nel GPS. Inoltre poiché le effemeridi hanno una
validità che oscilla tra le 2 e le 4 ore, bisognerebbe, nel caso di simulazione di durata maggiore, realizzare una funzione che al momento opportuno cambi il file di ingresso, considerando in tal modo le effemeridi aggiornate.
Infine, anche all’interno dell’intervallo di validità delle effemeridi, sarebbe necessario affinare l’implementazione dell’effetto Doppler e dei vari ritardi che subisce il segnale.
4.2.1 – Effetto Doppler
Se i satelliti fossero immobili, un subframe ricevuto durerebbe 6 secondi, ma, a causa del loro movimento rispetto all’utente, ciò che quest’ultimo vede è qualcosa la cui durata può comprimersi o dilatarsi a seconda che il satellite si avvicini o si allontani. Di questo fenomeno si è tenuto conto variando, come detto nel paragrafo precedente e mostrato in Fig. 4.5 (nel semplice caso di due soli segnali) il numero di campioni per chip da satellite a satellite in relazione al valore del Doppler che, però, si è considerato costante nel corso dell’intera simulazione.
Chiaramente questo non rispecchia la realtà delle cose ed una tecnica da implementare, per migliorare il programma, potrebbe prevedere l’uso di uno scostamento frequenziale costante a tratti e che insegua il Doppler reale. Il valore del intervallo temporale in cui mantenere costante lo scostamento risulta vincolato alla capacità del FLL (in fase di ricezione) di recuperare variazioni impulsive di frequenza solo se queste risultano non eccessive.
Fig. 4. 5 – Implementazione dell’effetto Doppler nel simulatore
La Fig. 4.6 mostra l’andamento del Doppler per il satellite 3 nel giorno 28/04/20051. Si nota che il caso peggiore per la nostra applicazione si ha quando il Doppler è nullo, poiché la curva ha la pendenza massima, pari a ±0.515377 Hz/s. In tale condizioni, se si tenesse costante il valore dello scostamento frequenziale solo per 6 secondi, ricalcolandolo alla fine di tale intervallo, cioè una volta per subframe, esso avrebbe delle variazioni impulsive con ampiezza pari al più a ±3.092262 Hz (±0.515377 Hz/s * 6 s). Questo,
1
Si è considerato la seguente posizione di utente: latitudine 43°46’ 51.4710’’
longitudine 10° 23’ 54.5191’’ altitudine 60.795 m
come si vede in Fig. 4.7 (ottenuta tramite apposita simulazione con un ricevitore software), non creerebbe problemi al FLL nell’ inseguire la frequenza complessiva del segnale.
-4000 -3000 -2000 -1000 0 1000 2000 3000 4000 D o pp le r per il s a te ll ite 3 (H z ) 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Ore del giorno 28/04/2005
Fig. 4. 6 - Andamento giornaliero del Doppler per il satellite 3 nel giorno 28/04/2005
4.2.2 – Ritardi
L’intervallo di aggiornamento di 6 secondi calcolato nel paragrafo precedente per il Doppler in realtà è più che sufficiente anche per i vari ritardi che interessano il segnale satellitare.
Per quanto concerne l’offset di clock, la dipendenza dal tempo (poiché legata a termini (af1, af2) che nel peggiore dei casi sono dell’ordine di 10-11) si
Il ritardo ionosferico, invece, qualora variasse nel tempo, lo farebbe a causa del termine
2 ( 50400) (radianti) PER t x= π − dove PER ≥ 72,000 e 4 4.32 *10 GPStime (sec), sin A (semi-cerchi), cos 0.0137 (semi-cerchi), E 0.11 cos A, 0.416 if 0.416, then 0.416 (semi-cerchi), if 0.416, then 0.416 A=azimu i i u i u i i i i i i t λ ψ λ λ ψ ψ = + = + Φ = − 0.022 + ⎧Φ + Φ ≤ ⎫ ⎪ ⎪ Φ =⎨ Φ > Φ = ⎬ ⎪ Φ < − Φ = − ⎪ ⎩ ⎭ th del satellite, E=elevazione del satellite,
longitudine dell' utente, latitudine dell' utente. u u λ = Φ = -200 -190 -180 -170 -160 -150 -140 D o p p le r (H z ) 8.44 8.42 8.40 Ore del 28/04/2005
Frequenza segnale generato Modo in cui il FLL lo insegue
Poiché nella nostra simulazione l’utente è fermo, e,come si vede in Fig. 4.8, l’elevazione e l’azimuth del satellite sono invarianti in 6 secondi, andando a ritroso con le formule sopra riportate, ψ, Φi e λi risultano costanti. Perciò
l’incremento di sole 6 unità di t, alla fine di ogni subframe, produce una variazione di x tale da rendere lo step di aggiornamento individuato per il Doppler più che buono anche in questo caso.
Per il ritardo troposferico il discorso è molto più semplice, poiché l’unica dipendenza temporale è legata all’elevazione del satellite che abbiamo già visto rimanere sostanzialmente costante in 6 secondi.
-180 -160 -140 -120 -100 -80 -60 -40 -20 0 20 40 60 80 100 120 140 160 180 A m pi ez z a ( °) 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Ore del giorno 28/04/2005
Satellite 3 azimuth elevazione se l'elevazione supera questa retta il satellite è visibile
4.3 – Software VS hardware
L’idea che sta alla base della decisione di implementare un simulatore software nasce da alcune considerazioni di carattere pratico.
Allo stato attuale delle cose, la maggior parte dei simulatori e dei ricevitori GPS utilizzano un apposito circuito hardware per l’implementazione
di tutti gli algoritmi di signal processing. Tra i simulatori più diffusi citiamo gli Spirent le cui caratteristiche fondamentali sono illustrate nel data-sheet di Fig. 4.10 (per ulteriori informazioni vedi [26]).
Fig. 4. 9 – Spirent STR400
Passare ad una architettura software che operi direttamente nel digitale, sia in trasmissione che in ricezione, produce due considerevoli vantaggi.
Da un lato un sensibile abbassamento del costo, dovuto al fatto che un simulatore o un ricevitore software è costituito semplicemente da una serie di moduli di codice da far girare su un qualsiasi computer di medio livello (per gli standard attuali).
Fig. 4. 10 - Datasheet STR4500
Dall’altro un indiscusso incremento della riprogrammabilità dell’intero sistema: una qualsiasi variazione negli standard di trasmissione o ricezione, infatti, richiederebbe la sostituzione del vecchio dispositivo hardware contro una semplice modifica del codice sorgente in quello software.
