Un unico comando per spostare tutti i ponti D-Star [parte 1]

di | 15/01/2015

Premessa, una necessità.

Questo testo nasce da un esigenza pratica, ovvero tutto il nostro gruppo (e non solo visto che i sistemi D-Star stanno ultimamente crescendo, e questo fa enormemente piacere) viene “ospitato” al momento sul DCS 008 modulo D (D sta nella configurazione che è stata preimpostata da qualcuno per “centro Italia”). E’ una sorta di “calderone”, ovvero una raccoglitore di tanti sistemi D-Star fra cui ponti ripetitori, hotspot privati, dongle, etc. tra loro connessi via internet. Praticamente un software fatto da DG1HT (e altri? non saprei …) che gira su di un server in Germania (anche questo penso, non vi è molta informazione purtroppo in giro e se qualcuno ha ulteriori info ce le mandi, grazie).

Ma cosa succede se questo “pentolone” digitale per qualche motivo va giù ? Un aggiornamento, un malfunzionamento, il raggiungimento di certi limiti… All’atto pratico da essere tutti connessi diveniamo in un istante “tutti isolati”, e da qui la rincorsa a mandarci una mail di avviso, un SMS, per ritrovarci ad esempio su di un sistema di backup (per il nostro gruppo abbiamo tirato su il Reflector XRF077, come indicato negli altri articoli pubblicati), ma non è immediato lo spostamento, anche solo per il fatto di collegarsi ai vari ripetitori ed inoltrare il comando di connessione ad altro sistema, e poi ci sono gli hotspot che vengono gestiti dai singoli utenti. Insomma, un bel “casino” come si dice a Firenze … Da qui l’idea: ma sarebbe possibile con un solo comando gestire tutta una catena di sistemi che aderiscono al progetto per attivare uno “spostamento di massa” ? Ovvero passare con un “colpo di portante” da 10 sistemi connessi sul DCS, ad esempio, ad una connessione complessiva su un XRF  senza dover fare tante chiamate e SMS di avvertimento ? Ovviamente alla fine dell’emergenza, con un altro colpo di PTT tornare al sistema iniziale. Si è tutto fattibile perchè il software ircddbgateway di G4KLX comprende tra i vari moduli anche questa possibilità… Vediamo assieme come realizzare questa soluzione, ovviamente migliorabile soprattutto in termini di sicurezza, ad esempio impiegando connessioni cifrate col protocollo SSH e certificati condivisi, ma per adesso, per partire come si dice, può andare bene anche così, sperando che il tutto sia di stimolo ad altri colleghi in ulteriori implementazioni.

La situazione attuale.

Vediamo bene una situazione tipo su questo schema, per ovvi motivi riassunto: IZ5ILH sta parlando con IW5EKI, uno su di un ponte ripetitore in UHF, l’altro su un ripetitore in VHF, ci sono degli hotspot dislocati fuori provincia, altri OM in ascolto su questi sistemi. Il collante: tutti sono connessi al DCS il quale ritrasmette a tutte le stazioni presenti quanto viene detto dai due colleghi. E’ un piccolo microcosmo, pensiamo invece siano collegate 40 e più stazioni radio tra ponti ripetitori e altro. E’ la situazione del momento, tutto è operativo ed il QSO prosegue senza problemi.

Vi è un problema. Per un motivo fra tanti il DCS non funziona più, è “giù” come si dice in gergo… Attendiamo qualche minuto ma il sistema non riparte, a questo punto vi è la necessità di cercare un “rattoppo”, ovvero provare a spostarci su qualche altro sistema (un  “pentolone” che potrebbe essere un XRF qualsiasi, o un altro DCS) per ritrovare i colleghi che prima stavano parlando. Ma tutti sono pronti e capaci nello spostamento ? E chi avvisa i colleghi che magari non sono al momento presenti ma che utilizzano un loro hotspot ? E vai di SMS, ma la cosa sta diventando complessa perchè metti che tra 30 minuti il DCS riparta… e chi li riavvisa nuovamente ? Uno scenario apocalittico, hi !! Ovviamente la sto buttando sullo scherzo, è un hobby il nostro, ma se miglioriamo il divertimento che male c’è ? 😉

La soluzione, il “colpo di PTT” che ci toglie dai guai.

Guardiamo lo schema seguente e commentiamolo.

IZ5ILH ha nel suo apparato radio alcune memorie già impostate, seleziona quella che prevede di inviare il comando di passaggio su XRF (nella parte 2 di questo testo parleremo in dettaglio di come fare) e preme il PTT sulla frequenza del ripetitore “capo maglia”, ovvero il sistema padre che inoltrerà a tutti i sistemi figli l’ordine di spostarsi. Il ripetitore padre, nel nostro caso IR5UBO come da schema, riconosce il comando, lo accetta ed esegue uno script, ovvero una serie di istruzioni in modo sequenziale. Inizierà a contattare IR5AY, il suo primo figlio, che da bravo ha sempre un orecchio in ascolto su di una certa porta (vedere il significato di “porta in ascolto” su Google per maggiori dettagli tecnici) perchè così gli abbiamo detto di fare, e questi, ricevendo la “chiamata” dal padre obbedisce e prontamente, usando il software “remotecontrold” presente a borso, commuta la sua connessione (anzi, al momento si trova in stato disconnesso se il DCS non è operativo)  su XRF. IZ5ILH potrà subito continuare il qso con IW5EKI perchè i due ponti ripetitori si ritroveranno sullo stesso “pentolone” ovvero un XRF, ma IR5UBO non si ferma perchè ha altri figli, e continua sempre in sequenza ad inoltrare comandi agli altri hotspot; così facendo, uno dopo l’altro, tutta la catena sarà gestita e i vari sistemi si ritroveranno assieme nuovamente. Quando vorrà IZ5ILH selezionerà un’altra memoria e con un secondo comando ordinerà a tutta la catena di sistemi di spostarsi nuovamente, tornando ad esempio sul DCS.

Requisiti obbligatori:

a) dobbiamo individuare un “capo maglia”, un ponte ripetitore a cui invieremo (e solo a lui) i comandi via RF;

b) tutti i protagonisti (ponti ripetitori. hotspot, etc.) devono essere collegati su internet e raggiungibili attraverso una porta che dovrà essere “girata” sul relativo router;

c) su tutti i sistemi deve essere operativo il software ircddbgateway di Jonathan ed essere attiva la sezione relativa al controllo remoto, con indicata un numero di porta (non è quella sopra menzionata, ma quella standard 10022) ed una password;

d) tutti gli attori non devono essere “chiusi”, ovvero devono poter accettare i comandi di connessione e disconnessione, ovvero non essere configurati a rimanere sempre e solo collegati ad un certo sistema.

Nella seconda parte vedremo in dettaglio le varie configurazioni. Ripeto nuovamente che questa è stata ed è per me una interessante prova, sicuramente migliorabile nella programmazione e nella sicurezza ed estendibile, che spero serva per nuovi spunti.