Una stazione radiantistica moderna assomiglia sempre meno a un insieme di apparecchi indipendenti e sempre più a un piccolo sistema informatico. La radio resta naturalmente il cuore della stazione, ma intorno ad essa ruotano logger, programmi per i modi digitali, DX cluster, strumenti per il controllo dell’antenna, SDR, applicazioni per il controllo remoto e, sempre più spesso, servizi che girano su macchine diverse.

Il problema nasce nel momento in cui tutte queste applicazioni hanno bisogno di parlare con la stessa radio.

Una volta era sufficiente collegare la radio al computer e configurare il programma che doveva controllarla. Oggi è abbastanza comune avere contemporaneamente un logger che deve conoscere la frequenza, il modo operativo ed il livello del segnale, un programma digitale che deve leggere e impostare il VFO, un’applicazione per il cluster che deve sapere dove siamo sintonizzati e magari un secondo programma che deve occuparsi del controllo del rotore. Ma le radio non sono progettate per essere utilizzate contemporaneamente da tutti questi programmi.

Una radio, una porta, un solo padrone

Il collegamento CAT delle radio moderne generalmente passa attraverso una porta seriale fisica oppure attraverso una porta USB che, dal punto di vista del sistema operativo, si comporta allo stesso modo di una seriale.

Ed è qui che compare il primo limite: una porta seriale normalmente viene aperta in esclusiva. Se WSJT-X apre /dev/ttyUSB0 (o COM1), un secondo programma non può semplicemente aprire la stessa porta e mettersi in ascolto. Anche quando il dispositivo e il driver consentono forme particolari di condivisione, non abbiamo comunque risolto il problema logico: due programmi potrebbero voler modificare contemporaneamente frequenza, modo, VFO o PTT senza sapere cosa sta facendo l’altro.

Il modello tradizionale (programma -> CAT -> radio) funziona perfettamente solo quando il programma è uno e soltanto uno.

Ma una stazione reale oggi assomiglia molto di più a questa:

Logger ------> |
WSJT-X ------> |
DX-Cluster --> | -> CAT -> Radio
FLDIGI ------> |
SSTV --------> |

La domanda, quindi, non è più semplicemente come collegare un programma alla radio, ma diventa: come facciamo a trasformare il collegamento CAT con la radio in una risorsa condivisa?

La risposta consiste nell’introdurre un livello intermedio, che possiamo chiamare HUB.

Logger ------> |   |
WSJT-X ------> | H |
DX-Cluster --> | U | -> CAT -> Radio
FLDIGI ------> | B |
SSTV --------> |   |

L’hub diventa l’unico componente che possiede realmente il collegamento verso la radio. Le altre applicazioni non accedono più direttamente alla porta seriale: parlano con l’hub. Questa semplice modifica cambia completamente l’architettura della stazione.

Due modi diversi di costruire l’hub

Nel software radiantistico, sia GNU/Linux che Windows, esistono diverse soluzioni per realizzare questo livello intermedio, ma due delle più interessanti sono flrig e Hamlib/rigctld. Non sono però due implementazioni equivalenti dello stesso concetto.

Flrig nasce come applicazione di controllo della radio che mette a disposizione dei vari programmi client un’interfaccia XML-RPC (un metodo che consente a due programmi di scambiarsi dati). In questo modello, flrig mantiene il collegamento con la radio e si comporta da server nei confronti delle applicazioni che vogliono utilizzarlo. L’idea nasce nell’ecosistema dei programmi sviluppati da W1HKJ.

Lo schema è quindi:

Applicazione1 -(XML-RPC)-> |
Applicazione2 -(XML-RPC)-> | -> flrig -> CAT -> Radio
Applicazione3 -(XML-RPC)-> |

È una soluzione semplice e molto efficace quando le applicazioni che compongono la stazione supportano direttamente l’interfaccia di flrig.

Il modello Hamlib è invece costruito attorno ad un’idea più generale: fornire un’interfaccia uniforme alle applicazioni, in grado di controllare un numero molto elevato di radio. Hamlib è principalmente una libreria messa a disposizione dei vari software. Ha inoltre un’applicazione associata, rigctld, che fa da ponte fra l’apparecchiatura radio locale e le applicazioni compatibili con Hamlib, che possono scambiare dati attraverso la rete.

In questo caso il modello diventa:

applicazione -> rete -> rigctld -> CAT -> radio

La differenza può sembrare sottile, ma dal punto di vista dell’architettura è importante: con flrig abbiamo un’applicazione che espone una propria interfaccia XML-RPC, con rigctld abbiamo un servizio di rete basato sul protocollo NET di Hamlib; ed è proprio la natura standardizzata di Hamlib a far sì che questo approccio possa essere utilizzato da un numero molto più ampio di programmi.

Dove si incontrano flrig e Hamlib

I due mondi, tuttavia, non sono completamente separati: Hamlib può parlare con flrig usando il modello #4, che permette ad un’applicazione che utilizza Hamlib di utilizzare flrig come dispositivo radio, con una configurazione di questo tipo:

applicazione1 -> rete -> rigctld -> | -> flrig -> CAT -> radio
applicazione2 -(XML-RPC) --------> |

In altre parole, Hamlib può utilizzare flrig come backend, ma non vale la relazione inversa: non possiamo prendere rigctld e configurarlo come client NET verso flrig, perché flrig non espone un server Hamlib NET rigctl a cui rigctld possa collegarsi.

Questa distinzione è fondamentale quando si progettano architetture più complesse, perché il fatto che due componenti siano entrambi in grado di controllare una radio non significa che siano intercambiabili come client e server.

Il computer non è più il centro della stazione

Il vero salto di qualità arriva quando il collegamento tra applicazione e servizio CAT non è più necessariamente locale: se rigctld ascolta su una porta TCP accessibile dalla rete locale, il programma che lo utilizza non deve più necessariamente trovarsi sulla stessa macchina a cui è connessa la radio. Questo consente di distribuire la stazione su più dispositivi, ma le applicazioni continuano a vedere la radio come se fosse un’unica risorsa CAT.

Questo è particolarmente utile per le tecnologie più moderne, come FT8: durante i collegamenti è facile tenere aperte più applicazioni, peraltro intensive dal punto di vista grafico: logger, WSJT-X, PSK Reporter, DX cluster, GridTracker. Anziché concentrare tutto su un unico PC, diventa più comodo ed efficiente lasciare il controllo CAT e WSJT-X sul dispositivo connesso alla radio, e fare girare le applicazioni grafiche – che richiedono spesso più monitor – su un altro PC dello shack.

Non è necessario che ogni applicazione sappia dove si trova fisicamente la radio: le basta conoscere l’indirizzo del servizio CAT.

Questa è una conseguenza importante dell’introduzione di un livello di rete: il collegamento fisico viene separato dall’applicazione che lo utilizza. È quindi utile considerare la condivisione del CAT come un’infrastruttura che può essere utilizzata per costruire una stazione distribuita.

Un caso pratico

Una volta compreso il modello, è interessante vederlo applicato in una situazione reale.

Nel mio shack ho due radio principali: un FT897D per VHF/UHF e un FTdx1200 per le HF, entrambe interfacciate con un ThinkCentre M91, un PC Small Form Factor che ha oltre venti anni (ne ho parlato qui).

Con Linux ha prestazioni più che sufficienti per fare girare sia l’applicazione principale (WSJT-X, Fldigi o altro) che quelle accessorie (logger, PSK Reporter, GridTracker, ecc.), ma un limite è il singolo schermo: per avere accessibili tutti i software utili per un collegamento digitale è utile averne almeno due.

Anziché aggiungere un secondo schermo al controller della stazione, ho preferito spostare le applicazioni accessorie su un altro PC che ho sempre nello shack, già dotato di schermi multipli.

Per interconnettere le varie applicazioni uso appunto rigctld, che lancio con configurazioni diverse a seconda di quello che mi serve. Ad esempio:

rigctld -m 1034 -r /dev/radio1200 -p CAT -s 38400 --port 4532

è quella che utilizzo per l’FTdx-1200.

WSJT-X è configurato per usare Hamlib via rete: il campo Server può essere lasciato vuoto se rigctld è in locale, altrimenti è sufficiente indicare l’indirizzo IP ed il numero della porta, il 4532 dell’opzione --port.

Per completare l’integrazione è necessario anche condividere i dati prodotti da WSJT-X via UDP. La configurazione è questa:

La spunta su Accetta richieste UDP consente ai programmi accessori una comunicazione bidirezionale, che permette una maggiore integrazione: ad esempio, è possibile aggiornare il campo nominativo DX di WSJT-X cliccando su uno dei nominativi del roster di GridTracker.

Nella mia configurazione GridTracker e Log4OM girano sul secondo PC, che – come dicevo – è dotato di due monitor.

Su GridTracker è necessario indicare l’indirizzo multicast (nel mio caso 224.0.0.1, porta 2237) che abbiamo precedentemente configurato su WSJT-X.

La stessa configurazione va fatta su Log4OM su Software integration/connections:

mentre il CAT è su Hardware/CAT:

Una volta settati i parametri è possibile usare sia il controllo CAT remoto, sia l’integrazione con FT8.

L’idea è separare il più possibile le funzioni: il computer dedicato alla parte radio può occuparsi del collegamento fisico con gli apparati e fornire il servizio CAT. Le applicazioni possono invece essere distribuite secondo le necessità, senza che ciascuna debba conoscere i dettagli della porta seriale utilizzata dalla radio.

Il vantaggio non è soltanto quello di poter eseguire più programmi: è che nessuno di questi programmi deve controllare direttamente la radio. La radio diventa un servizio, ed è una differenza concettuale notevole rispetto alla configurazione tradizionale.

In una stazione con più radio, come nel mio caso, si può inoltre fare un passo ulteriore: se le radio non vengono utilizzate contemporaneamente, non è necessariamente necessario mantenere un’istanza di rigctld distinta per ciascuna di esse. È sufficiente mettere in esecuzione solo quella associata alla radio da usare:

Le altre applicazioni non hanno bisogno di sapere quale radio sia al momento attiva: sanno che i dati arrivano sul canale multicast, ed è quindi possibile in pochi istanti passare da una radio all’altra senza modificare ulteriori configurazioni.

Questo permette di costruire un’infrastruttura nella quale la scelta dell’apparato fisico diventa una questione interna al sistema, mentre per i programmi client la stazione continua ad avere un’interfaccia CAT coerente.

La radio come servizio

Il passaggio più importante, alla fine, non è tecnologico ma concettuale: siamo passati dal concetto una radio, un programma ad un ecosistema in cui una o più radio interagiscono con più applicazioni in modo semplice ed affidabile, mentre il computer al quale è fisicamente collegata la radio non deve più essere necessariamente il computer dal quale la radio viene utilizzata.

Tutto questo funziona benissimo se rimaniamo nella nostra rete locale. Ma che succede se volessimo spostare il controllo fuori dalla rete, via Internet?

In questo caso non parliamo più di stazione distribuita, ma di stazione remotizzata, ed il passaggio è meno immediato e semplice di come possa apparire.

Ne parlerò nel prossimo post.