---

SVXLink Server & Client

Macro architettura e funzionalità, cenni installazione

Prologo

Immaginate una lunga strada, non poco tortuosa ma ampia e scorrevole, senza le buche e i gradini a cui siamo abituati nelle nostre carreggiate. Alberi frondosi a destra e sinistra, da uno dei due lati panchine e panchine perché ci si possa sedere e osservare, poi alzarsi e entrare in azioni camminando in senso o nel altro con chiunque abbia un CTCSS o un Talk Group uguale al nostro.

Ogni tanto lungo questa ipotetica strada Poco prima di una salita, in cima alla stessa o Appena a valle dall’altro lato, si apre uno slargo e c’è un chiosco, il chiosco riporta le informazioni necessarie per iniziare la camminata.

Ci sono appesi dei manifesti con i numeri di CTCSS per ogni Talk Group con cui iniziare a dialogare con altri o cercare chi vuole dialogare in quel momento: alzarsi e seguire una strada comunque.

Cosa e come si potrà vedere via via

Quattro punti fermi per confonderci bene o meglio le idea sull’architettura e la costruzione che ne consegue di SVXLink. In mezzo un altro po’ di blah blah, blah, come piace allo scrivente. Siate pronti e presenti a voi stessi, nel caso afferratevi.

1. Qualche elemento storiografico di SVXLink, i lor parenti, con rimandi a questi e altri elementi correlati tra le righe qua e la.

2. La definizione dei macro schemi funzionali a blocchi, utile per sapere cosa si ha di fronte volenti o nolenti per i due componenti principali, a noi OM solo parzialmente in vista

3. Schemi e approcci d’uso per chi lo usa e non è solo un gioco di parole e indica noi – certo non potranno essere esaustivi pena la completa illeggibilità del testo, p.es le voci che via via ci risponderanno …

4. Qualche cenno all’installazione e alla configurazione, compresi gli elementi già citati qua e la, visibili e non visibili a noi OM, ma presenti e coerenti con gli scopi dell’architettura di comunicazione che andremo a scalfire.

Vi saranno oltre allo script più o meno filante diversi disegni o tabelle, alcune da vedere una volta altre da tenere ben presenti nell’uso quotidiano. Quali e come, dipende da noi e dal livello d’interesse per le nostre attività, oltre che dalla curiosità intrinseca per chi vuole auto apprendere. Ovvero non solo pontificare con CTCSS, DTMF e ammennicoli vari.

Poca storia, scopi e funzioni

SVXLink (svxlink.org) prende il nome da SM0SVX, che ne ha curato lo sviluppo e le varie fasi di implementazione, l’aggiunta di gateway e, via via, il supporto operativo dal 2003 in poi. SVXLink è stato molto influenzato da Echolink e inizialmente tendeva a collegare nodi Echolink, fungendo da ponte per Echolink o come nodi simplex. Dispone di un software companion chiamato Qtel, nientemeno che un client Echolink grafico per Linux, utile sia per gli utilizzatori sia per le verifiche del setup del Gateway.

SVXLink è composto da due componenti principali (presenti nello stesso kit d’installazione, mentre Qtel è da installare a parte sempre su Linux):

1. SVXLink Reflector Server, interconnette uno o più SVXLink Client e altri SVXLink Server, non ha interfacce per RTX, interfaccia e parte di sistemi di comunicazione

2. SVXLink Client, si interconnette a SVXLink server, contiene le interfacce per gli RTX e altro, usa voce in TX e audio in RX inviandoli in rete, interfaccia radio e esseri umani

Le forme principali d’utilizzo sono quelle che tendono ad ampliare il classico utilizzo degli HT (Handie-Talkie) su ripetitori duplex o simplex, dove un SVXLink Client si interfaccia con un SVXLink Reflector Server, permettendo di comunicare “su e giù” per le nostre vallate montane via Internet.

Tutto questo senza meccanismi complessi, voce da Paperino o balzelli inopportuni nel nostro dominio.

Prima di tutto, di cosa si parla

Si parla di un’architettura di comunicazioni distribuita, costruita intorno ai due elementi appena citati, con molto altro “collante” aggiunto.

Vediamo due immagini, due schemi a blocchi che riguardano la stessa “ecologia” di sistemi e sottosistemi hardware e software, ma che la rappresentano diversamente:

→ la prima come schema a blocchi suddiviso in livelli gerarchici; → la seconda con un’intrinseca visione distribuita e geografica dello stesso insieme di componenti.

Le due immagini riportano in modo esaustivo il 99% dei componenti e coerentemente le relative interconnessioni.

Questa prima immagine, uno schema a blocchi meccanico e fortemente legato alla gerarchia dell’architettura in gioco, mostra i componenti livello per livello, dal primo in basso dove siamo presenti noi con le nostre radio analogiche.

Salendo, poi, poco più in alto verso i nodi che interconnetto le radio che ascoltano o trasmettono (SVXLink Client), già digitalizzando avanti e indietro, le nostre voci e i segnali, sempre in voce, per noi. Il componente di conversione, codec, dei segnali analogici usa il formato, open software opus: più performante, qualitativamente, rispetto a altri prodotti già in uso nel nostro campo radio o nel campo più commerciale.

Una digressione dovuta. Un codec (da codificatore/decodificatore) è una componente {software} o un dispositivo integrato che si occupa della {codifica} o {decodifica} di un segnale (tipicamente audio o video) perché possa essere salvato su un {supporto di memorizzazione}, la parte ci codifica, mentre la seconda componente, la decodifica, permette che il segnale sia letto per la sua riproduzione. Lo stesso termine, codec, si usa per supporti non volatili o volatili, un CD o uno stream in rete.

La parola Codec un {portmanteau}, l’unione artefatta di due termini: coder/decoder. E qui terminiamo questa digressione …

La ragione di fondo di tale scelta, che per noi si traduce in un’elevata qualità audio, è che i segnali analogici percorrono solo la tratta dalla nostra radio al Nodo e viceversa (dal nodo Client a noi): non vengono di fatto utilizzati tra le radio dei nodi e le nostre radio, né tra due radio connesse nella stessa modalità al Client.

Questo meccanismo, che pilota ogni ponte, riceve in RX la nostra modulazione analogica e ne rimanda pari pari il segnale di BF (bassa frequenza) alla radio in TX del ponte, permettendo ad altri OM in ascolto – come dicono al telegiornale – di fruirne normalmente.

La larghezza di banda necessaria al canale radio di comunicazione non viene ridotta o filtrata da codec commerciali (proprietari o non proprietari) che passano i nostri segnali audio attraverso dei “colini robot”.

Per esempio, non vi sono segnalazioni aggiuntive inviate ripetutamente in digitale insieme ai pacchetti della nostra modulazione, che obbligatoriamente dovrebbe restringersi per far passare tutto insieme. Appare lampante – se ci fosse bisogno di ribadirlo – come il “costo” del canale di trasporto (si badi, non è un costo puramente in metallo sonante) sia completamente diverso tra etere e filo.

Tutto questo è fondamentalmente l’insieme dei motivi per cui SVXLink ha sempre un’ottima modulazione, salvo problemi non nativi al suo interno (propagazione, taratura dei livelli, ecc.). Se usiamo un microfono rotto o trasmettiamo dagli infernotti, eh beh, capita di “impegnare male o peggio”, fin dall’inizio il circuito…

Nella seconda immagine qui presentata si ha una visione d’insieme geografica degli stessi componenti logico fisici e dei loro livelli d’interconnessione.

Con una diversa visibilità degli stessi. Per esempio si osserva, osservatelo, k è composto da due componenti principali (presenti nello stesso kit d’installazione, mentre Qtel è da installare a parte sempre come a SVXSVXLink Reflector si possano interconnettere diversi tipo, per configurazioni HW e SW, di configurazioni di stazioni:

1) SVXLink Node con due radio connessa, PONTE DUPLEX, una collegate una in RX e la seconda in RX, in shift di frequenza, più la relativa componentistica aggiuntiva

2) SVXLink Node con una radio connessa, SIMPLEX, una sola radio anche in shift o in split ma strettamente simplex quando trasmette non ascolta e viceversa

3) SVXLink Node in versione personale con una radio, con un ricetrasmettitore ad hoc semplificato, verosimilmente uno SHARI, per brevi e brevissime portate: qualche decina di metri

4) SVXLink Node sempre in versione personale ma senza radio connesse, quasi fosse un apparato da telefonia, pochissimo ingombrante, Raspberry PI, magari 0 2 W, un micofono e una cuffia o un’altoparlante, dipendentemente dalla fonte d’alimentazione e anche d’amplificazione

Quanto indicato viene qui riportato in forma grafica. Le linee tratteggiate orizzontali separano i livelli funzionali

In questa tavola sono schematizzati e diversamente visibili rispetto alla tavola precedente quasi tutti i macro componenti di un sistema di SVXLink:

• SVXReflector Server node – il principale al centro interconnette i Client e crea un sistema funzionale di SVXLink

• SVXLink Client node nella parte più in basso della tavola con le sue possibili diverse declinazioni

• Altri SVXReflector Reflector node con i propri, perché li connessi via IP, SVXLink Client – insieme al primo qui disegnato molto più grande ampliano il singolo sistema in un insieme multiplo di sistemi a livello gerarchico equivalente

• NON esiste, non è previsto nell’architettura, ne è configurabile un Reflector Master di altri Reflector, ovvero non esiste un SVXLink Reflector a cui tutti i Reflector si devono riferire per esistere e comunicare tra di loro

• Con le nuove versioni di Reflector si possono avere dei Satellite, ma sono altra cosa e hanno altri scopi, per quanto consimili, qui non verranno descritti Satellite

• Terminali a RF per gli SVXLink Client, ponti duplex e link simplex

• Terminali Echolink e POC che possono accedere via Gateway sugli SVXReflector opportunamente configurati, in definitiva saranno ingressi IP al Gateway configurato per un Reflector che voglia fungere da punto d’accesso fisico

Mancano nel disegno i terminali, con uso di radio, per DMR, C4FM, D-STAR e altri metodi di modulazione digitale e instradamento dati.

Risulterebbero connessi a hardware dedicato a sua volta connesso a Gateway per ogni Reflector che fungerà da punto d’accesso.

Quello più in basso nel disegno riporta ciò che noi OM osserviamo ascoltando e trasmettendo via nostre normali radio analogiche. Ponti, duplex o simplex e link personali.

POC e Echolink NON usano direttamente degli SVXLInk Client, ma Gateway come costrutti di rilancio da reti digitali ‘diverse’, tutte trasportabili via Internet. Lo stesso per DMR, C4FM, D-STAR, che possono condividere costrutti simili, Gateway, quando installati sui Reflector e ritornare analogici in uscita dai ponti e dai link di SVXLink e i segnali analogici possono divenire digitali, secondo i loro specifici protocolli, e essere restituiti all’utente connesso con la specifica radio.

In altre parole occorre normalizzare anche questi protocolli via IP occorre quindi riceverli via radio, convertirli in pacchetti di dati IP e re-instradarli verso un SVXLink Gateway

A proposito, Applicazioni, Gateway, router e trasporti dati

Per rendersi o rinfrescare la propria conoscenza su questi tre oggetti:

Un gateway risiede “on top” (al di sopra) della struttura di comunicazione. Si occupa di ricevere dati in un dato formato e di trasformarli in un altro formato. È un’applicazione che non si occupa dei livelli di routing, ma ha le proprie tabelle per sapere chi chiamare e a chi rispondere, in base a quanto gli viene inviato via IP.

A questo livello, il primo in alto, risiedono anche le applicazioni di gestione delle comunicazioni e del signalling sia in simplex che in duplex.

A questo livello, il più alto, risiedono anche le applicazioni di gestione delle comunicazioni e del signaling, sia in simplex che in duplex. C’è l’applicazione che gestisce i dati UDP in formato Opus, conta la sequenza dei pacchetti per rimetterli in ordine e li riconverte in audio BF per farceli sentire, trasmettendoli in aria verso le nostre radio. Lo stesso fa questa componente applicativa dentro SVXLink Client per ricevere la nostra voce via radio, codificarla in Opus e trasferirla verso chi è stato indicato come destinatario.

I diversi applicativi al livello top si appoggiano e vengono messi in gioco dalle indicazioni fornite dal Sistema Operativo, che come secondo livello dall’alto vede IP.

Un router si occupa di instradare i dati all’interno delle reti verso una destinazione, descritta nei dati stessi. A seconda delle strutture dati che riconosce o semplicemente perché ha tabelle predefinite o dinamiche, instrada i pacchetti. Il routing IP è il livello più basso di IP. Non esiste un vero e proprio router per SVXLink: le applicazioni di SVXLink si appoggiano ai servizi di Sistema Operativo per essere raggiunte o per raggiungere altri nodi SVXLink.

Sotto il livello di routing meccanico, esiste il livello di Trasporto per IP, i protocolli di trasporto sono UDP e TCP.

A UDP viene chiesto di aprire un circuito con un corrispondente per inviare dati, o per far sì che un corrispondente raggiunga la nostra applicazione SVXLink per farci sentire la sua voce. UDP lavora controllando l’andamento dei dati con numeri progressivi (numerando i pacchetti) e controllando le sequenze, stile AX.25: “mi hai mandato il pacchetto 100 e poi il 102, attento, si è saltato il 101”.

Opus, il codec audio, provvede come può a ricostruire le sillabe perse insieme ai dati ricevuti correttamente, ed è comunque una componente applicativa che riordina i pacchetti (persi o non persi, o anche solo ricevuti fuori ordine). Trasmettere la voce deve avere un costo basso, oltre a essere affidabile con il supporto del Sistema Operativo.

È una corsa di cavalli: persa una sillaba o anche più, non si torna a richiederla o a riprenderla, semplicemente perché non esiste più. UDP conserva solo minimamente i dati in transito: un pacchetto partito da un nodo e perso è perso. D’altronde, che potrebbe fare il codec ricostruttore? Farci aspettare fino a rimettere insieme la frase?

A TCP viene richiesto di aprire un circuito affidabile per la comunicazione delle segnalazioni tra i due livelli di nodi che compongono la gerarchia di SVXLink. TCP conta i pacchetti e invia i contatori nei due sensi della comunicazione; si può richiedere la ritrasmissione per ricostruire il messaggio, aspettandosi di attendere solo un minimo. Questo fa sì che il signaling tra due endpoint sia sempre funzionale e affidabile; viceversa, si perde la comunicazione. I nodi per il signaling sono paritetici nel caso di SVXLink: un SVXLink Client segnala verso un SVXLink Reflector, che segnalerà al Reflector del nodo SVXLink Client destinatario, e viceversa.

Comandi e segnalazioni in generale

Comandi o segnalazioni sono specifici segnali, comandi, o sequenze di elementi da inviare in linea insieme ai segnali utili, nel nostro caso la voce. Un esemplificazione prevede che i comandi sono inviati con sequenze esterne, bottoni e levette, mentre le segnalazioni sono inviate da gestori interni al software in uso, buffer pieno, buffer vuoto azione richiesta, azione ritardata.

Qui usiamo concetti più laschi, intendiamo sempre elementi esterni in controllo diretto di chi opera il sistema SVXLink e dividiamo i comandi che diamo in locale, dalle segnalazioni che diciamo alle nostre interfacce di passare segnalazione di comandi a chi le gestirà nella gerarchia di SVXLink.

Anche se già parzialmente indicato, occorre inquadrare la presenza di varie funzioni di instradamento tra i diversi ponti duplex o simplex. Tutte basate su tre metodi principali di definizione dei cammini (a volte simili), per cui i nostri segnali saranno propagati nei vari livelli di ogni sistema SVXLink: segnali DTMF per i link analogici; segnali CTCSS sempre per link analogici; indirizzamento a componenti infrastrutturali specifici dei vari modi digitali, da associare automaticamente ai TG (Talk Group) dei diversi Gateway distribuiti con i diversi Reflector sul territorio.

Quest’ultimo metodo, per quanto riguarda l’emissione digitale, verrà trattato solo marginalmente.

SVXLink, con i Reflector, i Gateway e i Client, compone un sistema distribuito dove esistono raggruppamenti di utenti via radio analogiche, utenti di radio e sistemi digitali (con gli appositi Gateway configurati sul proprio Reflector). I gruppi così costituiti possono insistere sulle stesse realtà geografiche (con separazione di frequenze) oppure interconnettersi con altri gruppi, e via via, senza perdita di segnale BF. La gestione dei gruppi di comunicazione, detti Talk Group (niente a che vedere con i TG DMR), è a carico dei gestori dei vari Reflector, Gateway e Client e, una volta configurati, anche degli utenti, seguendo le linee indicate poco fa: CTCSS, DTMF, frequenze e modi d’accesso a ponti e link.

La prima serie di elementi, questa preconfigurata dei gestori dei vari Reflector e Client, è quella composta dai Talk Group. I Talk Group sono per SVXLink sorte di canali assegnati al momento senza particolari regole e trasferiti da un Reflector all’altro per poi resi gestibili, fruibili direttamente, dai Client verso gli utenti. Un TG viene scelto per essere distribuito senza comandi particolari in audio da poti duplex o Simplex. In genere si tratta di gruppi che assolvono le funzioni d’interconnessione locale in zona … sono poi disponibili questi flussi IP numerati per essere trasportati a nuovi SVXLink Client sullo stesso SVXLink Reflector o da questo a altri Reflector aumentando l’area geografica potenzialmente corretta.

Ovviamente non tutti i TG sono disponibili agli utenti finali, in prima battuta perché non possono dare output insieme sulle radio da noi utilizzate per accedere ai sistemi, in seconda battuta perché verrebbe meno il raggruppamento di ponti che insistono nell’area geografica servita: sempre occupati da segnali di altri raggruppamenti di ponti di altre geografie.

Un immagine, semplificata, che salta direttamente alle conseguenze di ciò e quindi alle pratiche di utilizzo, ma non è di se per parlante è questa:

Ora, supponendo che un operatore alla radio posta in basso nel disegno voglia attivare lo SVXLink Client node, in funzione di ripetitore locale ha una possibilità:

Dopo aver atteso il segnale di stand-by del ponte, 30”, ovvero un bip di varia tipologia (tacchino o flipper che sia). Ora, supponendo che un operatore alla radio posta in basso nel disegno voglia attivare lo SVXLink Client node, in funzione di ripetitore locale ha una possibilità: un colpo di portante del proprio TX, in shift, senza CTCSS e quindi agganciare il ponte in LOCALE che al termine gli risponderà con un “cenno d’assenso”, colpo di portante successivo e ulteriore alla ripetizione sua emissione appena ripetuta, la coda del punte, o dal solito tacchino o dal flipper, sempre in coda.

Nessuna indicazione vocale indica un TG, s’ intende ingaggiato il TG0, locale. Altra possibilità in uso per ponti con altri ponti vicini e quella di usare un tono CTCSS anche per l’uso locale.

Per impedire con una portante senza segnalazione d’ agganciare più ponti. Le frequenza di segnalazione CTCSS sono configurate in SVXLink Client node. Difficilmente, a volte sempre per diminuire i disturbi di altri ponti incontinenti, si inseriscono i toni anche in TX sulla radio …

In un secondo caso, si vuole invece trasmettere la propria chiamata non solo in locale ma anche verso il ripetitore di Valle Lontana.

Ora, supponendo che un operatore alla radio posta in basso nel prossimo disegno voglia attivare lo SVXLink Client node, in funzione di ripetitore locale ha una possibilità le Lontana, anche freddina nei mesi invernali, dovrà selezionare per agganciare il TG3 conosciuto dal suo SVXLink Client node con il tono CTCSS di 107.8 Hz la propria memoria 4.

Alla fine della PRIMA trasmissione, sempre partendo dallo stato di stand-by del ponte. Quindi alla fine della propria PRIMA trasmissione riceverà dal ponte prima l’ indicazione vocale del TG 3 come selezionato e poi il tacchino o flipper o leggermente staccato un altro colpo di segnale ricevuto.

La terza possibilità d’ingaggio, facciamo l’esempio di voler raggiungere Valle Stretta, è quella che anche selezionando la memoria 2, quindi il tono a 77 Hz modula la nostra portante mentre diamo e ripetiamo il aria il nostro nominativo, ma non succeda nulla.

Tacchino o flipper OK, colpo di portante ma nessuna indicazione di TGXX. Se si osservano le tabelle che contengono i CTCSS, quelli in uso sulle nostre memorie e quelli usati dal software di SVXLink si vedrà che per il TG2, quello di Valle Stretta, non combacia tra le due. Qualcuno un sysop vestito di nero e con il cappuccio della felpa ben calcato in testa, ha cambiato nottetempo il valore del tono CTCSS tabellato per il TG2 dal solito nostro 777 Hz, messo in memoria, con un valore di 82.5 Hz.

Bene ci resta ancora una possibilità per chiamare il nostro caro corrispondente sul TG due.

Mandare, sempre partendo dallo stand-by del ponte, in trasmissione la nostra ondina e passare via BF o dal MIC predisposto la sequenza 912#.

A questo punto il nostro lato del ponte ci risponderà con Talk Group 2 e il solito tacchino camuffato da flipper o il noto fabbro del colpo di portante. Questo indica che il nostro ponte ha compreso di dover instradare l’audio da se stesso al suo omologo in Valle Stretta, se chiamiamo di qua ci sentiranno di la e viceversa, come fosse un unico ponte in semi duplex. Il circuito tra la nostra radio, lo SVXLink Client node locale, lo SVXLink Reflector node locale, lo SVXLink Reflector remoto, lo SVXLink Client remoto e le radio di chiunque sulle frequenze in uso per il Client remoto in Valle Stretta. Questo circuito resterà in piedi se utilizzato entro i tempi di stand-by già indirizzati, 30” circa. I timing della catena sono garantiti dagli orologi dei Raspberry o altro elaboratori che costituiscono i quattro punti di SVXLink appena indicati. Sincronizzati via rete internet. Dopo 30” il path viene sganciato e se vogliamo di nuovo chiamare o lo facciamo prima del tacchino che gioca flipper o rieseguiamo la sequenza DTMF appena usata 912#

I primi due digit, 91, indicano il comando a SVXLink: stabilisci circuito. I digit numerici successivi, in questo caso solo “2” indicano il Talk Group del circuito da stabilire. Mentre il simbolo #, come la coda sel gatto, indica che il comando è terminato.

Se questi dati non vengono ricevuti scatterà il TG di default, sia esso 0 o altro, per il tono che abbiamo o non abbiamo in TX.

I toni sui nodi di link vengono cambiati spesso e a volte inseriti anche in trasmissione, perché la comprensione di molti OM gestori di ponti può variare fortemente a causa del chilometraggio che percorrono e del tipo di veicoli utilizzati. Per ristabilire un uso, occorre spesso cambiare toni per impedire che il solito vicino rumoroso, senza ascoltare, piazzi i suoi altoparlanti a tromba dentro le nostre finestre. Perché lo sanno anche i sassi che “loro sono loro e gli altri niente”, mi sembra di essere un mio carissimo amico OM.

Esiste anche una quarta possibilità quella un cui, sempre facendo fede al disegno in tabella 5, ovvero che lo SVXLink Client di Valle Lontana o Valle Stretta abbiano SOLO la funzione di Client non coadiuvati da da SVXLink Reflector, costa meno anche se permette molta meno flessibilità: da un Client non può partire nulla verso un altro Client. Se in Valle Lontana si vuole aggiungere un ripetitore Simplex o Duplex con antenne, frequenze o, men che mai, postazione diversa … non si potrà mai farlo senza ricorrere al Reflector principale. Cosa che va bene se i due punti di Valle Lontana sono ben serviti da Internet, ma che viceversa, nelle mille possibili sfaccettature.

Occorre disporre in loco di risorse umane per la configurazione e il mantenimento. Con un proprio Reflector Valle Lontana sarà anche in grado di far operare uno o due ipotetici SVXLink Client in modo interconnesso garantendo un maggio livello di comunicazioni. Il numero dei TG trasportabili uno a uno non cambia, previo accordo informativo con chi gestisce il Reflector in vista logica via IP.

SVXLink Client

Diversi componenti e moduli sono presenti e configurabili “dentro” SVXLink, creati con una certa varietà di linguaggi (C++ e TCL) e file di configurazione (ASCII con forme PARAMETRO=valore o strutture JSON più complesse). Alcuni moduli sono essenziali per il funzionamento di SVXLink, altri sono accessori, ma spesso non meno utili.

Diverse funzioni a supporto, alcune da configurare altre no, sono presenti nel core del codice di SVXLInk:

• diversi protocolli di conversione audio analogico e digitali, scelti e usati automaticamente in funzione degli ingressi configurato

• watchdog e timer vari per il controllo degli eventi e la relativa sequenziazione, con controlli e sensing di nuovi eventi

• LocationInfo: modulo incorporato nel codice principale (core) per ritrasmettere la propria posizione in APRS, tramite lettura NMEA da GPS o inserimento manuale

• Decoder DTMF “quasi infallibile” (per esempio anche via microfono con app su Android o iOS: nulla è perduto).

• Interconnessione e security gestibili via certificati condivisi tra server diversi e tra server e client – questo diminuisce la compatibilità tra siti installati con versioni più o meno diverse tra loro.

• Il linguaggio parlato verso gli utenti può essere personalizzato/cambiato (una sola lingua alla volta) come idioma e quindi espressione, a partire da una struttura di directory e subdirectory con nomi di file predefiniti – per es. è possibile cambiare il contenuto di un file audio senza cambiarne il nome e la posizione, o riscrivere in toto il meccanismo.

• Utilizzare TX e RX remoti o locali, in sequenza o contemporaneamente. Per esempio, aggiungere RX dongle (le note chiavette) per scopi e necessità diverse, come aggiungere altri RX o TX in territori e coperture frammentati. Per il controllo degli eventi si usa la keyword VOTING, per stabilire e variare il peso dei ricevitori.

Vediamo descrittivamente lo schema dei componenti principali, più avanti il disegno.

Diversi elementi, moduli, possono essere configurati ed eseguiti dal codice principale di SVXLink, vengono indicati e spesso configurati al momento della lettura da parte del server del file di configurazione principale, sono:

• Help – interrogato via DTMF risponde vocalmente citando i punti rilevati

• Parrot – se ingaggiato, via comando specifico DTMF, ripete localmente audio per verifiche

• Echolink – connetti, con indicazioni DTMF altri nodi Echolink

• DTMFRepeater – ripete per verifica i codici DTMF inviati dopo il relativo ingaggio

• TclVoiceMail – Invia via voce email ricevute dagli utenti locali

• PropagationMonitor – Annuncia propagation warnings da dxmaps.com

• SelCall – Invia sequenze di selettive per apparecchiature telecomandate via codici predefiniti

• METAR – METeorological Aerodrome Reporter, condizioni meteorologiche degli aeroporti e avio-superfici secondo la configurazione del gestore e le caratteristiche proprie dei luoghi

• FRN – modulo per Family Radio Network US

• TRX modulo per inviare telecomandi a transceiver remoti che li comprendano

Tutti questi moduli sono esposti verso il mondo esterno, noi, e possono essere configurati e attivati a discrezione di ogni gestore/configuratore del cliente DTMF. Non esiste una singola sequenza DTMF per verificare l’installato, elenco parlato sub-componenti installati, ma ogni modulo ha un proprio codice d’ attivazione, come il Parrot che ascolterà ogni sono trasmesso ripetendolo solo su nodo a cui è stata richiesta l’attivazione.

Si attiva durante lo stand-by del nodo dal lato RF, generalmente passati i 30 secondi da un’ultima trasmissione del nodo, è un periodo variabile da parte del gestore di ogni nodo. Il passaggio in stand-by è indicato da un breve colpo di portante, carrier, con relativo aggancio e sgancio del nostro squelch.

Esiste anche lo possibilità per configurare tale evenienza con un segnale acustico discreto, stile bipbip, o un segnale digitale fuzzy in CW, p.es. K, da_di_da.

Macro schema complessivo

La parte in alto mostra le interfacce analogiche più usate verso le radio

Secondo un altro punto di vista, in ogni SVXLink Client saranno presenti questi componenti, oltre alle relative funzioni indicate in Tabella 01. “Ferro più, ferro meno”.

A questo punto inizia l’installazione del software Client. Leggiamo e comprendiamo molto bene i prerequisiti, sia software che hardware; se abbiamo dubbi, chiediamo. Un’incertezza potrebbe risultare fatale e obbligarci a ricominciare l’installazione da zero, HW compreso.

Come per tutto il software amatoriale su Linux e per tutte le componenti non chiuse in un’unica scatola, sta a noi comprendere il senso di ciò che non conosciamo, non secondo la nostra logica, ma sforzandoci di capire la logica dello sviluppatore. Altrimenti non riusciremo a integrare i diversi elementi che possono dar vita al nostro progetto. Ci scontreremo con versioni e componenti accessori da installare secondo mille possibilità del momento.

Occorre un supporto se non avete medie conoscenze operative a riguardo. È abbastanza inutile cercare qui di indicare questo o quello, specie in mezzo a quello che vi sembrerà un marasma generale. Non date nulla per scontato: trovatevi PRIMA un buon mentore.

Siamo tutti molto individualisti, ma qualcuno che abbia la volontà, la capacità e il tempo di spiegarci e supportarci esiste. Altrimenti, uscirne vittoriosi e “funzionanti” non è impossibile: potete anche cominciare da zero, piano piano, con una forte volontà.

Una discreta conoscenza di ambienti operativi Unix/Linux CLI (molto meno via GUI) è raccomandata. “Come si esce da un editor salvando o non salvando il testo che abbiamo di fronte?” è un impasse che tutti abbiamo subito. Per Raspberry e i suoi OS, nella fattispecie Bookworm e non Trixie: Raspberry PI OS discende da Debian ARM64 e, al momento, ne segue la nomenclatura delle versioni. Bookworm è la penultima.

Per mettere insieme l’hardware basta un Raspberry 3, 4 o 5 con 1 o 2 GB di RAM. Ma anche un RPI 3 o 2 0 W bastano per supportare SVXLink, addirittura SOC compatibili con Debian, ARM64 o Intel64 (vedere la Wiki su GitHub).

Va da sé che con i SOC meno potenti è sconsigliabile usare la parte grafica: la shell bash è più che sufficiente. Quindi, installando dal sito l’immagine di OS su TF (anche da Windows o da altri Linux), occorre abilitare ssh e, meglio, definire le reti e gli indirizzi IP. Per la grafica, se proprio la si vuole, meglio usare VNC (configurandolo anche da raspi-config) e Tiger VNC come client, specie da un altro Linux.

Occorre definire quali interfacce audio, di comando PTT e sensing COS acquisire e verificarne la configurabilità. La preferita è la CM108, disponibile in diverse versioni. Il chip CM108 ha il vantaggio di fornire in un sol colpo audio I/O e controllo GPIO per il PTT. Poi, se state configurando un vostro link personale (short haul), esiste un insieme denominato SHARI che contiene interfacce USB per la sua radio.

L’interfaccia audio è meglio se si presenta isolata rispetto agli ingressi e uscite; lo stesso per PTT e COS.

Ottenuto l’accesso a un SVXLink Server (con schema di sicurezza user/password o certificati), ci si potrà collegare al primo TG indicato dal gestore del Server e da lì, osservando anche il portale del Server e il web locale del proprio Client, verificare le funzionalità configurate e quelle ottenute. Dal lato radio, già prima si potevano verificare alcuni parametri.

SVXLink Server & Client

Questa tavola è riepiloga l’insieme di componenti logici e, alcuni, fisici per un singolo SVXLink Server e diverse tipologie di connettività.

                  ---

Documento: SVXLink Server & Client - Architettura e funzionamento Versione: 1.0 Data: 2026-05-21 Autore: Salvatore (IW1AYD) Copyright © 2026 Salvatore IW1AYD. Tutti i diritti riservati.

Questo documento può essere distribuito liberamente agli appassionati di radioamatoriale, purché se ne citi la fonte e non venga modificato senza autorizzazione.