La stringa Options in MMDVM e l’uso dei reflector su DMRPlus

di | 24/02/2019

I server IPSC2 che gestiscono la rete DMRPlus permettono (se abilitati dal Sysop del server) la connessione di sistemi Hotspot e ponti ripetitori con l’ID DMR a 7 cifre, l’ID personale che può essere richiesto attraverso una semplice procedura a questo indirizzo URL. La connessione è attivata verso il server in totale autonomia  senza necessità di richiedere impostazioni al Sysadmin di IPSC2 per le configurazioni dei flussi voce. Questo per i sistemi che utilizzano MMDVM quale software di gestione; i ponti Motorola e Hytera richiedono impostazioni lato server. Nell’esempio a seguire la configurazione della connessione di un ponte ripetitore verso il server IPSC2-TUSCANY della rete DMRPlus:

Nel file MMDVM.ini, sezione DMR Network, del ripetitore inserire:

La personalizzazione delle funzioni (flussi voce) del ripetitore avviene con la configurazione della stringa Options nella medesima sezione del file:

Nel particolare abbiamo richiesto la connessione all’avvio (StartRef=) al Reflector (concentratore, punto di unione di flussi voce) 4255 che corrisponde al Multiprotocollo Toscana TG 2225 (questo grazie ad una “mappatura” presente sul server IPSC2), un tempo di riconnessione (RelinkTime=) allo stesso dopo un periodo di inattività di 60 minuti, l’aggiunta (TS1_1=) sullo SLOT 1 del TG 222 in modalità statica (flusso sempre aperto, senza possibilità di escluderlo). I Reflector sulla rete DMRPlus vengono gestiti sempre sullo SLOT 2 e possono essere “disconnessi”, quindi liberare il ponte per un totale uso locale senza nessun arrivo forzato di flussi voce, semplicemente con una pressione di PTT programmato con il contatto 4000 (private o group call il funzionamento è lo stesso, ma con private call l’aggancio/sgancio del Reflector non invia il flusso all’intero network). Alla fine del QSO posso rendere un colpo di contatto 4255 per ri-collegare il Reflector 4255, oppure semplicemente attendere il periodo impostato nella stringa Options, valore di RelinkTime. Il contatto 4000 ha funzionalità SOLO se presente la connessione al Reflector e se vi è un TG richiesto “on demand”, se i flussi sono impostati staticamente “a TG” nulla viene alterato.

Esempio di “mappatura”, ovvero un collegamento tra Reflector e TG (multiprotocollo zonale), impostato sul server:

Si capisce bene che, a differenza dell’avere i flussi TG in modalità statica e/o assegnati dal Sysop del server, l’uso del Reflector da la piena possibilità di sgancio dal sistema oltre a organizzare anche una “stanza” tra due o più ripetitori che si trovano sullo stesso Reflector (tipo “un cluster”). La lista completa dei Reflector gestiti nella rete DMRPlus è visionabile a questo indirizzo URL, fermo restando che sul server IPSC2 (o sui server dello stesso network) ci sia una mappatura (riferimento) tra il Reflector stesso ed un TG. Diversamente il QSO sarà fattibile solo sui sistemi collegati fisicamente al Reflector e non tra questo e il TG (es. Reflector Toscana/Zona 5 n.4255 e il TG 2225). Il QSO sul Reflector avviene usando il TG 9 (come un qualsiasi QSO LOCALE), ma se in quel momento il ponte ripetitore è connesso al Reflector, non sarà QSO LOCALE ma girato verso la stanza/Reflector. Se vi è la mappatura ascolterò anche il traffico proveniente dai “classici” TG.

Se viene usata la configurazione “a reflector” posso usare il contatto 5000 per capire su quale sistema è connesso il ripetitore, una voce mi indicherà il numero di Reflector oppure “not connected” se libero.

Altra configurazione:

In questo esempio invece non si fa uso dei Reflector ma si assegna “staticamente” sullo SLOT 1 il TG 222 (Italia) e il TG 1 (WW), mentre sullo SLOT 2 il TG multiprotocollo 2225 e “solo DMR regionale condiviso” 2241, per la Toscana. Così NON sarà possibile liberare totalmente il ponte ripetitore perchè potrò usufruire solo dell’impegno di usare un altro TG tra un passaggio e l’altro del QSO in corso, ma passati i classici 15 secondi (prassi di impegno TG statico sul ripetitore) mi potrà tornare il flusso del TG assegnato staticamente. Questa è la differenza tra usare il Reflector e il TG statico, oltre quella di creare una “stanza” tra sistemi.

La stringa Options è gestibile anche sugli hotspot e, come i ponti ripetitori, è possibile assegnare staticamente fino a 5 TG sullo SLOT 1 (TS1_x=;) e 5 TG sullo SLOT 2 (TS2_x=;). Ogni impostazione è separata dal ” ; ” (punto e virgola). Di seguito un esempio di configurazione (solo uso del TG 2225 su SLOT 2) ottenibile su hotspot gestito da software MMDVM/Pi-Star:

Rappresentazione sulla Dashboard del server (non ha senso inserire anche il Reflector 4255 perchè già presente il TG mappato dal Sysadmin):

Ricordiamo che ad oggi NON è possibile impedire l’utilizzo di un TG che è presente in uno dei flussi (Matrice) del server IPSC2 o se condiviso sul bMaster+ (server centrale). Anche se questo non è inserito staticamente sarà sempre richiamabile “on demand”. Inoltre, poichè abbiamo due SLOT sui ponti ripetitori, non è sbagliato configurare il TG 9 anche sullo SLOT 1 ed usare questo TG/SLOT per i veri QSO locali senza necessità alcuna di disconnessione da Reflector. Per facilitare la programmazione del Codeplug del ricetrasmettitore DMR l’impiego del Reflector è assai una strada interessante per la gestione del ripetitore perchè con la sola programmazione del TG 9 su entrambi gli SLOT tutti i Reflector possono essere facilmente inseriti nella lista dei contatti e richiamati “al momento del bisogno”.

NOTA BENE: non vi è necessità di riprogrammare i codeplug togliendo quanto presente, se vi trovare a transitare su di un ripetitore in “modalità reflector”, accetta comunque il classico TG; nel nostro caso se viene dato il TG 2225 o il TG 2241 continuerà a funzionare come prima. Ripeto: la differenza non è in “uscita” dal ripetitore, ma in “entrata” ovvero nella possibilità di scollegarlo. Si consiglia di utilizzare il Reflector 4255 e lasciare il ponte connesso ad esso per avere un “canale di ascolto/chiamata” univoco per tutti, ovvero lo zonale multiprotocollo.

Buone prove, il server IPSC2-TUSCANY è disponibile per ogni prova e sperimentazione.

David [ ik5xmk@gmail.com ]