Uno dei vantaggi dei ricevitori digitali SDR (acronimo di Software Defined Radio) è costituito dalla relativa facilità con cui è possibile remotizzare il blocco di ricezione.
Spostare l’elettronica che gestisce il front-end di ricezione in prossimità dell’antenna ha innegabili vantaggi. Il più importante è sicuramente costituito dalla riduzione delle perdite della linea di discesa e che può essere estremamente penalizzante alle alte frequenze. Altrettanto importante è quello di allontanare il ricevitore dalle tante sorgenti di rumore radio che abbiamo oggi nelle nostre abitazioni – come alimentatori switching o lampadine LED, ma anche tablet e smartphone, ottenendo così una ricezione più pulita.
Una volta digitalizzati, i segnali possono essere trasferiti ovunque senza perdite di qualità. Grazie alla loro natura numerica, non dovrebbe esserci differenza che vengano trasferiti per pochi metri, o migliaia di chilometri. In realtà, però, un ‘ma’ rimane: la banda necessaria.
I ricevitori SDR operano su uno spettro relativamente ampio di frequenza. I ricevitori basati sull’RTL8032 possono campionare fino a fette di frequenza larghe 3.2MHz. Trasferire i due campioni I e Q per una larghezza di banda così ampia richiede una rete robusta, e potenzialmente può mettere in crisi una connessione WiFi non eccessivamente performante. Trasferirli in sedi remote, via internet, può essere possibile solo riducendo drasticamente la larghezza di banda del campionamento, rinunciando ad una delle caratteristiche più interessanti dell’approccio SDR alla ricezione.
RTL_TCP
Storicamente ci sono due approcci alla remotizzazione SDR. Il primo, specifico per i dispositivi basati sull’RTL8032, è quello di usare una caratteristica dei driver linux della libreria rtl_sdr, che grazie all’utilità rtl_tcp è in grado di utilizzare un flusso TCP per trasferire i campioni da una unità server ad un’altra con il ruolo di client.
Driver e libreria sono disponibili sui repository di debian e derivati e posso essere installati semplicemente via apt-get con il comando
apt-get install rtl-sdr librtlsdr-dev
per lanciarlo è sufficiente indicare l’indirizzo IP del computer su cui è installato
rtl_tcp -a 192.168.1.238
Come era facile aspettarsi, il server genera un traffico di rete significativo, che arriva a ~33Mbps sostenuti per un campionamento di 2MHz di larghezza:
SoapySDR
E’ una libreria di supporto hardware independent e multipiattaforma, che può interfacciarsi ad una larga varietà di dispositivi. Nella dotazione software è compreso anche una applicazione in grado di servire client remoti, SoapyRemote.
E’ una soluzione più elaborata rispetto a RTL_TCP: elabora localmente il flusso proveniente dal ricevitore SDR e lo invia ai client – che possono essere più di uno- usando RPC come protocollo e UDP come trasporto. Come client è possibile usare cubicSDR o GQRX.
Anche in questo caso l’installazione è semplice:
apt-get install soapyremote-server soapysdr-tools soapysdr-module-rtlsdr
Allo stesso modo, per metterlo in esecuzione è sufficiente indicare l’indirizzo IP su cui rispondere (o 0.0.0.0 per tutti):
SoapySDRServer --bind="0.0.0.0:1234"
Il carico di CPU dell’elaborazione è proporzionale alla larghezza del campionamento. Il server, peraltro, può usare un singolo core. Questo crea delle limitazioni su CPU di ridotte capacità, per cui sui Raspberry meno performanti non si riesce ad andare oltre i 250kHz di campionamento.
Grazie all’uso di UDP, l’occupazione di banda è leggermente minore di quella di RTL_TCP, ma rimane notevole, visto che per trasferire 2MHz di campionamento servono ~32Mbps sostenuti.
Spyserver
Un approccio completamente diverso è quello seguito da AirSpy, con il proprio software di remotizzazione, spyserver. E’ stato rilasciato alcuni mesi or sono a supporto dei propri prodotti hardware, ma di recente è stato esteso il supporto anche ai dispositivi basati su RTL8032.
Spyserver non è opensource, ma è disponibile in area download di AirSpy precompilato per Linux (amd64, x86) e ARM. Richiede però una CPU di una certa potenza, come quella del Raspberry 3.
L’installazione è comunque semplice, visto che è sufficiente scaricare e scompattare il file giusto, dopo averlo identificato sul sito di airspy:
wget -O spyserver.tgz http://airspy.com/?ddownload=4308
tar xvfz spyserver.tgz
Prima di mettere in esecuzione il software è consigliabile editare il file di configurazione sypserver.config per ottimizzare alcuni valori (come, ad esempio, device_type ed initial_gain), per quanto non indispensabile. Il server non richiede parametri. L’unico client che può connettere uno spyserver è SDR#.
L’occupazione di banda è decisamente ridotta: poco più di 2 Mbps, sempre con 2MHz di campionamento: circa il 6% del traffico generato dalle altre soluzioni e facilmente trasferibile in remoto utilizzando una normale connessione xDSL.
Non meraviglia che dal punto di vista dell’impegno della CPU è risultata l’applicazione più onerosa: 70% di carico, contro il 22% di SoapyServer ed il 2% di TCP_RTL.
Nel file di configurazione è possibile attivare la registrazione del server nella directory del sito di AirSpy per renderlo pubblicamente accessibile. In caso di connessioni multiple, il primo client ha accesso al controllo del ricevitore, mentre i successivi ricevono il solo flusso dei campioni.
Wake on Lan
Operando un sistema remoto, ritengo sia preferibile mantenere la possibilità di potere gestire l’accensione (via wake-on-lan) e lo spegnimento (via ssh) a distanza del sistema remoto. Questo taglia fuori le schede SBC ARM, che non implementano il sottosistema ACPI per il controllo dell’alimentazione. Io ho optato per una vecchia scheda ITX con un processore Atom N720, che ha sia ACPI che una potenza di calcolo sufficiente per tutte e tre le ipotesi. Da tenere presente che sul mercato dell’usato è facile trovare piastre analoghe, a prezzi concorrenziali con le board ARM.
Per abilitare il wake-on-lan è necessario innanzitutto abilitarlo a livello di BIOS, normalmente nella scheda Power, attivando l’accensione tramite LAN:
E’ poi necessario configurare anche la relativa opzione nei driver della scheda, che richiede l’installazione del pacchetto ethtool con il normale comando
apt-get install ethtool
Una volta installato, è bene verificare se scheda e driver supportino l’accensione remota
ethtool eth0 | grep Wake-on
Ethtool restituirà le opzioni supportate e la configurazione della scheda. Le opzioni sono d (disabled), p (PHY activity), u (unicast activity), m (multicast activity), b (broadcast activity), a (ARP activity), and g (magic packet activity) . A noi interessa attivare la g, in modo da abilitare l’accesione via magic packet.
Sui sistemi debian e derivati (io uso e consiglio devuan) recenti è possibile abilitare il wake-on-lan direttamente nel file di configurazione della rete, cioè in /etc/network/interface, aggiungendo il parametro ethernet-wol g fra quelli di configurazione dell’interfaccia:
#The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 192.168.1.238
netmaks 255.255.255.0
gateway 192.168.1.254
ethernet-wol g
Per potere accendere il computer via wake-on-lan è necessario annotare l’indirizzo fisico (MAC) della scheda di rete, che può essere ricavato dal comando ip addr show eth0: nell’immagine che segue è costituito dal gruppo evidenziato in giallo.
Serve solo un piccolo programma che generi il magic packet, disponibili per tutte le piattaforme. Su linux è sufficiente installare il package wakeonlan. Per windows c’è l’imbarazzo della scelta: io suggerisco un tool semplice, in linea di comando, come wol. In entrambi i casi è sufficiente specificare come parametro l’indirizzo MAC del PC da accendere, che deve trovarsi sulla stessa rete locale:
wakeonlan 00:24:8c:c0:d2:19 (linux)
wol 00:24:8c:c0:d2:19 (windows)
Ma…
Rimane un ultimo problema: wake on lan non è in grado di riavviare un PC a cui viene a mancare l’alimentazione elettrica, per cui in caso di black-out il PC deve essere acceso in modo tradizionale. Come aggirare il problema? Io ho scelto questa strada: configurare il PC per riaccensione automatica in caso di black-out, ed attivare un sistema di controllo che, dopo un certo tempo di inattività, provvede a spegnere – correttamente – il PC.
L’accensione automatica in caso di mancanza di alimentazione è una opzione che si trova, normalmente, nella stessa scheda del BIOS del wake on lan.
Per gestire lo spegnimento ho scritto questo semplice shell script, memorizzato in /usr/sbin/autoshutdown:
#!/bin/bash
#autoshutdown (C) 2018 Giorgio L. Rutigliano
#enumerate active connections (ssh, spyserver)
netstat | grep 'ssh\|5555' | grep ESTABLISHED -q ;
if [ $? -eq 0 ]
then
# touch flag file
/usr/bin/touch /tmp/autoshut
fi
# check file last modification time
if [/usr/bin/find /tmp/autoshut -mmin +15]
then
/sbin/shutdown -h now
fi
Il funzionamento è lineare: il comando netstat enumera le connessioni ssh o spyserver attive. Se ve ne sono, viene aggiornato un flag file. Se non ve ne sono, il file viene lasciato inalterato.
Successivamente viene verificata la data di ultima modifica, se è maggiore di 15 minuti, viene avviata la procedura di shutdown.
Il file è inizializzato in fase di avvio del sistema operativo, da un touch inserito in /etc/rc.local, giusto prima di avviare spyserver.
Lo script viene richiamato via cron ogni minuto:
crontab -e
m h dom mon dow command
*/1 * * * * /usr/sbin/autoshutdown
In caso di black-out, il PC si accende automaticamente. Se nei quindici minuti successivi non viene attivata una connessione, al server SDR o SSH, il PC si spegnerà automaticamente, pronto ad un wake-on-lan. Nell’uso normale, il PC si spegnerà autonomamente quindici minuti dopo l’ultima disconnessione, senza necessità di doverlo spegnere esplicitamente.
Buon ascolto!