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:

Esempio di due flussi “in operatività”, 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. 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 sempre 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) Finito il periodo di TEST verrà reso disponibile il software e alcune informazioni tecniche sulle configurazioni.

Per visionare e provare il nuovo reflector è disponibile il server YSF#22220 BM ITALIA, con dashboard raggiungibile al seguente indirizzo:

LINK DASHBOARD

Questa la configurazione C4FM/YSF su distribuzione Pi-Star, di default verremo collegati al flusso DG ID 22:

Nota Bene: per rendere “FIXED” il sistema, quindi non spostabile, occorre solo aggiungere il DGID dopo il nominativo impostato sul ripetitore/hotspot, del tipo IR5UDN-41 (per la Toscana).

 

pYSF3 #22220 BM Modalità operative (by IW4EHJ)

Di ik5xmk