L’implementazione del multiprotocollo in ambito radioamatoriale, se andiamo ad utilizzare software open source (codice libero e modificabile) pensati per la comunità radioamatoriale, prevede l’implementazione di programmi diversi tra loro che interagiscono per portare il flusso dati da un sistema all’altro (quindi da un protocollo all’altro). Pensiamo ad una realizzazione tipo, ovvero la gestione di un sistema DMR, C4FM e DSTAR. Con l’obiettivo di non dipendere interamente da un unico collettore e quindi, in assenza dello stesso, non poter fare interagire i sistemi tra loro, da prove fatte la soluzione funzionale prevede una connessione diretta DMR (un TG — talkgroup –dedicato) dal network BrandMeister (ricordiamo che i network DMRPlus e BrandMeister già condividono tra loro alcune risorse DMR — TG –) sul nostro sistema C4FM. Per questa ultima modalità, attualmente, il software/reflector YSF di Jonathan G4KLX si dimostra perfettamente efficiente anche se presenta delle limitazioni (ad esempio non gestisce una ‘deny list’ in presenza di disturbi ma occorre agire sul firewall del server). Come prima fase già abbiamo operativi due protocolli che interagiscono tra loro (DMR connesso al C4FM, nessuna transcodifica necessaria). Non mi soffermo sulle procedure di installazione e registrazione del reflector YSF C4FM e le varie impostazioni (es. la dashboard del reflector) del server linux ospitante poichè ci sono sufficienti informazioni in rete e comunque è prerogativa conoscere bene una parte sistemistica ed informatica prima di avventurarsi in questo settore del digitale radioamatoriale. Arriviamo infine al protocollo DSTAR che può essere gestito mediante il software/reflector XLX. Compiliamo il software (sul medesimo server) con i moduli richiesti (da gestire con la relativa parte hardware della transcodifica) seguendo le opportune istruzioni e prestando particolare attenzione alla gestione delle porte in uso: un possibile conflitto può nascere dalla porta dedicata al protocollo YSF/C4FM che XLX, nelle ultime versioni, gestisce con propria modalità operativa. Questa porta deve essere differente da quella utilizzata sul reflector YSF connesso al DMR altrimenti XLX non si avvierà. Ricordo che i messaggi (log) di sistema di XLX sono visionabili leggendo il file /var/log/messages. Abbiamo quindi due reflector operativi sul nostro server, il reflector YSF che gestisce il C4FM (e sul quale arriva il DMR con connessione diretta) e il reflector XLX che gestisce il DSTAR. Il problema nasce nel fare comunicare tra loro questi due software che gestiscono protocolli diversi. In precedenza avevamo parlato di YSF2DMR, un programma che permette questo tipo di link. Attualmente invece valuteremo positivamente l’implementazione di MMDVM_Bridge che non solo collega in maniera ottimale il C4FM al DSTAR attraverso l’uso della connessione in modalità MMDVM ma permette anche altre tipologie di interconnessioni. Ci soffermeremo in questo articolo al solo passaggio flussi tra il C4FM e il DSTAR (su di un proprio server/sistema) ricordando che interconnettere tra loro network diversi può creare problemi e va fatto chiedendo gli opportuni permessi ai gestori (sysop) interessati dettagliando la tipologia di operazione.
MMDVM_Bridge e la configurazione C4FM verso il DSTAR (file MMDVM_Bridge.ini)
Generalmente l’applicazione MMDVM_Bridge viene gestita sotto /opt creando una apposita cartella e prelevando l’eseguibile compatibile con il proprio sistema dalla sottocartella bin e rinominandolo semplicemente MMDVM_Bridge. L’esecuzione avverrà poi con il comando ./MMDVM_Bridge ./MMDVM_Bridge.ini & ovvero facendogli leggere il proprio file di configurazione presente nella stessa cartella. Possono essere attivate più istanze di questo software, ognuna girerà nella propria cartella ed avrà la propria configurazione per ulteriori interconnessioni. Di seguito le sezioni di MMDVM_Bridge.ini che andremo a personalizzare con i parametri relativi al sistema in uso.
Inserire un nominativo ( o descrizione del link ) e un ID DMR regolarmente registrato (fondamentale, ricordiamo che le connessioni avvengono con protocollo MMDVM). XLX preferisce ricevere una connessione con ID a 7 cifre, presente nel suo DB.
La sezione DMR deve essere attivata (gestisce il link con XLX via protocollo MMDVM/DMR ( — e non in DSTAR, richiederebbe ircddbgateway e specifiche configurazioni– ).
Abilitiamo anche la sezione C4FM (System Fusion) ed inseriamo nella sezione DMR i parametri di connessione verso il nostro server XLX (Address, port, etc.) specificando nella riga Options= il modulo di XLX al quale vogliamo effettuare il collegamento (4002 = B). Lo SLOT in uso sarà il 2 (è riferito al dialogo tra XLX e YSF Reflector). Nell’esempio i parametri sono quelli di XLX039, occorre mettere i propri.
La sezione System Fusion Network dialoga con il reflector YSF/C4FM presente sullo stesso server (localhost). Prestiamo attenzione alle porte che sono state inserite in fase di installazione di tale reflector. Niente altro occorre fare in questo file di configurazione, le due connessioni in modalità MMDVM sono state preparate e vengono viste dai rispettivi server reflector come comuni ripetitori/hotspot. L’altro file di configurazione gestito da MMDVM_Bridge è DVSwitch.ini e deve essere presente nella cartella dell’eseguibile (solitamente stessa cartella di MMDBM_Bridge.ini). In questo file vengono configurate le porte per lo scambio dati/flussi dell’instanza attiva di MMDVM_Bridge. Ci interessa nella specifico la sezione DMR e YSF.
Configuriamo una porta per la trasmissione (TX) ed una per la ricezione (RX) del flusso di collegamento YSF/XLX, sezione DMR. Lo SLOT, come sopra riportato nel testo, è il 2. Le porte DEVONO essere libere e per uso esclusivo di MMDVM_Bridge.
Sezione YSF: vediamo che le porte TX/RX sono chiaramente invertite rispetto a quelle della sezione DMR, il flusso trasmesso da una parte viene ricevuto dall’altra. Lo SLOT è il 2, non viene inserito nessun ID DMR di backup, per transitare su questi sistemi è necessaria la registrazione anche in DMR oltre che DSTAR, lato utente. L’export TG non ci interessa, verso XLX qualsiasi TG andrà bene, è un unico flusso non gestibile a livello di TG ma solo tramite la specifica connessione. A questo punto è possibile eseguire l’istanza di MMDVM_Bridge e dovremo vedere le connessioni presenti sulle dashboard dei due reflector interessati. Il flusso verrà così veicolato in questa catena: BM <-> YSF REFL <-> MMDVM_Bridge <-> XLX REFL. Ricordo alcuni comandi linux utili per monitorare la corretta esecuzione dei processi: “top“, “ps aux | grep MMDVM“, “ps aux | grep YSF“.
Buone prove, David IK5XMK
ps. per giusta esposizione è bene indicare che il flusso DMR può anche essere interamente gestito via IPSC2/DMRPlus, senza interconnessione con BM. In questo caso lavoreremo su una apposita istanza di MMDVM_Bridge che interconnetterà YSF Reflector a IPSC2 server. Potrà essere oggetto di un prossimo articolo.