Non basta comandare la radio

Nel precedente articolo abbiamo visto come sia possibile distribuire il controllo della stazione su più applicazioni e più dispositivi, utilizzando un livello intermedio che permetta di condividere il CAT della radio, e che distribuire una stazione all’interno della propria rete locale è ben diverso che utilizzarla quando ci si trova dall’altra parte della rete.

Quando si esce dalla rete locale, infatti, il problema cambia radicalmente: non basta più fare parlare i programmi, ma bisogna fare arrivare la stazione radio.

C’è molto altro oltre il VFO

Se una radio fosse soltanto un VFO, un commutatore di modo e un pulsante PTT, la remotizzazione sarebbe un problema relativamente semplice, ma in realtà una moderna stazione radiantistica è una esperienza molto più complessa.

La frequenza è soltanto uno dei parametri che devono essere controllati, mentre un operatore che si trova davanti alla radio utilizza continuamente una quantità di funzioni che spesso non vengono nemmeno percepite come controlli CAT: larghezza e posizione dei filtri IF, roofing filter, IF shift, notch filter, AGC, preamplificatori e attenuatori, noise blanker e noise reduction, RIT e XIT, VFO A/B e split… e l’elenco potrebbe continuare a lungo. Avrete notato che in larga parte sono comandi della sezione ricevente, e sono peraltro proprio quelle funzioni che denotano gli apparati più performanti.  Di per contro i software di controllo CAT, standalone o inglobati in applicazioni, sono generalmente limitati solo alle funzioni basilari.

Una reale remotizzazione, quindi, deve mettere l’operatore in grado di interagire con tutti i controlli della propria radio, e nel modo più naturale possibile: solo in questo modo è possibile replicare a distanza l’esperienza della stazione locale.

Il problema dell’interfaccia radio

Questo è probabilmente il punto più difficile dell’intero problema: se i comandi CAT sono oggi in grado di gestire praticamente tutti i parametri principali delle radio arruali, è al momento arduo di restituire via software una interfaccia che ricordi anche lontanamente quella fisica con la quale l’operatore è abituato a lavorare: possiamo sapere che la radio è sintonizzata a 14.200 MHz, che siamo in USB, che il PTT è disattivato e – casomai – che la larghezza di banda è impostata a 1.8kHz. Ma questo non significa avere davanti agli occhi ciò che vede l’operatore locale. Tutte le radio moderne hanno pannelli operativi complessi: il mio FTdx-1200 ha dieci manopole e 52 pulsanti – senza contare le funzioni a menù. Una remotizzazione degna di questo nome deve essere in grado di replicare in remoto la maggior parte di questi comandi.

E’ oggettivamente complesso costruire una interfaccia remota che possa essere realmente universale. C’è una proposta interessante,  wfview – un progetto open source per controllare via rete alcune radio Icom e Kenwood moderne -ma ha un campo di applicazione molto limitato, ristretto a pochi modelli recentissimi. E scartando a monte i sistemi di controllo inclusi in alcune applicazioni – che come dicevo sono troppo ‘basici’ – le opzioni disponibili sono veramente scarse.

Ad essere più precisi, la mia percezione è che ce ne sia solo uno sufficientemente valido e funzionale: Flrig (ne ho parlato qui),

che, a fronte di una interfaccia spartana secondo i canoni moderni, consente di controllare a distanza la maggior parte delle funzioni disponibili fisicamente sulla radio, e che implementa anche tre gruppi di comandi aggiuntivi (tre pannelli A, B e C), che sono personalizzabili. E dato che rigctld può essere configurato per controllare flrig, anzichè direttamente la radio, é una aggiunta che si integra perfettamente nell’ecosistema che avevamo disegnato nel citato articolo.

C’è da dire, però, che non tutte le radio hanno lo stesso livello di supporto: per come sono nate ed evolute nel tempo, le implementazioni CAT sono infatti molto differenti, agli inizi fornivani giusto accesso alle funzioni base, e poi si sono via via arricchite nel tempo.

Ora che abbiamo virtualizzato anche il pannello di controllo per la radio siamo liberi dai vincoli fisici. Ma quale è la strategia migliore per trasferire l’intero controllo del nostro shack fuori di casa?

Una nota sulla sicurezza

La remotizzazione della stazione passa la maggior parte delle volte attraverso la connessione internet, per cui la soluzione più semplice potrebbe sembrare quella di aprire le porte sul router ed esporre i servizi direttamente online. Vi consiglio, però, caldamente di non farlo: esporre applicazioni su internet senza avere piena contezza delle implicazioni è un grosso rischio, che è bene non sottovalutare. E’ molto più affidabile usare uno strato di rete virtuale privata (VPN, come wireguard o openvpn), che può essere facilmente installata localmente, ed accedere in remoto al controller di stazione attraverso di essa.

I limiti tecnici

Oltre alla sicurezza, Internet introduce però un altro problema, questa volta di natura puramente tecnica: una stazione radiantistica è, almeno in parte, un sistema real time, in cui, cioè avvengono una serie di operazioni in tempi predefiniti. L’operatore non si limita a impartire comandi e ad aspettare che vengano eseguiti: ascolta continuamente il ricevitore, osserva lo spettro, modifica la sintonia, interviene sui filtri e sul guadagno e reagisce a ciò che sta ascoltando.

Quando usiamo la rete per trasportare dei dati, ogni passaggio attraverso la rete introduce un certo ritardo, e soprattutto rende il tempo di consegna dei dati meno prevedibile, a causa principalmente di due fattori:

La latenza

La latenza è semplicemente il tempo che intercorre tra un evento e il momento in cui ne percepiamo l’effetto: se parliamo nel microfono e l’audio arriva alla stazione remota dopo 100 ms, abbiamo una latenza di 100 ms in quella direzione. Se il segnale audio della radio deve arrivare fino alle cuffie attraverso la stessa rete, anche quello avrà un proprio ritardo. Per una normale applicazione informatica  una latenza di qualche decina di millisecondi è generalmente irrilevante, ma in una attività radiantistica, invece, possono diventare percepibili.  Il problema non è necessariamente che la radio risponda lentamente. È che l’operatore non sta più interagendo direttamente con ciò che sta accadendo in radio.

Questo diventa particolarmente evidente in alcune attività: se durante un collegamento SSB, ad esempio, una certa latenza può essere semplicemente fastidiosa, durante un collegamento in CW la situazione è molto più delicata, visto che il rapporto temporale tra ciò che ascoltiamo e ciò che trasmettiamo è parte integrante dell’attività operativa.  Anche nei modi digitali il problema può manifestarsi in modo diverso, perché alcune applicazioni sono molto più tolleranti verso la latenza del controllo CAT rispetto all’audio in tempo reale.

Il jitter

La latenza, però, non è necessariamente il problema peggiore. Una latenza ridotta e costante, tutto sommato, può essere derubricata ad un semplice fastidio. Ma cosa accade se alcuni pacchetti arrivano dopo 50 ms, altri dopo 80 e altri dopo 200? l’esperienza diventa molto meno prevedibile. Questa variazione del ritardo viene chiamata jitter.

Per capirlo intuitivamente, possiamo immaginare di inviare una sequenza di campioni audio a intervalli regolari:

Invio:       |--|--|--|--|--|--|--|--|
               1  2  3  4  5  6  7  8

Arrivo:      |---|-----|-|------|--|---|
               1    2  3    4    5  6

Il ricevitore non riceve più i dati con la stessa regolarità con cui sono stati prodotti, e questo è realmente problematico. Per evitare che questo si traduca immediatamente in interruzioni dell’audio, i sistemi di trasmissione real time utilizzano normalmente un jitter buffer, un’area di memoria in cui si accumulano una piccola quantità di dati prima di riprodurli, in modo da assorbire le variazioni temporali.

Ma c’è un compromesso inevitabile: più grande è il buffer, maggiore è la capacità di assorbire il jitter; ma allo stesso tempo,. più grande è il buffer, maggiore diventa anche la latenza complessiva. In altre parole, non possiamo eliminare completamente il problema: possiamo soltanto trovare un compromesso tra reattività e continuità del flusso audio.

Internet non è un cavo

Questo è probabilmente il concetto più importante da tenere presente quando si progetta una stazione remotizzata: una connessione Internet non è un semplice prolungamento del cavo che collega la radio alle cuffie. I pacchetti possono seguire percorsi differenti, essere accodati nei router, subire ritardi variabili e, in determinate condizioni, essere persi. La situazione può inoltre cambiare nel tempo senza che sia stata modificata la configurazione della stazione. Per questo motivo una soluzione che funziona perfettamente alle 10 del mattino può avere prestazioni molto diverse qualche ora dopo, senza che apparentemente sia cambiato nulla.

La qualità della remotizzazione dipende quindi non soltanto dalla velocità della connessione, ma soprattutto da latenza, jitter, perdita di pacchetti e stabilità del collegamento. E questo è un punto sul quale spesso si fa confusione: avere una connessione da 1 Gbit/s non significa automaticamente avere una connessione adatta ad una stazione remotizzata. Per l’audio di una radio non servono in genere grandi quantità di banda; è molto più importante che i dati arrivino in tempo e con regolarità.

Non tutte le funzioni sono ugualmente sensibili

Il problema, inoltre, non è uguale per tutte le componenti della stazione: Un comando CAT può tollerare senza particolari problemi qualche centinaio di millisecondi di ritardo, ma se stiamo ascoltando una conversazione SSB, il ritardo diventa immediatamente percepibile; in CW la situazione è ancora più critica, perché la corretta temporizzazione è parte integrante dell’informazione, ed un jitter può potenzialmente rendere indistinguibile una linea da un punto.

L’audio è quindi normalmente il componente più sensibile della remotizzazione. Il CAT, al contrario, può essere relativamente tollerante, purché la connessione sia stabile.

La mia soluzione

Data l’importanza che la componente audio ha nell’attività radiantistica, per la remotizzazione ho preferito gestire due flussi distinti e separati.

Il primo flusso concentra la parte applicativa: tutte le applicazioni da usare sono in esecuzione sul controller della stazione, e l’accesso a questi programmi è garantito trasportando attraverso la rete l’interfaccia grafica e gli input di tastiera e mouse. A questo scopo ho usato l’accoppiata xRdp+Xorg per rendere accessibile in remoto l’ambiente grafico della macchina, così come se fosse eseguita sul desktop (che è gestita da xfce). E’ la configurazione standard del servizio remoto preinstallato su hamlinux, e può essere ovviamente attivata su ogni altra distribuzione, ed è  fra le soluzioni di virtualizzazione che, al momento, hanno la migliore utilizzazione della banda. Sul controller di stazione faccio girare anche Flrig, che mi consente di interagire con i controlli del ricetrasmettitore.

La cosa interessante è che l’operatore remoto utilizza gli stessi programmi che utilizzerebbe davanti alla stazione: non deve imparare una nuova interfaccia, nè deve capire come un’applicazione remota ha deciso di rappresentare il filtro della radio. Il limite è naturalmente quello di qualsiasi desktop remoto: stiamo trasferendo l’interfaccia grafica, non l’intero computer. La qualità dell’esperienza dipende quindi dalla latenza e dalla qualità della connessione, ma per molte operazioni radiantistiche questo compromesso è perfettamente accettabile. Il desktop remoto è quindi soltanto uno dei modi attraverso i quali l’operatore accede alla stazione: questo è un aspetto importante dell’architettura: il sistema non deve essere progettato specificamente per il controllo remoto, la remotizzazione dovrebbe essere una funzione aggiuntiva della stazione, non una modalità completamente diversa di funzionamento.

L’audio è gestito invece da un secondo flusso, affidato ad un server Mumble: una piattaforma open source di comunicazione vocale in tempo reale, nata principalmente per il gaming e progettata per offrire comunicazioni a bassa latenza. Anche questa è una applicazione facilmente installabile localmente, quindi senza affidarsi a servizi di terze parti. Un client è installato sul controller di stazione, su una interfaccia audio connessa agli ingressi cuffia e microfono, e l’audio è pronto ad essere trasferito al client installato sul PC remoto.

Un ultimo aspetto operativo merita una menzione: il comando PTT manuale di Flrig, a differenza di quanto avviene in molti programmi digitali, non ha un meccanismo di timeout integrato (watchdog timer). Se la connessione remota cade mentre la radio sta trasmettendo, non c’è nulla che rilasci automaticamente il PTT, che potenzialmente è un grosso problema. Per questo ho aggiunto un piccolo script Python che, tramite l’interfaccia XML-RPC di Flrig, monitora periodicamente lo stato del PTT e forza il rientro in ricezione se la trasmissione continua oltre una soglia configurabile (nel mio caso 6 minuti), indipendentemente dal tipo di sessione che l’ha causata. È un livello di protezione aggiuntivo rispetto al TX Timeout Timer eventualmente già presente nella radio, e funziona anche quando quest’ultimo non è stato impostato o è configurato su un intervallo troppo lungo.

Un aspetto che vale la pena sottolineare è che la VPN non serve soltanto a proteggere l’accesso al desktop della stazione. Nel mio caso, sia xRDP che il server Mumble restano raggiungibili esclusivamente all’interno della rete privata virtuale: nessuno dei due servizi è esposto direttamente su Internet. La VPN diventa quindi il perimetro unico attraverso cui passa l’intera stazione remotizzata, non soltanto il controllo CAT o il desktop.

È una soluzione più complessa rispetto a “aprire un programma e collegarsi alla radio”, ma è anche molto più aderente alla natura reale del problema: la remotizzazione non consiste infatti nel trasportare semplicemente i comandi della radio da un computer all’altro, ma rendere disponibili informazioni diverse, con esigenze temporali diverse, e nel farle arrivare all’operatore in modo sufficientemente rapido e prevedibile da permettergli di continuare a utilizzare la stazione.

E, a differenza di quello che accade quando siamo seduti davanti alla radio, su Internet dobbiamo sempre accettare un certo compromesso: una stazione remotizzata non potrà mai essere perfettamente equivalente a una stazione locale.  L’obiettivo realistico non è eliminare la rete, ma progettare l’architettura in modo che i suoi limiti siano il meno possibile percepibili dall’operatore e  rendere accessibili da remoto le funzioni necessarie per utilizzare la stazione.

Cosa significa “utilizzabile”?

Io opero principalmente nei modi digitali, FT8 in primis, e questo è l’ambito in cui la remotizzazione dà i suoi risultati migliori: se la connessione è adeguata, l’esperienza finale non è così diversa da un uso in locale. Ho fatto qualche collegamento anche in SSB, con buoni risultati. Ma più che i giudizi personali contano i fatti, per cui qui di seguito potete ascoltare un frammento di comunicazioni ricevute su 14.201 MHz (come riferimento LY2NK arrivava con RS 5/5) ritrasmesso via mumble configurato a 60kbit/s a bassa latenza, e ricevuto attraverso una connessione via rete cellulare.

Completamente diversa è la questione nel caso del CW, perchè a velocità relativamente modeste come 25 parole al minuto un punto dura circa 48ms, quindi anche pochi millisecondi di jitter sono percepibili come CW sporco. Ci sarebbero vari approcci possibili per risolvere la questione, ma dato che è un problema che non ho ancora concretamente affrontato direttamente sul campo vi rimando a due soluzioni che mi sembrano, in linea di principio, buone: quella di IW7DMH, e l’altra di N2QM.

Dalla stazione distribuita alla stazione remotizzata

Nel primo articolo di questa serie il passaggio fondamentale era stato rendere condivisibile il collegamento CAT: la radio smetteva di essere una risorsa esclusiva di un singolo programma e diventava un servizio a disposizione di più applicazioni, anche su computer diversi, purché nella stessa rete locale.

Qui il salto è diverso, e più impegnativo: non basta che la radio sia un servizio raggiungibile in rete, bisogna che l’intera esperienza operativa – comandi, ascolto, reattività – resti utilizzabile anche quando fra l’operatore e la stazione non c’è più un cavo, ma Internet. Ho separato i due flussi (controllo/interfaccia via xRDP, audio via Mumble) proprio perché non hanno le stesse esigenze, e ho scelto di proteggerli entrambi dietro un unico perimetro VPN, invece di rincorrere soluzioni frammentarie servizio per servizio.

Il risultato – ovviamente – non pretende di essere perfetto, né identico a operare seduti davanti alla radio: latenza e jitter restano un limite fisico che nessuna architettura può eliminare del tutto. Ma è una soluzione che nasce da ciò che già esiste – flrig, Hamlib, xRDP, Mumble – invece che dal tentativo di ricostruire da zero l’esperienza della stazione. E soprattutto, resta coerente con l’architettura descritta nel primo articolo: la stazione remota non è un sistema a parte, costruito solo per essere raggiunto da fuori casa. È la stessa stazione distribuita di prima, a cui abbiamo semplicemente esteso il perimetro.

Il CW resta il fronte ancora aperto, ed è probabilmente lì che tornerò in un prossimo articolo, una volta messe alla prova sul campo le soluzioni che ho citato o, perchè no, anche mettendone in campo una mia.

Info