Molte volte è stato chiesto come creare un proprio sistema multiprotocollo digitale radioamatoriale, magari per uso locale dove collegarci qualche hotspot e il ponte ripetitore di zona, che sia questo DMR o C4FM. Un “piccolo mondo” autogestito, senza troppe regole di utilizzo e che non implichi problemi nel tenerlo acceso o spento, comunque usufruibile da tutti i radioamatori, del posto e non, che utilizzano sistemi radio diversi. Questa esigenza è sempre stata presente; da un lato molti colleghi reclamano unità nei collegamenti, condivisioni fra infrastrutture, copertura capillare. Ma altresì, in parallelo, la voglia (e l’esigenza) di localizzare un QSO in una modalità “più ristretta” (discreta, non molto pubblica) non è da sottovalutare. Come di dice dalle nostre parti “non è a farli, ma a trastullarli…”, per accontentare sempre tutti. Proviamo quindi a descrivere un microcosmo su di una piattaforma Linux, gestita con software open-source e/o ad uso radioamatoriale, che non necessiti di hardware aggiuntivo da dedicare ai processi di transcodifica.
La scelta verte sui protocolli radioamatoriali DMR e C4FM, ma può essere facilmente estesa al protocollo NXDN scaricando il relativo software ed adeguando le configurazioni del caso. Consigliamo, come piattaforma hardware, visti gli attuali costi, un server VPS presso un datacenter con installato Linux Debian. Molti provider offrono anche il servizio “snapshot” quindi una copia giornaliera dell’intero sistema, una immagine di backup pronta per essere ripristinata in caso di problemi. Non ci soffermeremo sull’installazione/aggiornamento e personalizzazione del sistema operativo e risorse collaterali: come più volte ricordato, chi si avvicina all’implementazione di queste soluzioni radioamatoriali deve avere una buona base informatica poichè non è sufficiente attivare una volta e via il sistema ma occorre anche controllarlo periodicamente e approntare i periodici aggiornamenti al software.
I protocolli DMR e C4FM “parlano” bene tra loro: il primo deriva da una impronta civile riadattata per i nostri utilizzi, il secondo nasce (e si utilizza e configura lato radio) per “il radioamatore”. Valutando “lato server” l’implementazione del nostro multiprotocollo non possiamo fare a meno di capire anche cosa verrà ad esso connesso. L’utilizzatore radioamatore potrà quindi collegare il proprio hotspot personale, che sia la classica “distribuzione pi-star”, il nuovo “openspot” e altro, utilizzando per il C4FM la modalità YSF quale collettore, ma anche un ripetitore C4FM basato sempre sul sistema MMDVM/YSF. Idem per la parte DMR che, ricordiamo, attraverso l’uso della modalità (protocollo) MMDVM favorisce anche l’autocostruzione degli impianti ripetitori.
Possiamo procedere nel descrivere cosa ci occorre, suddividendo il nostro “nuovo microcosmo” in due parti che parlano tra loro. Per semplicità lato C4FM useremo il software YSFReflector di Jonathan G4KLX che realizza un “reflector”, un collettore di sistemi C4FM (hotspot e ripetitori) collegati tra loro che condividono il medesimo flusso voce/dati. Useremo poi il software MMDVM_Bridge per unire questa parte C4FM con il DMR. L’infrastruttura relativa al protocollo DMR può essere facilmente implementata e gestita con il software HBLink, descritto sempre su questo sito dal collega IU5JAE con articoli molto precisi a cui rimando la lettura. Diversamente, per questo testo, useremo la piattaforma IPSC2-IT-MLINK, un server già pronto e operativo presente nella rete DMRPlus, che nasce con lo scopo di dare a tutti la possibilità di sperimentare le varie interconnessioni e richiedere anche un proprio TG (TalkGroup) da destinare alla realizzazione sperimentale del proprio microcosmo digitale. Ad onor del vero anche l’ottima infrastruttura BrandMeister offre i medesimi collegamenti, ma volendo esclusivamente “baloccarci e fare dei test” è inutile al momento smuovere un funzionale gigante, magari successivamente se il nostro sistema risulterà stabile, utilizzato e sempre operativo, allora si.
Implementazione del reflector C4FM:
- registrazione del nuovo sistema che andiamo a creare sul portale dedicato;
- scaricare il software da github e compilarlo (generalmente inserire l’eseguibile in /usr/local/bin) – (guida dei vari passaggi, in inglese);
- configurare il file YSFReflector.ini (generalmente il file lo inseriamo sotto /etc):
I parametri necessari sui quali operare:
- Name = inserire il nome del reflector formalizzato durante la procedura di registrazione / mail ricevuta
- Port = la porta di ascolto del reflector, generalmente la 42000. Vedi sempre la procedura di registrazione eseguita
Se intendiamo creare dei file di log (necessari anche per la dahsboard) assicuriamoci dell’esistenza del relativo percorso ove verranno registrati (e che sia accessibile con i permessi di scrittura). Per eseguire manualmente il software posizioniamoci nella directory dell’eseguibile e diamo il comando ./YSFReflector [uno spazio] /etc/YSFReflector.ini
Da questo indirizzo è possibile scaricare la dashboard che ci farà visionare i sistemi collegati al reflector. Andrà posizionata nella directory (scrivibile) gestita dal server web Apache (solitamente /var/www/html) che dovrà risultare operativo sul server. La modalità di configurazione della dashboard è riportata sul sito ove è presente il software; in pratica si fa tutto da browser richiamando il file setup.php I log generati dal reflector occupano spazio sul sistema e vanno rimossi periodicamente con opportune procedure. La cancellazione consigliata è ogni 7 giorni, questa è la riga da inserire nel processo cron (ovviamente da configurare il corretto percorso):
12 3 * * * root find /tmp/ram/* -mtime +7 -exec rm {} \;
Di seguito un esempio di visualizzazione della dashboard di un reflector YSF con impianti (hotspot e ripetitori) collegati:
Ricordiamo che il nostro reflector sarà visibile su tutta la rete radioamatoriale YSF, grazie alla registrazione effettuata, dopo un giorno circa perchè i sistemi (hotspot e ripetitori) si aggiorneranno in automatico durante i relativi processi di update. E’ chiaramente possibile non registrarsi per mantenere il sistema “non visibile”, ma in questo caso ogni singolo client (esempio un hotspot) dovrà essere configurato manualmente alla connessione verso il server impostando il relativo IP e la porta di ascolto del servizio.
La prima parte del nostro sistema è conclusa, la gestione del “mondo C4FM” è attiva. Dobbiamo ora occuparci del collettore che congiungerà il C4FM al DMR. Partiamo direttamente dalla configurazione di MMDVM_Bridge, cosa è e come si installa è già stato oggetto di articolo, in precedenza, su questo sito. La visione di insieme della situazione che stiamo trattando sarà: YSFReflector e MMDVM_Bridge operativi sullo stesso server, in dialogo con il server esterno IPSC2-IT-MLINK per la gestione del flusso DMR.
MMDVM_Bridge per collegare il C4FM al DMR:
Occorre editare il file MMDVM_Bridge.ini e gestire i seguenti parametri:
- Callsign = nominativo che verrà visualizzato sulla dashboard dei sistemi interessati (es. LINK_MIO);
- Id = ID DMR regolarmente registrato nel DB mondiale;
Abilitare le sezioni DMR e FUSION:
Continuiamo nella configurazione del file con i seguenti valori sotto la sezione [DMR Network]:
- Enable=1
- Address=it-mlink.grupporadiofirenze.net
- Port=55555
- Password=passw0rd
- Options=TS1_1=XXXX;
- Slot1=1
- Slot2=1
Prestiamo attenzione al parametro Options= che dovrà essere gestito per collegare il flusso C4FM ad un TG DMR (esistente o nuovo). In ogni caso contattare il gestore del server ove vogliamo effettuare il collegamento per le opportune valutazioni e abilitazioni. Es. Options=TS1_1=9123; (termina con “;”) significa che usando il TG 9123 sullo SLOT 1 del mio apparato/hotspot DMR collegato su IPSC2-IT-MLINK potrò parlare con i sistemi connessi al reflector YSF/C4FM che ho configurato.
La sezione [System Fusion Network] dovrà invece essere:
- Enable=1
- LocalAddress=127.0.0.1
- LocalPort=3444
- GatewayAddress=127.0.0.1
- GatewayPort=42000
Riassumendo, l’indirizzo del gateway in questo caso è locale (stesso server) e la porta è quella configurata nel file YSFReflector.ini Niente altro occorre all’interno di MMDVM_Bridge.ini ma rimane da editare il file DVSwitch.ini presente nella directory di MMDVM_Bridge per la gestione dei flussi tra i due protocolli.
Gestione del “partner” DMR che invia e riceve i flussi su due porte sul server che stiamo configurando:
e, conseguentemente, gestione del “partner” YSF/C4FM che usa le stesse due porte, ma invertite TX con RX, ovviamente:
I due “partner” lavorano entrambi (internamente) sullo SLOT 2, la chiave ExportTG deve riportare il valore di TG configurato nel file MMDVM_Bridge.ini riferito alla connessione sul server DMR IPSC2-IT-MLINK, nessunFallbackID impostato perchè i transiti (QSO) devono avvenire tra stazioni radio registrate. Eseguendo il collettore MMDVM_Bridge (vedi precedente articolo) si dovrà visionare il collegamento sul server IPSC2-IT-MLINK con il nominativo (e ID) impostato nel file di configurazione, oltre al relativo TG.
La prova di corretta configurazione e funzionamento la si avrà collegando un primo impianto/hs sulla parte C4FM e un secondo sul server DMR (richiamando l’opportuno TG), l’audio dovrà passare in ambedue i versi con la stessa qualità.
Buone prove e ricordiamoci che le interconnessioni tra sistemi di terzi devono essere dichiarate sempre ai gestori degli impianti/network per evitare problemi e malfunzionamenti.
Per richieste di configurazioni/TG sul server IPSC2-IT-MLINK scrivere a info@grupporadiofirenze.net – i TG già in uso su altri sistemi e network, condivisi, non sempre sarà possibile destinarli a queste interconnessioni e prove.
David IK5XMK