Dal cuore di pYSFReflector versione 2, che possiamo definire “monoflusso”, assistiamo alla genesi di un nuovo modo di gestire le connessioni C4FM grazie alla versione 3 del software di IU5JAE, pYSFReflector “multiflusso”. Quindi non pensiamo più ad un sistema che riceve un flusso dati e lo ritrasmette a tutti i sistemi ad esso connessi, ma ad un concentratore intelligente, uno “switch di rete” che, grazie alla selezione del DG ID (sulla radio) proprio del protocollo C4FM discrimina i flussi e li trasmette ai soli sistemi che utilizzano lo specifico ID. Per fare un esempio proveniente dal mondo DMR abbiamo a disposizione 99 “Talk Group” che possono essere usati su pYSF3 (da DGID 0 a DG ID 99). Questo sistema porta all’utilizzatore finale una gestione estremamente semplice e pratica che, grazie una impostazione sulla radio, potrà passare da un flusso ad un altro (in sintesi: da una room ad un’altra) senza necessità di ricordarsi numeri su numeri. Per meglio spiegare come questo software funziona ne descriveremo a seguire le varie operatività e configurazioni che, molto importante, possono variare per scelte specifiche del gestore del sistema (sysop) server. Vedremo anche che con BrandMeister Italia (Server Ufficiale DMR BM2222) e su DMRPlus Italia (Server DMR IPSC2-IT-MLINK) sono stati mantenuti degli standard consolidati di utilizzo proprio per agevolare l’utilizzatore finale degli impianti RF. Questo almeno sul sistema che verrà reso disponibile e collegato ai master. Parleremo di multiprotocollo anche se pYSF3 è un sistema C4FM, ma questa prassi di ritrovarci tutti con modi (protocolli digitali) e radio diverse (e, aggiungo, con ottima qualità funzionale e di ascolto) è quanto di più apprezzato dall’intera platea digitale radioamatoriale.
pYSF3 è Open Source, il codice è libero, modificabile, a disposizione di tutti. Creato con linguaggio Python (versione 3) per avere flessibilità e leggerezza funzionale, pYSF3 è il motore del sistema; i dati trattati vengono successivamente “gestiti” da un software collettore (sempre scritto in Python) che li deposita in un database ed in ultimo delle pagine web scritte con linguaggio PHP/HTML5 prelevano dal database le informazioni e le pubblicano, accessibili a tutti su internet. La primaria funzione di questo sistema “a più flussi” è quella di semplificare il network: i singoli reflector (ognuno con la propria funzione e connessione) potranno essere anche rimossi. Il tutto sarà più semplice, sia da trovare (nella lista dei server) che da manutenere/aggiornare/controllare.
pYSF3 può essere “monoflusso” ed operare come il classico (vecchio) YSF di Jonathan e il nuovo pYSFReflector e pYSF2 di Antonio, quindi al massimo avere solo una connessione da e per l’esterno con altri server/room, o “multiflusso” quindi ricevere in ingresso ed in uscita più flussi digitali. E’ una configurazione che si gestisce nel file .ini del reflector ed è legata a cosa questo software dovrà andare a fare. Ad ogni “connessione” è abbinato un DG ID; se la connessione è presente (attiva sul reflector) quando verrà utilizzato tale DG ID la nostra voce verrà instradata verso altri sistemi, se non vi sono link/bridge operativi allora si viene a creare una “room privata”. Questa modalità permette la non installazione di ulteriori reflector/server, ma una razionalizzazione delle risorse e praticità d’uso.
Esempio di configurazione di flussi (DG ID) che il sysop del sistema ha deciso di rendere fruibili sul reflector (pysfreflector.ini):
Come indicato sopra, l’uso del DG ID 30 ci permetterà di parlare con il “flusso Multiprotocollo Lazio” (in DMR il TG 2230), e così via, come da tabelle indicanti i TG Multiprotocollo in uso sulla rete italiana BrandMeister e DMRPlus. Evidenziamo la presenza di un DG ID di “default” e sarà il flusso assegnato a chi si collegherà con il proprio ripetitore e hotspot senza impostare il DG ID (in questo esempio è il 41 corrispondente a Toscana, TG DMR 2241, ma verrà gestito sul 22 in una collocazione più completa: Multiprotocollo Italia) ed un DG ID “locale”. L’impostazione locale è utilizzabile quando vogliamo parlare sul solo ripetitore in uso, senza necessità di disconnetterlo dalla rete/server. Ovviamente la mia zona operativa sarà limitata al raggio di azione del ripetitore. Diversamente l’utilizzo (in questo caso) del DG ID numero 9 mi permetterà di fare QSO in “modalità privata” ovvero senza uscire verso altri server/link, ma con tutti i colleghi che, presenti sul reflector, impiegheranno tale configurazione (lo stesso ID). In questo modo, molto velocemente, potrò passare da un QSO affollato ad uno privato (o quasi) con il solo cambio di impostazione sulla radio ricetrasmittente.
pYSF3 è anche “multiporta”, ovvero permette in modalità fissa di collegare un flusso su di una porta specifica. In questo modo potremmo avere, su di un unico reflector, due (o più) connessioni con BM (due DGID e due TG distinti). Questa impostazione è molto tecnica e, oltre alla valutazione di reale fattibilità e necessità, deve essere fatta in concerto con i gestori del server BrandMeister. A seguire un esempio estrapolato dal file di configurazione:
# aux ports linked statically at DG-ID (empty string if not used)
# format:
# DG-ID:port
aux_port = 41:42397, 88:42398
Queste connessioni sono identificate come FIXED sulla dashboard:
Il sysop del reflector ha inoltre la possibilità di gestire degli “YSF virtuali“, configurati nella sezione REFL_ALIAS, come nell’esempio:
[REFL_ALIAS]
refl_01 = 41, 26045, IT GRF-YSF, TUSCANY MULTIP
Utilizzando la configurazione e i parametri presenti sul registry mondiale degli YSF (ID26045, NOME, DESCRIZIONE) si crea un “alias” abbinando la configurazione ad un DG ID attivo (sezione DGID, 41). Chiaramente il proprietario del reflector YSF originale deve “riconfigurare” sul registry la nuova destinazione (IP/DNS di pYSF3)/porta(42397 nell’esempio). Eseguite queste modifiche pYSF3sarà in grado di gestire un “YSF virtuale” per ogni DGID permettendo quindi di non perdere l’identificativo originale e di spengere il vecchio reflector per una ottimizzazione delle risorse e dei sistemi. Inoltre sui ripetitori e hotspot non sarà necessario apportare modifiche perchè “crederanno” sempre di collegarsi alla room configurata in origine, ma funzionalmente saranno connessi a pYSF3.
Esempio di due flussi “in operatività” (colore VERDE sulla riga interessata), ovvero QSO in corso (stato TX) sul DG ID 36 (Lombardia) e 30 (Lazio):
4 flussi operativi (QSO):
Per completezza: gli altri stati del QSO possono riportare TC (trasmissione completata correttamente), WD (watchdog, interrotta dal reflector) e TO (timeout, superato il tempo massimo di trasmissione).
La selezione del DG ID, quindi il cambio di flusso, è immediata. Un colpo di PTT (che non sarà propagato in rete per non disturbare) con la nuova selezione e se c’è un QSO in corso inizierò subito a parteciparvi.
Il cambio di DG ID viene evidenziato sulla dashboard di colore azzurro. Il colore giallo identifica una trasmissione chiusa dal watchdog del reflector, quindi non ottimale. Rosso un evento di timeout.
Altra particolarità interessante: spostando il mio ripetitore/hotspot su di un flusso, allo spengimento dello stesso (o interruzione di internet ad esempio) non dovrò poi impostare nuovamente il flusso di destinazione perchè pYSF3 si ricorda l’ultimo DG ID utilizzato. Se lasciamo il DG ID 00 (non occorre MAI modificare la parte RX ma solo quella TX) verrà utilizzato l’attuale flusso presente sul ripetitore/hotspot che stiamo utilizzando per entrare sul sistema.
Per chi le dashboard non le guarda pYSF3 viene in aiuto. Lato RF verrà inviato (se abilitato suil server) il numero del DG ID (flusso in uso) anteposto al nominativo. Quindi avremo ad esempio: 41/IK5XMK. Questo indica che IK5XMK sta parlando sul flusso 41 e viene visualizzato nel display della radio. Nessuna modifica invece verso le connessioni in uscita dal reflector (ad esempio BrandMeister).
Questa breve panoramica ci permette di capire alcune delle funzionalità principali offerte da questo software. Rimane attiva e configurabile la gestione dei blocchi dei nominativi, dei seriali, etc. già implementate in pYSF2. Le connessioni con altri sistemi possono essere implementate (sempre accordandoci con i gestori dei network interessati) usando il software ysf_bridge e ysf2dmr o mmdvm_bridge. Lo stesso BrandMeister può gestire la connessione verso pYSF3. (connessione YSF standard) .
Per visionare e provare il nuovo reflector è disponibile il server YSF#22220 BM ITALIA, con dashboard raggiungibile al seguente indirizzo:
Questa la configurazione C4FM/YSF su distribuzione Pi-Star, di default verremo collegati al flusso DG ID 22:
Il server/reflector YSF#22220 IT BM2222 Italy gestisce le connessioni con tutte le regioni italiane utilizzando i DG ID corrispondenti ai TG DMR MULTIPROTOCOLLO presenti su BrandMeister (es. LAZIO TG 2230, DG ID 30 … e così via), nel futuro possono essere previste implementazioni:
Nota Bene: per rendere “FIXED” il sistema, quindi non spostabile dall’utilizzatore, occorre solo aggiungere il DGID dopo il nominativo impostato sul ripetitore/hotspot, del tipo IR5UDN-41 (per la Toscana).
Le ultime implementazioni prevedono due configurazioni interessanti da sottoporre all’attenzione del SYSOP del server reflector: la prima (presente sempre nel file di configurazione pysfreflector.ini) gestiste l’invio del DG ID anteposto al nominativo verso l’uscita RF (display della radio). Nel particolare: prefix = 1 attiva nn/Calsign (utile, in ascolto, per capire da che flusso sta provenendo il QSO), prefix = 0 (ZERO) porta l’uscita del solo nominativo. La funzione prefix, per la natura di come è stata progettata, blocca anche dei “ritorni” di flusso anomalo da alcuni ripetitori generalmente causati da problemi di connettività. La seconda configurazione (file home.db) gestisce il “back to home” ovvero il ritorno, dopo un periodo di tempo, del ripetitore al flusso (DG ID) preimpostato. Quindi se un collega invia un DG ID per fare QSO su di un flusso, in assenza di traffico lato RF l’impianto tornerà alle indicazioni (DG ID) comunicate al SYSOP del server. Tutta la configurazione, se impostata, è visibile sulla dashboard nella pagina dedicata ai sistemi connessi. Un esempio di impostazione nel file: IR5UDN:41:15 che significa: il ripetitore IR5UDN, in assenza di traffico sull’impianto, torna sul flusso DG ID 41 (MP Toscana) dopo 15 minuti di inattività.
Informazioni sull’utilizzo del sistema:
pYSF3 #22220 BM_01012022 (by IW4EHJ)
DISPONIBILE IL SOFTWARE SU GITHUB, VEDI QUESTO LINK