3. La nuova realizzazione: architettura e considerazioni generali
n questo capitolo saranno esposte e motivate le scelte definitive riguardanti l’architettura, le specifiche sulla connettività e l’hardware del sistema, in modo da poter procedere poi allo sviluppo di un prototipo funzionante. I
3.1 Architettura della rete wireless
L’architettura vista in figura 2.5 sarebbe la soluzione ideale, ma presenta un problema di difficile soluzione, legato alla banda complessiva disponibile.
Nel protocollo Bluetooth, infatti, l’audio viaggia su canali dedicati, noti come link SCO (Syncronous Connection Oriented), che implementano dei link punto-punto simmetrici tra il master della piconet ed uno slave specifico. I pacchetti audio sono trasmessi in slot riservati, ad intervalli di tempo regolari, in modo da mantenere la coerenza temporale dell’audio stesso. Ora, a causa della banda complessiva disponibile, nella release 1.1 del protocollo, anche ricorrendo ai pacchetti SCO HV3 che non supportano nessuna ridondanza dell’informazione, non si possono instaurare più di tre link SCO, e comunque instaurare tre link comporterebbe l’esaurimento della banda. Per l’utilizzo della connettività Bluetooth da parte del telefono GSM, l’unica soluzione è dunque la creazione di una seconda piconet, in cui il GSM si comporti da master ed un secondo chipset Bluetooth, su cui è installato il profilo headset, si comporti da slave e comunichi con il DSP
presente nella centralina sulla moto. In questo modo si risolve anche un problema secondario: il software installato in molti telefoni cellulari supporta solo la modalità master, quindi non è possibile connettersi ad una piconet come slave. Se avessimo realizzato la piconet a quattro nodi, si sarebbe rischiata l’incompatibilità con un certo numero di cellulari GSM in commercio, visto che impostare il nodo sulla centralina come slave non avrebbe alcun senso.
Per la realizzazione pratica della piconet a tre nodi si è ritenuta sufficiente la realizzazione trattata nel capitolo 2, della quale è stato adottato anche il software e l’idea di fare riferimento, per i caschi, a due auricolari per telefoni GSM, che implementano il profilo headset.
Resta immutato anche il partizionamento dell’architettura del nodo master (nonché dell’applicazione) tra host e host controller, schema di cui sono già stati illustrati i vantaggi.
3.2 Definizione delle specifiche per l’interfaccia
Per quanto riguarda l’interfacciamento del sistema con il mondo esterno si è detto di voler agevolare, per quanto possibile, l’integrazione con l’elettronica già presente a bordo del motoveicolo. Per far questo è stato deciso di non sviluppare un’interfaccia hardware dedicata, ma piuttosto di sviluppare un protocollo di comunicazione a comandi ed eventi, che viaggino tra il sistema e la moto attraverso un bus seriale RS232. In tal modo qualunque costruttore di motoveicoli potrebbe integrare il sistema su un sua moto, decidendo con la massima libertà come permettere all’utente di controllare le funzionalità che il sistema mette a disposizione e come visualizzare le informazioni sullo stato del sistema stesso. Per il testing è stata emulata una semplice interfaccia con l’applicazione LabView.
Questa filosofia consente, inoltre, una notevole flessibilità dell’applicazione, che può essere aggiornata con nuove funzionalità agendo esclusivamente sul software, senza bisogno di dover riprogettare un’interfaccia che consenta il controllo delle nuove funzioni.
E’ ovvio come questa scelta renda necessaria la disponibilità, da parte del DSP, di una porta seriale aggiuntiva.
3.3 Note su soppressione del rumore e riconoscimento/
sintesi vocale
Lo sviluppo del codice relativo alla soppressione del rumore ed alla sintesi/riconoscimento vocale non compete a questo lavoro di tesi.
Tuttavia, nell’ottica della futura espandibilità del sistema, si è ritenuto opportuno prevedere, nell’architettura così come nella scelta dell’hardware, le risorse di cui tali funzioni potrebbero necessitare. E’ stato quindi deciso di riservare una sorgente audio al prelievo del segnale rumore, inteso, principalmente, come rumore del motore. Questo segnale potrà poi essere opportunamente filtrato in modo da migliorare la qualità complessiva dell’audio.
Effettivamente è nella soppressione del rumore che si incontra l’unico inconveniente dato dall’aver scelto dei semplici auricolari per telefonia cellulari per l’implementazione dei caschi: l’assenza di potenza di calcolo all’interno dei caschi preclude l’intervento sul rumore dato dai fruscii aerodinamici che si odono, appunto, all’interno del casco: l’alternativa, cioè l’integrazione di potenza di calcolo nei caschi, come si vede nel casco sviluppato da BMW, comporta però un notevole appesantimento dell’accessorio, ed un crollo della durata delle batterie, inconveniente
fastidioso proprio nel corso dei lunghi viaggi in cui il sistema potrebbe migliorare di più la comodità dello spostamento.
Da questo punto di vista appare interessante la possibilità, data da alcuni algoritmi [5], di stimare le caratteristiche del rumore (allo scopo, ovviamente, di filtrarlo) dal segnale complessivo voce + rumore, pur non avendo una fonte dedicata al prelievo dall’ambiente del solo segnale rumore;
ciò consentirebbe la delega al DSP di tutte le operazioni, salvando così capra e cavoli (si perdoni l’espressione bucolica).
Ad ogni modo si è preferito avere a bordo del DSP abbastanza potenza di calcolo per implementare efficacemente sia la soppressione del rumore che la sintesi ed il riconoscimento vocale, basate, queste ultime, su un vocabolario di campioni memorizzati o sul riconoscimento di particolari fonemi [6].
Si giunge dunque alla seguente architettura complessiva:
Figura 3.1: architettura del sistema realizzato
3.4 La scelta di un nuovo hardware per il sistema host
In questo paragrafo ci si occupa della scelta dei componenti che dovranno concorrere alla realizzazione fisica del sistema: avendo deciso di lasciare inalterati sia i caschi che l’host controller, la nostra attenzione deve concentrarsi sulla scelta di un sottosistema host in grado di rispondere ai requisiti presentati.
E’ stato escluso il ricorso allo stesso hardware utilizzato per il precedente prototipo, in considerazione dei problemi che questo aveva a suo tempo presentato:
• La potenza di calcolo non è stata ritenuta sufficiente alle nuove funzionalità da implementare;
• Il codec non era in grado di convertire più di due sorgenti contemporaneamente, e comunque il protocollo di comunicazione tra codec e DSP (Audio Codec ’97 Rev 2.1 dela Intel) era eccessivamente complesso, richiedendo uno scambio di dati anche quando non si avevano campioni significativi in ingresso;
• Un’anomalia hardware aveva creato problemi con i trasferimenti in DMA.
In pratica è stata effettuata una ricerca tra i prodotti che i vari costruttori di DSP propongono per la soluzione di questo genere di problemi, tenendo d’occhio, ovviamente il rapporto tra capacità e costo. Si è parlato non a caso di “prodotti” e non di processori, poiché per la realizzazione del sistema non serve solo un DSP, ma tutto un insieme di componenti: volendo stendere una lista di questi componenti con le loro caratteristiche principali, ci si potrebbe limitare ai seguenti:
• Il DSP, che deve disporre di tutta la potenza di calcolo necessaria, ed inoltre deve disporre delle seguenti periferiche:
o tre porte seriali asincrone per le comunicazioni con i due chipset Bluetooth e l’interfaccia esterna;
o una o più porte con cui interfacciarsi al codec che effettuerà le conversioni sui segnali audio analogici;
• Il codec, che deve disporre, almeno, di 4 ingressi ed una uscita analogica:
o GSM cablato (I/O) o Radio(I)
o Navigatore(I)
o Soppressione del rumore(I)
Deve inoltre essere in grado di convertire tutte questa sorgenti contemporaneamente, e di inviare i campioni al DSP con un protocollo di comunicazione di semplice utilizzo;
• La circuiteria di alimentazione del DSP (regolatori di tensione);
• I connettori per l’accesso alla piedinatura dei componenti;
• I circuiti a pompa di carica per la traslazione dai livelli di tensione UART a quelli RS232 (line drivers).
La procedura più intelligente da seguire è quella che consiglia di evitare la realizzazione di un hardware dedicato all’inizio dello sviluppo di un’applicazione: per permettere ciò i costruttori di logica digitale producono dei kit di sviluppo per i loro processori, che consistono in schede su cui sono integrati il DSP con tutta la circuiteria atta alla programmazione, i circuiti di alimentazione e tutta una serie di altri dispositivi che servono a dimostrare le capacità del processore. La ricerca si è dunque limitata a queste schede, in particolare tra quelle prodotte dalla Analog Devices: la
ADSP BF535 EZ-KIT Lite, la ADSP BF533 EZ-KIT Lite e la ADSP BF561 EZ-KIT Lite. Purtroppo nessuna scheda mette a disposizione tre porte seriali asincrone, dunque si è dovuto comunque procedere all’emulazione di tali porte con altre risorse hardware e software, in particolare ricorrendo ad altre porte seriali sincrone; la ADSP BF535 dispone di due UART, ma ne può controllare solo una in DMA, ed inoltre ha a bordo lo stesso codec (che si è detto insufficiente) della scheda con cui era stato realizzato il vecchio host controller, la ADSP 2191. La ADSP BF561 è stata scartata perché si tratta di una scheda multiprocessore, su cui sono integrati due DSP BF561: ovviamente una tale soluzione offre prestazioni molto elevate, ma i con le prestazioni lievitano anche i costi, e considerate le stringenti specifiche in questo campo, questa scheda non è stata considerata adatta ad essere utilizzata.
La scelta è quindi caduta sulla ADSP BF533 EZ-KIT Lite, in considerazione della notevole potenza di calcolo del processore montato, della comunque grande quantità di periferiche e del codec di buone capacità e semplicità di utilizzo. Tutto l’hardware utilizzato verrà comunque descritto nel prossimo capitolo.
