Views: 0
Un’antenna installata in una buona posizione, un ricevitore SDR, un piccolo computer Linux e una connessione Internet.
Con quattro elementi relativamente semplici è possibile realizzare qualcosa che vent’anni fa avrebbe richiesto apparecchiature costose e infrastrutture dedicate: un ricevitore radio remoto utilizzabile attraverso Internet da più persone contemporaneamente.
È il concetto alla base dei WebSDR.
Ma prima di iniziare bisogna fare una precisazione importante.
WebSDR o “web SDR”?
Nel linguaggio comune si tende a chiamare WebSDR qualsiasi ricevitore SDR utilizzabile attraverso un browser.
WebSDR, con la W e SDR maiuscole, è però anche il nome preciso del progetto sviluppato da Pieter-Tjerk de Boer, PA3FWM.
Il progetto nacque inizialmente per rendere utilizzabile da più radioamatori il radiotelescopio da 25 metri di Dwingeloo per la ricezione EME. Una prima versione HF venne poi installata presso l’Università di Twente alla vigilia di Natale del 2007 e resa pubblicamente nota nel 2008.
La caratteristica rivoluzionaria era, ed è ancora oggi, questa:
molti utenti possono utilizzare contemporaneamente lo stesso hardware ricevente scegliendo indipendentemente frequenza e modo, purché i segnali siano contenuti nella porzione di spettro acquisita dall’SDR.
Non si tratta quindi semplicemente di comandare a distanza una radio.
Se dieci persone si collegano a un normale ricevitore remoto, normalmente tutte condividono la stessa frequenza.
Con un WebSDR possono invece esistere contemporaneamente:
- un utente in CW;
- uno in USB;
- uno in LSB;
- uno in AM;
- altri utenti su frequenze differenti.
Tutti sfruttando lo stesso flusso IQ.
Un chiarimento importante nel 2026
Chi volesse oggi realizzare un server utilizzando precisamente il software originale PA3FWM deve conoscere una limitazione importante.
La FAQ ufficiale WebSDR informa che la distribuzione del software server è stata temporaneamente sospesa. L’autore spiega che l’ultima versione distribuibile è ormai piuttosto datata, anche se lo sviluppo del WebSDR dell’Università di Twente continua. L’ultima versione distribuita pubblicamente ai gestori già autorizzati è indicata come versione 11.
Di conseguenza questo articolo utilizzerà “WebSDR” anche nel suo significato più generale:
un ricevitore Software Defined Radio reso utilizzabile attraverso il Web.
Per un nuovo progetto nel 2026 esistono diverse possibilità, tra cui OpenWebRX, già trattato in un precedente articolo, oppure altre piattaforme web SDR.
Ma indipendentemente dal software, l’architettura RF e informatica di una buona stazione remota rimane sostanzialmente la stessa.
Come funziona un WebSDR
Lo schema fondamentale è:
ANTENNA
↓
FILTRI / PRESELETTORE
↓
SDR
↓
SERVER LINUX
↓
SOFTWARE SDR WEB
↓
ROUTER / FIREWALL
↓
INTERNET
↓
BROWSER DELL’UTENTE
L’antenna riceve lo spettro RF.
L’SDR converte una determinata porzione di quello spettro in campioni digitali I/Q.
Il server elabora il flusso.
Il software crea i singoli ricevitori virtuali richiesti dagli utenti.
Internet trasporta verso ciascun utente solamente quanto necessario:
- audio;
- waterfall;
- dati di controllo;
- informazioni dell’interfaccia.
L’intero flusso IQ dell’SDR normalmente non viene inviato a ciascun utilizzatore.
Ed è proprio questo a rendere il sistema scalabile.
Il concetto chiave: la larghezza di banda istantanea
Una delle idee più importanti da comprendere è questa:
un SDR non riceve necessariamente tutto il proprio range di sintonia contemporaneamente.
Un ricevitore può magari essere sintonizzabile fra 500 kHz e 1,7 GHz, ma non significa affatto che acquisisca contemporaneamente 1,7 GHz di spettro.
Prendiamo come esempio un RTL-SDR.
Il datasheet dell’RTL-SDR Blog V4 indica una larghezza di banda stabile di circa 2,56 MHz, con possibilità di arrivare a circa 3,2 MHz accettando potenziali perdite di campioni.
Questo significa che, fissata una determinata frequenza centrale, possiamo visualizzare contemporaneamente una finestra larga pochi MHz.
Non l’intero spettro radio.
Anche la FAQ ufficiale WebSDR sottolinea che l’operatore sceglie la frequenza centrale e gli utenti possono muoversi soltanto all’interno della porzione effettivamente trasferita dall’hardware al server.
Primo progetto: WebSDR economico VHF/UHF
Partiamo dalla configurazione più semplice.
Hardware
Possiamo utilizzare:
- RTL-SDR;
- Raspberry Pi o mini PC;
- antenna;
- alimentatore;
- connessione Ethernet.
Uno schema potrebbe essere:
ANTENNA VHF/UHF
↓
RTL-SDR
↓
USB
↓
RASPBERRY PI
↓
ETHERNET
↓
ROUTER
Con una spesa relativamente contenuta possiamo realizzare un ricevitore remoto capace di coprire, a seconda della configurazione:
- banda aeronautica;
- 2 metri;
- 70 centimetri;
- APRS;
- satelliti;
- beacon;
- servizi locali ricevibili legalmente;
- segnali digitali radioamatoriali.
Quale RTL-SDR?
Per anni uno dei riferimenti è stato l’RTL-SDR Blog V4.
Tecnicamente è interessante perché utilizza:
- ADC RTL2832U a 8 bit;
- tuner R828D;
- TCXO da 1 ppm;
- ingresso SMA;
- bias tee;
- front-end suddiviso per HF/VHF/UHF;
- upconverter interno per HF;
- copertura dichiarata da circa 500 kHz a 1,766 GHz.
Occorre però considerare che RTL-SDR Blog ha annunciato nel maggio 2026 la fine produzione del V4, legata alla disponibilità del tuner R828D. Pertanto le caratteristiche del V4 sono ancora un ottimo riferimento tecnico, ma non va considerato necessariamente il modello da acquistare per un nuovo progetto.
Otto bit: attenzione al dynamic range
L’RTL2832U utilizza un ADC a 8 bit.
Per moltissime applicazioni è sufficiente.
Ma quando colleghiamo il dongle a un’antenna esterna molto efficiente possono emergere i suoi limiti.
Immaginiamo di voler ascoltare un debolissimo segnale radioamatoriale mentre, nelle vicinanze, esiste un trasmettitore broadcast molto potente.
Il front-end può saturare.
Sul waterfall potremmo vedere:
- segnali inesistenti;
- repliche;
- immagini;
- intermodulazioni;
- aumento apparente del noise floor;
- perdita dei segnali più deboli.
La stessa FAQ del progetto WebSDR raccomanda particolare attenzione all’uso degli RTL-SDR proprio a causa del loro dynamic range relativamente limitato.
Per questo un buon WebSDR non è solamente:
antenna + dongle.
Molto spesso serve qualcosa in mezzo.
Filtri e preselettori
Uno dei miglioramenti più efficaci consiste nell’inserire filtri RF.
Per esempio:
WebSDR dedicato ai 2 metri
ANTENNA
↓
BAND-PASS 144 MHz
↓
SDR
Il filtro attenua segnali forti molto lontani dalla banda desiderata.
Ricevitore aeronautico
ANTENNA 118-136 MHz
↓
BAND-PASS AIRBAND
↓
SDR
Ricevitore ADS-B
ANTENNA 1090 MHz
↓
FILTRO 1090 MHz
↓
LNA
↓
SDR
Più restringiamo la porzione di spettro realmente necessaria, più diventa facile proteggere un ricevitore economico dal sovraccarico.
WebSDR HF: la situazione cambia
Le HF sono più impegnative.
Un’antenna a larga banda può raccogliere simultaneamente segnali fortissimi provenienti da:
- onde medie broadcast;
- broadcasting internazionale;
- stazioni radioamatoriali;
- servizi professionali;
- disturbi locali.
Per realizzare un buon ricevitore HF pubblico sarebbe preferibile un SDR dotato di:
- ADC con maggiore risoluzione;
- elevato dynamic range;
- buon front-end;
- filtri adeguati;
- oscillatore stabile.
L’RTL-SDR può essere utilizzato sperimentalmente anche sulle HF, ma per un WebSDR HF destinato a funzionare 24 ore su 24 con una buona antenna può avere senso passare a hardware di categoria superiore.
Quanto è importante l’antenna?
Moltissimo.
Anzi, spesso più dell’SDR.
Un ricevitore economico installato in un sito radioelettricamente silenzioso può dare risultati incredibilmente superiori a un SDR costoso collocato nel centro di una città piena di RFI.
Il vantaggio di una stazione remota consiste proprio nella possibilità di scegliere la posizione.
Una postazione ideale dovrebbe avere:
- basso rumore elettromagnetico;
- distanza da inverter e fotovoltaico;
- distanza da linee elettriche disturbanti;
- buona apertura verso l’orizzonte;
- possibilità di installare antenne adeguate;
- rete Internet stabile;
- alimentazione affidabile.
Raspberry Pi o mini PC?
Il progetto originale WebSDR prevede Linux e può funzionare anche su Raspberry Pi. La documentazione ufficiale indica, come riferimento storico, che un Raspberry Pi 4 risultava sufficientemente veloce per gestire circa 2 MHz provenienti da un RTL-SDR, mentre un Raspberry Pi 3 era limitato indicativamente a circa 1 MHz.
Nel 2026, per un nuovo progetto, sceglierei comunque il computer in base al carico reale.
Raspberry Pi
Ottimo per:
- un solo SDR;
- pochi MHz;
- pochi utenti;
- consumi ridotti;
- installazioni alimentate anche da sistemi off-grid.
Mini PC x86
Preferibile per:
- molti utenti;
- più SDR;
- diversi decoder;
- registrazione;
- database;
- servizi accessori;
- VPN;
- reverse proxy;
- monitoraggio;
- maggiore margine futuro.
Un piccolo mini PC moderno spesso consuma comunque pochissimi watt.
Ethernet, non Wi-Fi
Per una stazione permanente utilizzerei, quando possibile:
Ethernet cablata.
Il Wi-Fi introduce un elemento di incertezza inutile.
Una postazione remota dovrebbe essere progettata con l’obiettivo:
deve funzionare per mesi senza che qualcuno debba andare fisicamente a riavviarla.
Ethernet tende ad offrire:
- maggiore stabilità;
- minore latenza;
- meno problemi di associazione;
- meno interferenze;
- diagnosi più semplice.
Quanta banda Internet serve?
Il WebSDR originale fornisce una stima interessante.
Con waterfall lento, l’autore indica indicativamente circa 100 kbit/s di upload per singolo utente. Il consumo effettivo dipende naturalmente dal numero di waterfall e dalla loro velocità.
Quindi, molto grossolanamente:
10 utenti:
≈ 1 Mbit/s
50 utenti:
≈ 5 Mbit/s
100 utenti:
≈ 10 Mbit/s
Non sono valori da utilizzare come dimensionamento contrattuale preciso, ma fanno capire perché una normale connessione FTTH possa tranquillamente sostenere una piccola stazione pubblica.
Il problema può essere invece una connessione 4G/5G con:
- CGNAT;
- upload variabile;
- limiti di traffico;
- IP non raggiungibile.
Non inviare l’intero flusso IQ su Internet
Un errore concettuale sarebbe pensare:
“Metto l’SDR in campagna e mando tutto il suo IQ a casa.”
Possibile? Sì.
Sempre conveniente? No.
Un flusso IQ è enormemente più pesante dell’audio destinato all’utente.
La documentazione WebSDR porta un esempio significativo: appena 96 kHz di spettro, campionato con I e Q a 16 bit, richiede già nell’ordine di 3 Mbit/s di dati grezzi.
Con diversi MHz la quantità cresce drasticamente.
È quindi molto più efficiente elaborare il segnale vicino all’SDR e inviare via Internet soltanto il risultato necessario ai vari utenti.
Struttura di rete consigliata
Una buona architettura potrebbe essere:
INTERNET
↓
ROUTER
↓
FIREWALL
↓
REVERSE PROXY HTTPS
↓
SERVER SDR
↓
USB / ETHERNET
↓
RICEVITORE
Non pubblicherei direttamente tutti i servizi del server.
Il principio è:
esporre solo ciò che realmente serve.
HTTPS
Se il ricevitore è pubblico, utilizzerei HTTPS.
Un reverse proxy come soluzione architetturale permette di:
- terminare TLS;
- gestire il certificato;
- utilizzare un dominio;
- centralizzare i log;
- applicare eventuali limiti;
- separare OpenWebRX/WebSDR dal collegamento diretto a Internet.
Per esempio:
https://sdr.miosito.it
anziché:
http://123.45.67.89:8073
È una soluzione più ordinata e più facilmente manutenibile.
CGNAT: il nemico delle stazioni remote
Molte connessioni mobili non forniscono un vero indirizzo IPv4 pubblico.
Il router riceve un indirizzo appartenente alla rete interna dell’operatore.
In questo caso il port forwarding potrebbe non funzionare.
Le alternative comprendono:
- IPv6;
- VPN;
- tunnel;
- VPS esterno;
- servizi di reverse tunnel.
Prima di installare fisicamente una postazione in montagna conviene quindi verificare come sarà realmente raggiungibile da Internet.
Sicurezza
Un WebSDR pubblico è un server Internet.
Va quindi trattato come tale.
Alcune regole basilari:
- sistema operativo aggiornato;
- password amministrative robuste;
- SSH con chiavi;
- root login remoto disabilitato;
- firewall;
- porte inutili chiuse;
- software aggiornato;
- backup;
- log;
- rete possibilmente separata dagli altri dispositivi.
Non collegherei mai un server pubblico direttamente alla LAN che contiene:
- PC personali;
- NAS;
- videosorveglianza;
- domotica;
- documenti.
Una VLAN dedicata è una soluzione estremamente sensata.
Alimentazione: il problema dimenticato
Possiamo realizzare il miglior WebSDR del mondo e perderlo al primo micro-blackout.
Per una stazione seria servono:
- buon alimentatore;
- protezione sovratensioni;
- UPS;
- eventualmente batteria;
- possibilità di riavvio remoto.
Una configurazione interessante:
230 V
↓
UPS
↓
alimentatore DC
↓
server + SDR + router
Se il consumo è basso, un piccolo UPS può offrire un’autonomia sorprendentemente elevata.
Watchdog
La postazione remota deve essere capace di recuperare autonomamente.
Un watchdog può controllare:
- connessione Internet;
- processo SDR;
- temperatura CPU;
- disponibilità USB;
- spazio disco.
Se qualcosa si blocca:
- riavvia il servizio;
- se non basta, riavvia il server;
- come ultima possibilità, effettua power-cycle.
È molto meglio che percorrere cinquanta chilometri per togliere e reinserire una spina.
Temperatura e installazione esterna
Un Raspberry Pi chiuso dentro una scatola stagna esposta al sole estivo può raggiungere temperature importanti.
Occorre quindi pensare a:
- ventilazione;
- dissipazione;
- condensa;
- umidità;
- insetti;
- sovratensioni;
- fulmini.
L’SDR dovrebbe essere installato il più vicino possibile all’antenna quando questo permette di ridurre le perdite RF, ma bisogna contemporaneamente proteggerlo dall’ambiente.
Alimentare un LNA tramite Bias-Tee
Molti SDR consentono di alimentare un preamplificatore direttamente attraverso il cavo coassiale.
L’RTL-SDR Blog V4, per esempio, dispone di un bias tee software da circa 4,5 V con corrente dichiarata fino a 180 mA.
Lo schema diventa:
SDR
↓
COASSIALE + DC
↓
LNA VICINO ALL’ANTENNA
↓
ANTENNA
È particolarmente utile su VHF/UHF/SHF, dove le perdite del cavo possono essere importanti.
Attenzione: un LNA non cura tutto
Se davanti all’SDR abbiamo già segnali troppo forti, aggiungere un amplificatore può peggiorare drasticamente la situazione.
Il LNA va utilizzato quando serve realmente a migliorare il noise figure complessivo del sistema.
Non semplicemente per “vedere il waterfall più alto”.
Ricevitore pubblico oppure privato?
Privato
Se deve essere utilizzato solo dal proprietario:
VPN.
È probabilmente la soluzione migliore.
Non è necessario esporre il servizio a tutto Internet.
Pubblico
Se vogliamo offrire il ricevitore alla comunità:
- dominio;
- HTTPS;
- informazioni sulla stazione;
- limiti utenti;
- monitoraggio;
- pagina di stato;
- eventuale sistema anti-abuso.
Un progetto concreto a basso costo
Potremmo partire da:
- antenna VHF/UHF;
- RTL-SDR compatibile;
- Raspberry Pi 4/5 o mini PC;
- SSD;
- Ethernet;
- Linux;
- software SDR web;
- piccolo UPS.
In seguito aggiungere:
- filtri;
- LNA;
- GPSDO;
- seconda antenna;
- secondo SDR;
- sensori ambientali;
- monitoraggio remoto.
La cosa importante è partire semplice.
Un progetto HF più serio
Per una postazione HF destinata ad essere realmente utile:
ANTENNA HF
↓
PROTEZIONE
↓
COMMON-MODE CHOKE
↓
PRESELETTORE / FILTRI
↓
SDR CON BUON DYNAMIC RANGE
↓
MINI PC
↓
SERVER SDR
↓
HTTPS
↓
INTERNET
Questo è già un sistema di livello decisamente superiore.
La posizione prima dell’hardware
Prima di acquistare l’SDR più costoso disponibile, farei un esperimento.
Porterei un ricevitore portatile o un SDR alimentato a batteria nel luogo scelto e confronterei il noise floor con quello domestico.
Potremmo scoprire che a casa, sugli 80 metri, abbiamo:
S7 di rumore
mentre nella postazione remota:
S2-S3.
Questo miglioramento vale infinitamente più del passaggio da un dongle da poche decine di euro a un ricevitore da centinaia di euro.
Condividere la ricezione
Ed è qui che un WebSDR assume una dimensione particolarmente radioamatoriale.
Un’ottima postazione montana può diventare utile non soltanto al proprietario ma a un’intera comunità.
Può essere utilizzata per:
- confrontare propagazione;
- monitorare beacon;
- seguire aperture VHF;
- ascoltare satelliti;
- attività didattica;
- dimostrazioni;
- studio delle antenne;
- ricezione HF;
- sperimentazione.
Un’antenna e un ricevitore diventano una risorsa condivisa.
WebSDR e stazione trasmittente: non sono la stessa cosa
È importante ricordarlo.
Un WebSDR è principalmente un ricevitore.
Non dobbiamo confonderlo con:
- remote station;
- remote transceiver;
- sistema CAT remoto;
- stazione TX controllata via Internet.
Consentire la trasmissione introduce problematiche completamente differenti:
- autorizzazioni;
- controllo PTT;
- sicurezza;
- watchdog;
- interlock;
- potenza;
- gestione dell’antenna;
- rispetto della normativa.
La sola ricezione è immensamente più semplice.
Conclusioni
Costruire un proprio WebSDR significa mettere insieme almeno cinque mondi:
radiofrequenza
SDR
Linux
networking
Internet
Ed è proprio questo a renderlo uno dei progetti più completi che un radioamatore possa affrontare.
Si può iniziare con:
RTL-SDR + Raspberry Pi + antenna
e arrivare a una stazione con:
- più ricevitori;
- filtri professionali;
- GPSDO;
- server ridondante;
- UPS;
- VPN;
- accesso pubblico;
- centinaia di utenti.
La tecnologia SDR ha reso possibile qualcosa che pochi decenni fa avrebbe richiesto una quantità enorme di apparecchiature.
Oggi il vero limite non è più soltanto l’hardware.
È la qualità con cui sappiamo progettare l’intero sistema.
Ed è qui che il radioamatore torna a essere ciò che dovrebbe essere: non soltanto utilizzatore di una radio, ma sperimentatore di telecomunicazioni.