16 marzo 2007

In margine all'SDRday

Ricevo e pubblico molto volentieri questo commento a margine del mio breve resoconto della grande giornata di Modena, l'SDRday di sabato scorso. Tengo a precisare che il commentatore non è anonimo ma mi ha chiesto di poter mantenere una riservatezza dovuta più che altro alla mancanza di tempo dovuta ai suoi impegni professionali. Un fattore che gli impedirebbe di seguire con attenzione eventuali dibattiti.

"Avere davanti a sé una radio software significa poter contare su una maggiore sensibilità unita a una maggiore dinamica, arrivare a demodulare segnali che non farebbero nemmeno il solletico a un demodulatore a diodo, ridurre un fenomeno rovinoso per il DXer come lo "splatter" da canali adiacenti, grazie alla sparizione delle non linearità associate agli stessi diodi."
Tutto esatto Andrea (ma bisogna citare anche il minore costo, la ripetibilità produttiva, la mancanza di tarature), ma deve essere generalizzato. Intanto, per completezza di informazione il primo convegno in Italia su SDR è stata la 7a Convention di Renon nel 2005 totalmente dedicata allo stato dell'arte che vedo è rimasto tale quale a Modena 2007 (vedi programma su http://www.i-link.it/). Tornando alla questione, SDR significa anche...

I segnali numerici li posso elaborare in due modi, con costi e prestazioni completamente differenti:

A) In logica programmata (DSP su processori particolari o, con tutti i suoi limiti, potenti PC che attualmente possono manipolare, limitando il numero di eleborazioni, segnali compresi tra i 10 e i 20 Khz.

B) In logica cablata. Scolpisco su silicio, su ASIC se si hanno almeno 250.000 Euro (Il componente poi costa 1 euro) oppure su FPGA se vogliamo spendere 400 Euro per il componente vergine e avere alti assorbimenti, calore...

A) è comodo per hobbisti e softwaristi, didattica, università... Ma ad esempio non so se a Modena hanno fornito i tempi di elaborazione del SW? Se un OM vuole trasmettere in CW non può aspettare 1 secondo per trasmettere. Negli anni 90 quando telefonavo in America tramite geostazionario, mi dava fastidio 0,25 sec (oggi con la fibra il problema è superato) si opera in tempo reale e oggi si può fare (filtri, demodulatori, mixer, noise limiter) fino a frequenza di 90 Mhz. Se non si usano FEC i processing delay sono di decine di millesimi di secondo.
Oggi i ricevitori numerici casalinghi (decoder DVB-T e DVB-S e DBV-C e mobile DVB-H, DAB, DMB-T e DRM) sono in logica cablata ed elaborano frequenze massime di una trentina di MHz (alcune radio con DRM hanno logica programmata).
Strano che molti radioamatori in sala ,anche se non esperti, non abbiamo chiesto perché non si fa un trasmettitore numerico? E' molto più semplice di un ricevitore. Forse è poco noto che nel 2002 un radioamatore italiano (ha un azienda progetti) ha realizzato penso il primo trasmettitore radioamatoriale (HF) numerico al mondo in logica cablata, con FPGA poiché come dissi con gli ASIC oltre che grossi investimenti, se si commette un errore tutte le maschere devono essere rifatte, mentre lo schema elettrico su FPGA può essere riprogrammato n volte...
E’ possibile usare un trasmettitore analogico o numerico insieme ad un ricevitore numerico a logica programmata con PC? Gli oscillatori numerici DDS (quelli "digitali" erano i PLL) sono puliti come un oscillatore a quarzo? A Modena hanno fatto vedere la pulizia spettrale degli oscillatori? Hanno quantificato la distorsione? I prodotti d’intermodulazione dovuti agli splatter? Al giorno d'oggi non è possibile realizzare un ricevitore numerico con dinamiche e sensibilità paragonabili a costosi analogici. Poiché al 99 % delle applicazioni non sono richieste performance troppo spinte, i vantaggi del numerico sono notevoli, tenendo poi conto che se utilizziamo una modulazione numerica volente o nolente debbo usare una demodulatore numerico.


Alcune precisazioni sui commenti. Sì, a Modena si è parlato del problema latenze, anche in relazione al problema della commutazione delle antenne. Con un ricevitore analogico "switchare" da un'antenna all'altra porta a immediate ripercussioni in cuffia. Col digitale no, ci sono i tempi di elaborazione che influiscono appunto sulla latenza, sul tempo che intercorre tra commutazione e ascolto delle conseguenze sulla ricezione.
Si è parlato anche di trasmissione (dopotutto SoftRock è un progetto di ricetrans SDR), ma in almeno due casi, se non ricordo male, si è anche precisato che il problema della modulazione e trasmissione è forse meno critico rispetto alle ripercussioni che il trattamento della radiofrequenza e la demodulazione numerica possono avere sulla resa complessiva, sulla qualità della ricezione.
Doveroso il riferimento (mi scuso molto con il gruppo i-LINK Packet Radio Group Alto Adige Südtirol che organizza l'evento) alle giornate di Renon, iniziate addirittura nel 1999 con le prime discussioni sulle tecniche digitali radioamatoriali e un primo cenno alla software radio. Ma il convegno organizzato dall'ARI a Modena ha il merito di aver affrontato al banco di misura proprio la questione del confronto tra ricevitori analogici e numerici. Alcuni intoppi organizzativi non hanno permesso a Marco Bruno di effettuare tutte le misure volute. Per esempio, quella effettuata sul ricevitore SDR RFSpace SDR-IQ sono state pubblicate solo oggi sul sito di Marco (spero che il nostro tecnico lasci ancora per qualche tempo a disposizione di tutti questo documento). Nel corso della sua presentazione introduttiva, Marco ha citato anche le applicazioni SDR in ambito professionale (per esempio il nuovo modello Rohde&Schwarz, un ricevitore di sorveglianza il cui costo è compreso tra i 25 e i 40mila euro), facendo chiaramente capire che i rapporti di forza tra gli approcci analogico e numerico stanno per cambiare radicalmente. I valori misurati in questi mesi, prima e dopo Modema, dimostrano che a parità di costo il rendimento di un progetto SDR può essere enormemente superiore rispetto all'analogico.

3 commenti:

Anonimo ha detto...

Buona Giornata Andrea e all'autore "anonimo" dell'articolo. Era mia intenzione solo puntualizzare o rimarcare sul concetto di ritardo tra ricezione effettiva, dovuta alla elaborazione del segnale da parte del software e il passaggio in trasmissione. Ho costruito lo scorso anno il famoso Firefly di Dan Tayloe, N7VE, Un RTX in CW con SDR nella parte ricezione, puoi trovare info sul mio sito, usandolo spesso posso riferire su questa problematica, il ritardo esiste ed è paragonabile ad un paio di secondi, ho notato che dipende da software a software, ma nel mio caso è tollerabile. Però posso anche riconoscere in certe operazioni questo sarebbe inammissibile, ad esempio “passare” durante un pile-up sarebbe una vera impresa!
Chi invece, come il sottoscritto, preferisce il consueto qso “tranquillo”, i problemi non sussistono.
Comunque credo che quest’aspetto sarà una nuova problematica da risolvere, ovviamente concernete la sezione S , come la definita, Alberto di Bene della SDR., altrimenti non troverà estimatori in una certa branca del radiantismo.

Andrea Lawendel ha detto...

Grazie Giuliano, in effetti come ho precisato in calce al commento di (...) il fattore latenza era stato preso ampiamente in considerazione.
Giuliano cita espressamente il progetto di Dan Tayloe e fa riferimento al suo sito personale. Lo trovate qui:

http://www.ir3ip.net/in3klq/_private/firefly.htm

Anonimo ha detto...

Giuliano,

usando i drivers ASIO e campionando a 96kHz il ritardo è minimo, direi nell'ordine di 200ms.

Il problema del trasmettitore è stato sollevato anche nel breve "replay" della mia presentazione che ho fatto alla domenica mattina. Sono convinto che a) ci sia abbastanza da fare e b) non sia la massima priorità nello sviluppo; comunque diversa gente ha già fatto QSO in CW, SSB e PSK31 con il semplice SoftRock (senza contare gli SDR1000).

Non sono invece assolutamente d'accordo che lo stato dell'arte sia fermo al 2005; HPSDR, SDR-IQ, SDR-X, e parecchi altri progetti (compreso il mio) al tempo non c'erano, ed i programmi di demodulazione erano meno e più arretrati.

73 - Marco IK1ODO