Connessioni multi-protocollo DExtra, DPlus, DCS,Controlliamo il

Connessioni multi-protocollo
DExtra, DPlus, DCS
Il nostro reflector D-Star XRF077 (Server per la condivisione
del flusso dati verso tutti i sistemi connessi) è diventato
già da tempo XLX077. Questo significa, come anche per tutti i
reflector XLX a lui connesso, che può operare in
“multiprotocollo” ovvero accetta in ingresso connessioni dai
ripetitori e hotspot in modalità DExtra, DPlus e DCS. Il
protocollo DPlus è il “linguaggio originale primario”
sviluppato per supportare i sistemi ICOM. Successivamente si è
diffuso il protocollo DExtra, open source, sviluppato da Scott
KI4KLF, e infine il protocollo DCS (Digital Communication
Service) sviluppato in Germania. Per una idea dei sistemi
reflector attualmente collegati fra loro (“peers”, usano un
protocollo proprietario denominato XLX per la connessione tra
i
link:
server)
seguire
questo
http://xrf077.duckdns.org/db/dashboard/index.php?show=p
eers
E’ bene ricordare che per collegare dal proprio ripetitore (o
hotspot D-Star casalingo) un XLX va opportunamente aggiunto
nel relativo file di identificazione del protocollo un record.
Nel dettaglio, prendendo come esempio il nostro reflector 077
(ogni server reflector ha il proprio IP/DNS) per aggiornare il
proprio sistema:
CONNESSIONE DEXTRA: editare il file DExtra_hosts.txt ==>
inserire XRF077 xrf077.duckdns.org
CONNESSIONE DPLUS: editare il file
DPlus_hosts.txt ==>
inserire REF077 xrf077.duckdns.org
CONNESSIONE DCS: editare il file DCS_hosts.txt ==> inserire
DCS077 xrf077.duckdns.org (questa tipologia di connessione è
indicata in presenza di una connettività non performante e
stabile, es. rete mobile o wi-fi)
IMPORTANTE: non è necessario eseguire NAT e aperture di porte
per le connessioni a reflector XLX
La lista aggiornata dei reflector XLX, e quindi identificare
il record che ci interessa inserendolo nei file come sopra
indicato,
può
essere
scaricata
da
questo
indirizzo: http://xlxapi.rlx.lu/api.php?do=GetReflectorHostnam
e
Quanto sopra indicato non deve interessare il semplice
utilizzatore del sistema perchè la gestione della
configurazione è demandata al sysop del ripetitore.E’ altresì
buona norma per l’utilizzatore attendere sempre qualche
secondo prima di premere il PTT; si capisce bene che ci sono
molti e vari sistemi connessi tra loro, ed è importante, oltre
che per fare entrare altri colleghi nel QSO, lasciare i tempi
di sincronizzazione necessari.
Proseguiamo nel “dettagliare” in maniera semplice come le
informazioni vengono mostrate sulla dashboard del reflector
(una lavagna, un cruscotto che riepiloga le varie informazioni
sui transiti e posizionamento dei ponti ripetitori sul
server).
Una
panoramica
può
essere
visionata all’indirizzo: http://xrf077.duckdns.org/db/dashboar
d/index.php
La dashboard è uno strumento fondamentale; chi opera “in
digitale” sa benissimo che dietro alla sua emissione in radio
ci sono complicati sistemi di rete, protocolli, server. Questo
il motivo per il quale al ricetrasmettitore, quando possibile,
va affiancato l’uso e la conoscenza della dashboard: su di
essa vengono mostrate le informazioni necessarie ad un
corretto utilizzo dei sistemi. Usare i protocolli
radioamatoriali digitali senza un minimo di studio e
approfondimento è quantomai riduttivo e cagionevole di
problemi. Troppe volte è stata data colpa al “sistema
digitale” di malfunzionamenti quando l’utilizzatore non è
neanche in grado di programmarsi correttamente il proprio
ricetrasmettitore (saltiamo qui i dettagli di questa fase
poichè già l’argomento è stato affrontato e approfondito a
sufficienza).
Il primo passo è quello di conoscere i pulsanti presenti:
Il bottone “users/modules” mostra una lista degli ultimi
nominativi
“transitati”
sul
sistema,
a
seguire
“repeaters/nodes” visualizza i ripetitori radio e hotspot
connessi al reflector. Il bottone “peers” come in precedenza
accennato permette di ottenere un elenco dei server tra loro
connessi e i relativi moduli condivisi. “Reflectorlist” mostra
l’elenco di tutti i server (non forzatamente tra loro
connessi) esistenti nel mondo e regolarmente registrati al
database centrale; “d-star live” è una finestra “live” ovvero
in tempo reale sul traffico radio attualmente operato. Vediamo
in dettaglio le singole opzioni partendo da “users/modules”:
Il passaggio di ogni trasmissione/nominativo è evidenziato con
una riga nella tabella. A seguire il nominativo (N0CALL può
significare un passaggio non identificato da un’altra rete,
come il suffisso /DMR evidenzia il flusso proveniente dal
sistema DMR connesso al reflector), il suffisso (dati
preimpostati nel proprio ricetrasmettitore), la posizione su
APRS (http://aprs.fi) se correttamente trasmessa dal
ricetrasmettitore/sistema gps. Infatti facendo click sul
nominativo si apre la pagina di QRZ.com
comunicandoci i
dettagli del collega e sul simbolo gps la mappa con la
posizione. La colonna “via/peer” mostra la “provenienza” della
trasmissione, nella fattispecie se sta usando un
ripetitore/hotspot direttamente connesso a questo reflector
oppure se sta transitando da un altro sistema (un altro server
reflector) coneesso come “peer” (come detto prima, un XLX
collegato al nostro). Prendendo in esame la tabella sopra
mostrata si vede che il collega IZ5ILH con suffisso /ID51 ha
effettuato un passaggio attraverso il suo nodo (hotspot)
IZ5ILH C (in VHF, B = UHF) alle ore 11 e 24 minuti sul modulo
B del reflector (ultima colonna). Ma cosa significa “sul
modulo B” ? Ogni reflector XLX ha più moduli (stanze) a
disposizione. Per convenzione il modulo B è la “stanza
nazionale italiana” e su tale modulo si fa QSO a carattere
generale e nazionale, quindi di comune interesse fra colleghi
nelle varie regioni. Il modulo A è riservato a collegamenti
“fuori Italia” mentre il C è a carattere regionale; viene
quindi utilizzato, dopo aver preso un primo contatto sul
nazionale, per spostarci sopra il ripetitore in uso. Così
facendo non si “monopolizza” il modulo nazionale e si riserva
il regionale per QSO locali. Generalmente il ripetitore può
essere spostato attraverso toni DTMF dati dal proprio
ricetrasmettitore (es. B77C sposta un ripetitore connesso al
reflector XLX077 sul modulo C) o inserendo nel campo UR del
trasmettitore (solitamente presente”CQCQCQ”) il comando
“XRF077CL”. Anche in questo caso non mi dilungherò sulla
configurazione e comandi da dare sugli apparati radio, c’è
ampia documentazione su internet e sul nostro sito. Le colonne
seguenti, con intestazione “[B] Italia”, etc. (ogni reflector
può avere le proprie “scritte”) mostrano appunto queste
“stanze” dove sono connessi i vari ponti ripetitori e hotspot
D-Star. Sempre prendendo in esame la figura sopra si nota che,
ad esempio, il ripetitore IQ5QE-B (in UHF come da lettera B) è
connesso al modulo C e sarà impiegato “localmente” per i QSO
in Toscana. Può essere “spostato”.
Cosa sono i “nodi” collegati al reflector?
Un reflector “vive” se ad esso ci sono ponti ripetitori e
hotspot collegati. Questi, in gergo, si chiamano “nodi”. Il
flusso dati passa tra di loro e viene esposto in ingresso ed
in uscita in ogni punto della nostra “ramificazione”: La
tabella, molto completa ed esaustiva, rappresenta quanto è in
gestione al server. La “dvstation” è la stazione ripetitrice
digitale (anche hotspot) con nominativo radioamatoriale e
suffisso, ovvero lettera che indica la frequenza operativa
(meglio descritto nella colonna “band”). Le colonne “last
heard” e “linked for” ci comunicano l’esatto tempo dell’ultimo
ascolto (quando i dati sono da questa stazione transitati
l’ultima volta) e da quanto il “link” è operativo (tempo di
connessione al reflector). A seguire il protocollo impiegato
per il collegamento (DPlus, DExtra, DCS, sempre riferito al
ripetitore) ed il modulo ove è parcheggiato (A =
internazionale, B = nazionale, C = regionale, etc.). In ultimo
viene riportata l’informazione dell’IP del sistema “client”,
ovvero chi ha connesso il reflector. Si capisce bene che
queste informazioni, se ben lette e capite, ci permettono di
sfruttare a pieno questo sistema. Infatti posso decidere di
spostare il mio ripetitore su di un altro modulo e cambiare il
tipo di protocollo usato per connettere il reflector (es.
XRF077BL per DExtra oppure REF077BL per usare il protocollo
DPlus). Conoscere il sistema significa “padroneggiarlo” e non
“subirlo”.
La figura sopra mostra i “peers”. Immaginiamo una specie di
“maglia” che unisce i vari server reflector. Nella fattispecie
i sistemi/reflector sopra elencati sono tra loro collegati (e
al nostro 077 chiaramente) attraverso una serie di moduli
condivisi. Quindi XLX911 (dal quale sono transitati i dati
l’ultima volta in data …. colonna “last heard” ed è connesso
con noi da … colonna “linked for”) che utilizza il protocollo
proprietario XLX per l’unione agli altri sistemi ha, come da
colonna “module”, le varie stanze “condivise”. Operativamente
questo significa che se ho un ripetitore lo posso collegare a
XLX077 modulo B oppure XLX911 modulo B (o qualsiasi altro
reflector della tabella con il modulo B condiviso) ed il
risultato è lo stesso, ovvero transito nella stanza nazionale
indipendentemente quale XLX stia utilizzando. Questo principio
vale per tutti i moduli che sono condivisi; non importa su
quale reflector sono attivamente collegato, fondamentale è che
il modulo dove sto transitando sia “visto e condiviso” da
tutti i server, e l’uscita della mia trasmissione (e ricezione
degli altri colleghi) sarà la medesima. L’ultima colonna della
tabella mostra (anzi nasconde, è “ad libitum” del sysop) l’IP
del server, ma all’utilizzatore del sistema non serve tale
informazione.
Analizziamo la tabella che visualizza la lista dei reflector
registrati al database mondiale.
Grazie al bottone “reflectorlist” viene mostrata una lista dei
vari server raggiungibili. Quindi se inseriamo nei file di
configurazione del nostro ripetitore o hotspot tali
informazioni non abbiamo limiti nelle connessioni D-Star “in
giro per il mondo”. Come mostrato, se faccio click su XLX068
verrà caricata la dashboard del reflector selezionato e a
seguire i passaggi/transiti dei colleghi radioamatori, i nodi
connessi, etc. L’icona verde ci suggerisce che il reflector è
attualmente operativo, la colonna “country” ci fa capire la
nazione nella quale il reflector opera ed infine la colonna
“comment” può aiutarci ad acquisire ulteriori informazioni; ad
esempio il sito web del club che ospita/gestisce tale
reflector. In definitiva, se comando al mio ripetitore locale
(sperando sia aggiornato e costantemente seguito dal sysop) di
collegarsi al reflector XLX035 (http://xrf035.wa7dre.org/)
verrò quindi connesso negli USA, e precisamente sul server di
“Washington Digital Radio Enthusiasts”. Come tutti i sistemi
digitali occorre che tutti gli hotspot e ponti ripetitori,
nonchè server/reflector, siano ben manutenuti e aggiornati
altrimenti, come si dice, “il giochino si rompe e non
funziona”….
Adesso facciamo un salto veloce sul un altro XLX, il 177,
sempre connesso a tutta la rete, per capire l’uso delle
starnet.
XLX177 è un “server bridge” ovvero NON deve essere utilizzato
per le connessioni standard ma ospita i collegamenti con altri
flussi dati (DMR e YAESU FUSION). Ogni modulo è condiviso,
ragion per cui ciò che passa sul modulo I del 177, per
esempio, lo ascolterò anche sul modulo I di tutti gli altri
reflector in “peer”. Quello che ci interessa notare è che sono
connessi dei nominativi quali IR5UCQ. Questo cosa è ? E’ un
“server starnet”, ovvero permette, tramite l’uso delle starnet
appunto (nominativi registrati sulla rete US-TRUST / IRCDDB,
la rete ufficiale D-Star), la connessione facilitata ai
reflector. In questo caso, sostituendo nel campo UR del nostro
ricetrasmettitore, al posto di CQCQCQ la relativa starnet (es.
STN395 C per passare sul regionale Toscana) e mantenendola per
l’intera durata del QSO per poi dare il comando di chiusura
abbinato (STN395 X), saremo subito collegati al modulo
connesso del reflector senza bisogno di dare comandi al nostro
ponte ripetitore. Si evince la comodità di questo sistema
poichè basterà registrare le varie starnet/memorie sul nostro
ricetrasmettitore e quindi passare da un modulo all’altro del
sistema. A seguire la tabella delle nostre starnet operative.
Presto se ne aggiungeranno altre e, per la natura dinamica
dell’intero sistema, invitiamo a seguire con periodicità gli
sviluppi visitando i nostri siti web e quelli dei colleghi
gestori degli altri XLX. IMPORTANTE: NON UTILIZZARE la Starnet
395 B sui ponti che già sono collegati su tale modulo
altrimenti si generano disturbi.
STARnet Groups
Callsign LogOff
STN395 A
Info
STN395
XLX177 A
Z
Internazionale
UTOT GTOT
15
15
15
15
STN395
XLX177 B
Y
Nazionale
STN395 C
STN395
X
XLX177 C
Toscana
15
15
STN395 D
STN395
W
XLX177 D DMR
TG2225
15
15
STN395 F
STN395
V
XLX177 F C4FM
TG2229192
15
15
STN395 B
XLX177 ha anche collegato il flusso proveniente dal Server
BrandMeister. Lato DMR è possibile impostare il TG (talkgroup)
abbinato al modulo del reflector e, “on demand” (a richiesta,
non automaticamente), uscire lato D-Star. Contemporaneamente
le stazioni connesse a tale modulo (e degli altri XLX con
condivisione operativa) ascolteranno il traffico DMR e
potranno con esso interagire. Per tale motivo si parla di
“bridge” ovvero ponte tra i due sistemi digitali. Esempi
concreti: TG 8515 attiva il flusso verso il modulo B D-Star,
dopo 10 minuti di inattività il passaggio viene
automaticamente richiuso; TG 2229192 attiva il flusso C4FM
verso il modulo F.
Buone prove, per integrazioni e consigli scriveteci. 73 de
Roberto IZ5ILH
Controlliamo il nostro ponte
ripetitore con Telegram
Per coloro che non sanno cosa è Telegram si tratta di un app
di messaggistica, molto simile a WhatsApp. Diversamente da
quest’ultimo, Telegram è un servizio di messaggistica basato
sul cloud con sincronizzazione istantanea. Il risultato ti
permette di accedere ai tuoi messaggi da diversi dispositivi
contemporaneamente, inclusi tablet e computer Nel 2015 è stato
pubblicata API Bot, una interfaccia HTTP che permette di
sviluppare applicazioni e quindi far dialogare uomini e
macchine. I “bot “sono applicazioni di terze parti che vengono
eseguite all’interno di Telegram. Gli utenti possono
interagire con i bot inviando loro messaggi, i comandi e le
richieste in linea. A controllare i bot si utilizzano
richieste HTTPS dirette al nostro API bot. Nel sistema i bot
sono account speciali che non richiedono un numero di telefono
aggiuntivo da configurare. Gli utenti possono interagire con i
bot in due modi: inviare messaggi e comandi al bot con
l’apertura di una chat con loro o aggiungendoli ai gruppi
oppure inviare le richieste direttamente dal campo di
inserimento digitando @nomeutente del bot e una query. I
messaggi, i comandi e le richieste inviate dagli utenti
vengono passati al software in esecuzione sui server. Il
server di Telegram intermediario gestisce tutte la
crittografia e la comunicazione con l’API Telegram. Si può ben
capire quanti possibili applicazioni possono così essere
sviluppate, da sistemi di controllo remoto ad applicazioni
specifiche per interagire con il sistema operativo della
macchina ospite, ad esempio. Da qui mi è nata l’idea di
provare a far qualcosa per il nostro mondo radioamatoriale,
che sia di spunto per tante altre applicazioni. E’ richiesta
una conoscenza base del sistema operativo linux (faccio
riferimento a hotspot e ponti ripetitori basati su Raspberry
Pi) e quanto riportato è ovviamente migliorabile e adattabile
per le proprie esigenze. Ricordo che Telegram è utilizzabile
anche da browser via web o dal proprio PC o Mac (chiaramente è
presente su Android e IOs). E’ possibile scaricare il
programma di installazione di Telegram Desktop Client da
questo indirizzo http://tdesktop.com/win/current per la
versione Windows e http://tdesktop.com/osx per la versione OSx
Procediamo, scaricatevi l’applicazione e createvi un account,
si entra nel mondo del dialogo uomo-macchina.
Il primo passo, creiamo il nostro bot
Apriamo Telegram sul telefono e cerchiamo un utente chiamato
“BotFather”. Come suggerisce il nome, è il padre di tutti i
bot. E’ in realtà una macchina, non è un utente umano, ed
accetta comandi speciali specifici. Digitiamo /newbot. (è
necessaria la barra ‘/’ di fronte) e ci verranno richieste
alcune informazioni. Diamo un nome al nostro bot e poi un
username che necessariamente deve terminare con “bot”. Alla
fine del processo vi verrà dato un codice, qualcosa come
123456789:
ABCDEFGHIJKLMNOPQRSTUVWXYZ.
Questo
token
rappresenta l’account bot e dovrà essere conservato. Conviene
ora utilizzare la piattaforma web sul PC per copiare più
facilmente il token perchè andrà inserito all’interno di
codice nel Raspberry.
Riporto a seguire i comandi che BotFather accetta. Servono
esclusivamente alla gestione del bot che viene creato:
/newbot – create a new bot
/token – generate authorization token
/revoke – revoke bot access token
/setname – change a bot’s name
/setdescription – change bot description
/setabouttext – change bot about info
/setuserpic – change bot profile photo
/setinline – change inline settings
/setinlinegeo – toggle inline location requests
/setinlinefeedback – change inline feedback settings
/setcommands – change bot commands list
/setjoingroups – can your bot be added to groups?
/setprivacy – what messages does your bot see in groups?
/deletebot – delete a bot
/cancel – cancel the current operation
Installare telepot su Raspberry Pi
Per installare telepot, una applicazione scritta in Python
che abilita la comunicazione tra il Raspberry Pi e il Telegram
Bot API, occorre digitare da shell questi comandi:
sudo apt-get install python-pip
sudo pip install telepot
Creiamo la nostra applicazione per la
gestione dei comandi
Occorre creare un file con il comando sudo nano tg.py (potete
dare qualsiasi nome, l’estensione “py” identifica un file che
contiene codice del linguaggio di programmazione Python) ed
inserire il seguente codice:
import commands
import sys
import telepot
import time
def handle(msg):
chat_id = msg[‘chat’][‘id’]
command = msg[‘text’]
print ‘mi e\’ arrivato il comando: %s’ % command
if command == ‘/info’:
info = commands.getoutput(“uname -a”)
bot.sendMessage(chat_id, info)
elif command == ‘/xrf077a’:
out = commands.getoutput(“remotecontrold ir5ay__c link
never xrf077_a”)
bot.sendMessage(chat_id, “inviata connessione XRF077 A”)
elif command == ‘/reboot’:
bot.sendMessage(chat_id, “attendi, riavvio in corso…”)
out = commands.getoutput(“sudo shutdown -r now”)
elif command[0:5] == ‘/temp’:
temp
=
commands.getoutput(“cat
/sys/class/thermal/thermal_zone0/temp”)
temperatura = int(temp) / 1000
temp = str(temperatura)
bot.sendMessage(chat_id, temp)
out = commands.getoutput(“texttransmit ir5ay__c -text
‘%s gradi'” % temp)
elif command[0:5] == ‘/link’:
link = commands.getoutput(“cat /var/log/Links.log”)
bot.sendMessage(chat_id, link)
elif command[0:4] == ‘/who’:
who
=
commands.getoutput(“tail
/var/log/Headers.log”)
bot.sendMessage(chat_id, who)
-n
1
bot = telepot.Bot(‘INSERIRE QUI IL TOKEN DEL VOSTRO BOT’)
bot.message_loop(handle)
print ‘sono in ascolto….’
while 1:
time.sleep(10)
Importante l’identazione delle linee dei comandi, in Python fa
parte della sintassi, diversamente verranno generati degli
errori. Inoltre il file deve avere i permessi di esecuzione.
Il codice riporta, come esempio, la creazione di alcuni
comandi di facile interpretazione: “/reboot” che effettua un
riavvio del sistema, oppure “/temp” che invia in radio (RF),
attraverso il programma di Jonathan texttransmit, il valore
della temperatura della CPU. Potete creare nuovi comandi che
agiscono sul sistema operativo e/o sul software
radioamatoriale, utilizzate le stesse modalità di quelli
presenti facendo le opportune modifiche. Inoltre occorre
inserire ove indicato il TOKEN che è stato rilasciato durante
la creazione del bot, diverso per ogni bot, e il nominativo
del vostro sistema. Questo processo deve rimanere in ascolto
se vogliamo che i comandi dati dal nostro smartphone siano
recepiti sul Raspberry Pi, quindi digitiamo sudo python
/home/pi/tg.py per eseguirlo.
I comandi dallo smartphone o da un PC
I comandi creati possono essere eseguiti da uno qualsiasi dei
nostri dispositivi connessi alla piattaforma Telegram. La
prima volta occorre cercare il nostro bot, sulla barra di
ricerca, indicando il nome dato (@…..) e per avviarlo, dopo
averlo selezionato,
eseguire il comando /start. Come da
esempio sotto riportato, eseguendo il comando /info il sistema
(Raspberry) mi risponde con la versione del sistema operativo.
Questa informazione la leggo direttamente sullo smartphone e
su tutti i dispositivi collegati. In pratica il comando dal
mio spartphone è passato sui server di Telegram, da questi al
Raspberry che ha processato l’istruzione, e in restituzione il
valore richiesto. Un’altra prova che ho fatto è stata quella
di ricevere una foto. Collegando una telecamerina al sistema e
creando apposito comando mi è stata spedita dal Raspberry
l’immagine catturata. Le implementazioni sono molteplici,
pensiamo a sensori collegati al Raspberry che ci danno le
temperature della postazione radio, centraline meteo, etc.
Raccomando uno studio del linguaggio Python e ovviamente una
conoscenza dei comandi del sistema operativo Linux.
Aggiornare in automatico i
file
DExtra,
DPlus
e
DCS_Hosts.txt dal database
XLX
Gli script (per Linux) sotto riportati, prelevati dalla rete,
permettono l’aggiornamento in automatico dei file
DExtra_Hosts.txt, DPlus e DCS dal database che gestisce
l’elenco dei reflector XLX che si autoregistrano. Il contenuto
dei file NON viene cancellato ma sono aggiunti i record
mancanti. Per un aggiornamento completo ripulire a mano i file
affinchè il processo, trovandoli vuoti, provveda a
ripopolarli. Di seguito i comandi:
copiare i file interessati nella cartella temporanea del
nostro hotspot/ripetitore prelevandoli dalla cartella
/usr/local/etc
$ sudo -s
# cd /tmp
prestare attenzione al “.” al termine del comando
# cp /usr/local/etc/DExtra_Hosts.txt .
# cp /usr/local/etc/DPlus_Hosts.txt .
# cp /usr/local/etc/DCS_Hosts.txt .
nel caso volessimo avere i file vuoti possiamo evitare di
ricopiare gli originali, bensì creare i nuovi con il comando
“touch“
Creare il primo script
# nano main.sh
e copiarvici il seguente contenuto:
#!/bin/bash
cd /tmp
wget -O /tmp/xlx_Hosts.txt http://xlxapi.rlx.lu/api.php?do=GetReflectorHostname # get self registered XLX hosts.
XLXFILE=/tmp/xlx_Hosts.txt
echo “Merging XLX DPlus reflectors with master list…”
export HOSTFILE=/tmp/DPlus_Hosts.txt
export REFTYPE=”REF”
cat $XLXFILE | xargs -r -l1 /usr/local/bin/checkref
echo “Merging XLX DExtra reflectors with master list…”
export HOSTFILE=/tmp/DExtra_Hosts.txt
export REFTYPE=”XRF”
cat $XLXFILE | xargs -r -l1 /usr/local/bin/checkref
echo “Merging XLX DCS reflectors with master list…”
export HOSTFILE=/tmp/DCS_Hosts.txt
export REFTYPE=”DCS”
cat $XLXFILE | xargs -r -l1 /usr/local/bin/checkref
rendere eseguibile il file creato
# chmod 755 main.sh
creare il secondo script con il comando
# nano /usr/local/bin/checkref
e copiarvici il contenuto:
#!/bin/bash
REF=”$1″
TEST=`echo $REF | grep ^#`
if ! [ “$TEST” = “” ]; then
exit 0
fi
TEST=`echo $REF | grep $REFTYPE`
#echo -n “$REF, $TEST, “
if [ “$TEST” = “” ]; then
CHECK=””
exit 0
else
REF=”^$REF”
CHECK=`cat $HOSTFILE | grep $REF`
fi
if ! [ “$CHECK” = “” ]; then
echo “Skipping duplicate entry $1”
# echo -n “$CHECK, “
exit 0
fi
echo “$@”
echo -e “$1\t$2” >> $HOSTFILE
rendere quindi eseguibile questo secondo script
# chmod 755 /usr/local/bin/checkref
ed eseguire il processo avviando il primo script
# sh /tmp/main.sh
si avrà un output simile a questo:
–2016-04-16
20:28:32–
http://xlxapi.rlx.lu/api.php?do=GetReflectorHostname
Resolving xlxapi.rlx.lu (xlxapi.rlx.lu)… 193.168.82.26
Connecting to xlxapi.rlx.lu (xlxapi.rlx.lu)|193.168.82.26|:80…
connected.
HTTP request sent, awaiting response… 200 OK
Length: 4516 (4.4K) [text/plain]
Saving to: `/tmp/xlx_Hosts.txt’
100%[=========================================================
==============================================================
==========>] 4,516 –.-K/s in 0s
2016-04-16 20:28:32 (32.1 MB/s) – `/tmp/xlx_Hosts.txt’ saved
[4516/4516]
Merging XLX DPlus reflectors with master list…
che indentifica il corretto procedere nell’aggiornamento dei
dati, attendere quindi il completamento della lavorazione.
Alla fine i file risulteranno aggiornati e potremo ricopiarli
nella loro posizione corretta dando i seguenti comandi (prima
procedo con una copia del file originale rinominandolo .OLD):
#
mv
/usr/local/etc/DExtra:Hosts.txt
/usr/local/etc/DExtra_Hosts.OLD
# cp /tmp/DExtra_Hosts.txt /usr/local/etc/DExtra_Hosts.txt
#
mv
/usr/local/etc/DPlusHosts.txt
/usr/local/etc/DPlus_Hosts.OLD
# cp /tmp/DPlus_Hosts.txt /usr/local/etc/DPlus_Hosts.txt
# mv /usr/local/etc/DCS:Hosts.txt /usr/local/etc/DCS_Hosts.OLD
# cp /tmp/DCS_Hosts.txt /usr/local/etc/DCS_Hosts.txt
Si può creare facilmente un automatismo, magari utilizzando
CRON per programmare l’aggiornamento una volta alla settimana.
Guida
rapida
l’installazione
Reflector XLX
di
per
un
Quanto segue è una rapida spiegazione dei passi necessari
all’installazione di un reflector XLX, materiale in parte
liberamente tratto dal documento in PDF disponibile sul gruppo
Yahoo degli sviluppatori. Consiglio di seguire attivamente
tale gruppo per conoscere gli aggiornamenti del software e
ulteriori spiegazioni al funzionamento e installazione. Alcune
doverose premesse per evitare problematiche e una non perfetta
operatività:
il software “gira” su di un server Linux, queste
informazioni si riferiscono alla distribuzione Debian
versione 7 oppure 8
meglio dedicare un server al reflector, evitare quindi
operino altri programmi che possono pretendere risorse
non serve una macchina potente, va bene inizialmente
anche un VPS o server in Cloud con 1 GB di memoria Ram,
spazio su disco minimo
occorre un indirizzo IP pubblico STATICO e un nome DNS
da assegnargli, utile nel caso si sostituisca o si
sposti il server su altro provider
il server deve essere accessibile su internet, evitiamo
NAT se possibile, occorrono siano aperte delle porte su
eventuale firewall presente
il server deve avere “banda” garantita, le connessioni
dei ripetitori e hotspot occupano spazio nel
trasferimento della voce digitalizzata e non devono
subire interruzioni
Per fare delle valutazioni operative, sul nostro sito è
presente un link al sistema di monitor presente sul reflector
XLX077. Raccomando l’uso di password molto robuste e di una
gestione oculata nell’apertura delle porte ai vari servizi
(es. inutile installare un server FTP se non vi è la reale
necessità…). Infine dobbiamo domandarci se è utile la
creazione di un nuovo reflector e quindi ci saranno dei
ripetitori e hotspot che si collegheranno ad esso, oppure
conviene sfruttare quanto già c’è e collegarci, ad esempio, a
XLX077, che funziona proprio bene … :-)) Chiaramente provare
ad installare questi sistemi è molto utile per accrescere le
proprie conoscenze, senza ombra di dubbio !! Il software XLX è
stato testato su sistemi a 32 e 64bit e qualcuno lo ha anche
installato su Raspberry Pi, e funziona anche se, per motivi di
performance, magari non è consigliato su una gestione di una
grossa mole di traffico, viste le limitate caratteristiche.
Nel procedere è richiesta una sufficiente conoscenza del
sistema operativo linux e i comandi della shell, oltre a
comprendere e gestire i concetti base del “networking”
(protocolli, porte, nat, etc.)
Queste invece le porte (e relativo protocollo) necessarie alla
gestione delle connessioni e manutenzione, devono essere
aperte sul firewall (o “girate” dal router verso il server se
dietro NAT):
TCP porta 80 (http) ==> server web per la
visualizzazione della dashboard
TCP porta 8080 (RepNet) ==> visualizzazione
dell’interfaccia/dashboard in 3D (la documentazione per
questa installazione è separata)
UDP porta 10001 (json interface XLX Core) ==> gestione
interna del software, interrogazione dati
UDP porta 10002 (XLX interlink) ==> gestione interna del
software, riservata a interconnessione tra XLX
TCP porta 22 (ssh) ==> necessaria per collegarsi al
server tramite terminale (es. PUTTY) per le operazioni
di manutenzione/aggiornamento
UDP porta 30001 (DExtra protocol) ==> connessione al
server reflector da ponti ripetitori/hotspot/XRF con
protocollo DEXTRA
UDP porta 20001 (DPlus protocol) ==> connessione al
server reflector da ponti ripetitori/hotspot con
protocollo DPLUS
UDP porta 30051 (DCS protocol) ==> connessione al server
reflector da ponti ripetitori/hotspot con protocollo DCS
Dopo aver installato una versione stabile (e pulita, senza
altro software) del sistema operativo sul server, procedere
con un aggiornamento dell’intero sistema digitando i seguenti
comandi:
# apt-get update
# apt-get upgrade
quindi installare il software “git” per lo scarico in
automatico di quanto ci occorre relativamente al software del
reflector,
# apt-get install git git-core
e installiamo il server web apache ed il linguaggio PHP (per
la visualizzazione della dashboard).
# apt-get install apache2 php5
Rimane da installare il compilatore C++ per “creare” dai
sorgenti (il codice) che scaricheremo il programma in formato
eseguibile:
# apt-get install build-essential
(il seguente passaggio può essere saltato se si è scelto il
sistema operativo Debian 8.x o superiore)(vedi integrazione in
fondo al testo)
# apt-get install g++-4.7
I prossimi comandi eseguono il download del codice dal sito
degli sviluppatori e lo “compilano” creando
l’eseguibile, il cuore del nostro reflector:
quindi
# git clone https://github.com/LX3JL/xlxd.git
# cd xlxd/src/
# make
# make clean
# make install
Al termine di questa procedura, se non vi sono stati errori,
verrà creata in automatico una directory /xlxd nel ramo
principale (si chiama root) del sistema operativo e
all”interno di essa copiati alcuni file, fra cui l’eseguibile.
Riporto l’estratto delle operazioni che questa procedura
effettua per meglio capire quali sono i file che saranno
copiati (non digitare quanto segue):
install:
mkdir -p /xlxd
cp ./xlxd /xlxd/
cp -i ../config/xlxd.blacklist /xlxd/
cp -i ../config/xlxd.whitelist /xlxd/
cp -i ../config/xlxd.interlink /xlxd/
La directory /xlxd è quella a cui dovremo fare riferimento per
le configurazioni delle connessioni tra XLX (editare il file
xlxd.interlink, all’interno di esso è spiegata la sintassi da
utilizzare, inoltre presso il gruppo Yahoo degli sviluppatori
vi è apposita documentazione) e per limitare eventuali accessi
(i file xlxd.blacklist e xlxd.whitelist). Questa directory
contiene anche il file xlxd che è il programma di reflector.
Il passo successivo riguarda il file di configurazione
principale del reflector (anche lui si chiama xlxd ma è un
file di testo che contiene dei comandi) che va manualmente
copiato in una opportuna posizione (cartella /etc/init.d) del
sistema operativo per essere letto (ed eseguito) ad ogni avvio
del server. Digitare quanto segue:
# cp ~/xlxd/scripts/xlxd /etc/init.d/xlxd
Occorre quindi eseguire gli opportuni adattamenti editandolo
(viene utilizzato il comando “nano” come editor di testo, va
bene qualsiasi altro editor) e inserendo i nostri parametri:
# nano /etc/init.d/xlxd
Si possono lasciare “di default” tutti i parametri,
diversamente ci addentreremmo in una personalizzazione troppo
approfondita; occorre invece modificare la proprietà
della variabile “ARGUMENTS” con il nome del proprio reflector
(per esempio XLX077) e l’indirizzo IP statico (nel nostro caso
5.249.151.111) assegnato al server (se è dietro un router
occorre inserire l’indirizzo IP privato statico assegnato
all’interno della lan). Indirizzo sul quale il software del
reflector farà ascolto:
ARGUMENTS=”XLX077 5.249.151.111″
Dopo aver salvato il file di configurazione digitare il
seguente comando che serve ad automatizzare l’avvio del
reflector ad ogni accensione del server:
# update-rc.d xlxd defaults
Manualmente si può procedere anche così:
# service xlxd start
# service xlxd stop
Gli ultimi passaggi riguardano la dashboard, il cruscotto
visibile via web contenente le informazioni sullo stato delle
connessioni al reflector. Iniziamo copiando i vari file che
compongono la dashboard nella directory gestita dal server web
Apache già installato. generalmente sotto /var/www :
# cp -r ~/xlxd/dashboard /var/www/db
Troviamo quindi le pagine e il file di configurazione della
dashboard nella dir /var/www/db e relative sottodirectory.
Anche in questo caso occorre eseguire una personalizzazione
editando manualmente il file:
# nano /var/www/db/pgs/config.inc.php
Questo file è molto ben commentato, e molto facilmente si
possono inserire le informazioni relative alla propria
installazione, quali la mail dell’amministratore del sistema,
il tempo di refresh della pagina, etc. Prestare attenzione
all’ultima sezione che riguarda l’inserimento del reflector
nella lista automatica dei reflector mondiali inserendo l’ URL
completo per visualizzare la dashboard, oltre ad un commento.
Dalla versione 2.2.2 della dashboard viene creato un file
sotto /tmp chiamato callinghome.php Consiglio di fare una
copia di questo file perchè serve all’autenticazione al server
che mantiene la lista dei reflector, e nel caso venisse
cancellato occorre ripristinare l’originale, pena la non
registrazione. Seguire le varie discussioni sul gruppo Yahoo
nel caso questa operatività venisse cambiata con l’uscita di
aggiornamenti.
Rimane, in ultimo, di assegnare i permessi di lettura alla
dashboard al file che contiene il log del reflector:
# chmod +r /var/log/messages
e un riavvio del server per verificare che tutto sia
perfettamente funzionante.
# reboot
Per vedere in tempo reale cosa sta accadendo al reflector è
possibile dare questo comando che legge il file di log:
# tail -f
/var/log/messages
e, per assicurarsi che il reflector stia correttamente
“ascoltando” sulle porte sopra indicate, il seguente comando:
# netstat -lnp
che produrrà un output simile a questo (il processo xlxd è in
ascolto su IP/porta indicata con il protocollo UDP):
udp
udp
udp
udp
udp
0
0
0
0
0
0
0
0
0
0
5.249.151.111:20001
5.249.151.111:10001
5.249.151.111:10002
5.249.151.111:30001
5.249.151.111:30051
0.0.0.0:*
0.0.0.0:*
0.0.0.0:*
0.0.0.0:*
0.0.0.0:*
2959/xlxd
2959/xlxd
2959/xlxd
2959/xlxd
2959/xlxd
Nel caso non fosse installato netstat, si può provvedere con:
# apt-get install netstat
E’ utile ricordare che le cartelle “importanti” sono /xlxd e
/var/www/db quindi la cartella originaria creata durante il
processo di download dei sorgenti (es. /root/xlxd) può essere
rimossa affinchè successivamente sia possibile scaricare nuovi
aggiornamenti. Per qualsiasi suggerimento e integrazione
mandatemi una mail, provvederò ad aggiornare questo articolo.
Buone prove, David Bencini [ [email protected] ]
Integrazione al testo del 03/aprile/2016
I comandi sotto riportati valgono per distribuzioni Wheezy
basati su Debian inferiori a 8.0
dopo il comando:
# apt-get install build-essential
occorre digitare in successione:
# apt-get install g++-4.7
#
update-alternatives
–install
/usr/bin/gcc
gcc
/usr/bin/gcc-4.6 60 –slave /usr/bin/g++ g++ /usr/bin/g++-4.6
#
update-alternatives
–install
/usr/bin/gcc
gcc
/usr/bin/gcc-4.7 40 –slave /usr/bin/g++ g++ /usr/bin/g++-4.7
# update-alternatives –config gcc
all’ultimo comando chiedere di scegliere delle opzioni e si
risponderà con la n. 2 (due).
Rete QuadNet2 e traffico su
XLX077 A da ponti CISAR
Una premessa: vorrei ricordare ai numerosi colleghi OM che
utilizzano XLX077 (ex XRF077 con DNS: xrf077.duckdns.org) e ai
vari gestori di hotspot e ponti fatti “home made” che esiste
una rete alternativa ad ircDDB la quale, a differenza di
quest’ultima, non richiede alcuna registrazione né che il
vostro sistema abbia un nominativo ufficiale. Questa rete si
chiama QuadNet2. Per avere un’idea di cosa sia e come funzioni
vi rimando a questo link http://openquad.net/ dove troverete
in lingua inglese tutte le informazioni necessarie ed una
dashboard completa, in tempo reale, con gli ultimi nominativi
ascoltati. Per “loggarsi” su tale rete basta abilitare il
campo ircDDB ed inserire il nominativo del vostro
ponte/hotspot lasciando il campo password vuoto e selezionando
il relativo server come visibile nell’immagine che segue e che
fa riferimento al software di Jonathan ircDDBGateway:
Ho fatto riferimento alla rete QuadNet2 perché i ponti Cisar,
ormai da tempo, sono tutti (oppure quasi tutti) connessi a
tale rete e quindi tra di loro è possibile fare “callsign
routing” ovvero si può sfruttare il protocollo G2 della rete
D-Star per collegamenti in routing tra due stazioni o tra una
stazione e un ponte specifico. Questo fatto permette inoltre
di poter creare ed utilizzare sulla rete QuadNet2 delle
starnet che puntano ad xreflector, DCS o ai nuovi sistemi
XLXreflector. Una starnet non è altro che una stanza dentro la
quale arriva e parte il traffico da e verso l’XRF/XLX al quale
fa riferimento. I vari utenti che vi si affacciano ricevono e
trasmettono sia tra di loro che attraverso il reflector al
quale punta la starnet. Molti conosceranno la starnet chiamata
STN058 A che permette di fare traffico sul modulo A dell’
XLX077 da quei ponti che pur facendo capo alla rete ircDDB
sono bloccati oppure normalmente non connessi ad alcun
reflector. Sulla rete QuadNet2 esiste invece la starnet
chiamata QNET77 A che permette di fare traffico sul modulo A
dell’XLX077 da tutti quei sistemi che fanno capo a tale
rete. Quindi, all’occorrenza, potremmo utilizzare un ponte
della struttura Cisar normalmente connesso all’ XRF003 A (ora
XLX003) per fare traffico sul nostro XLX077 A mediante l’uso
della starnet appositamente predisposta allo scopo. Basterà
inserire nel campo UR del nostro apparato radio D-Star il
comando QNET77 A e mantenercelo fino al termine del nostro
QSO. Al primo colpo di portante la starnet risponderà “Logged
in”, mentre a conclusione del QSO abbiamo due possibilità, la
prima chiudere la starnet con il comando QNET77 T oppure
attendere 30 minuti e si chiuderà da sola. In entrambi i casi
sul display della radio troveremo scritto “Logged off”. A dire
la verità sulla rete QuadNet2 non esiste solo la starnet
QNET77 A ma ce ne sono altre tre, una punta al modulo D
dell’XLX077, una al modulo C dello stesso XLX077 e una al
modulo A dell’XRF003. Di seguito sono elencati i comandi per
apertura e chiusura e a cosa fanno capo, nonché il tempo
limite di funzionamento in assenza di traffico:
Da questo link è visibile la dashboard della mia DvMega con le
starnet attivate: http://iz5cmc.no-ip.org/
Per la realizzazione di starnet su rete QuadNet2 rimando a
questo articolo http://dstar.grupporadiofirenze.net/?p=1091
già pubblicato sul sito D-Star del Gruppo Radio Firenze.
73, Maurizio IZ5CMC
XRF077
diventa
XLX077
Reflector multiprotocollo
Il nostro reflector D-Star XRF077 è diventato XLX077 con la
sostituzione del vecchio software di Scott con il nuovo
software multiprotocollo. Questo vuol dire che ora il
reflector accetta in ingresso connessioni con protocollo
DExtra, DPlus e DCS. Le giunzioni tra reflector possono essere
stabilite, dopo opportune configurazioni da entrambe le parti,
con il nuovo protocollo XLX. Il cambiamento è stato apportato
poichè il vecchio software non era più manutenuto e soggetto a
miglioramenti, mentre il nuovo XLX ha un gruppo attivo di
sviluppatori,
potete
fare
il
“join”
al
gruppo
all’indirizzo https://groups.yahoo.com/neo/groups/xlxd-star/in
fo
Per le configurazioni relative alle connessioni dei ponti
ripetitori e hotspot a XLX077 occorre inserire negli opportuni
file i seguenti record:
CONNESSIONE DEXTRA: DExtra_hosts.txt ==> inserire XRF077
xrf077.duckdns.org
CONNESSIONE
DPLUS:
DPlus_hosts.txt
==>
inserire
REF077
xrf077.duckdns.org
CONNESSIONE DCS: DCS_hosts.txt
xrf077.duckdns.org
==>
inserire
DCS077
Come potete vedere il record finale DNS rimane sempre
xrf077.duckdns.org, cambia solo l’approccio al protocollo. Per
le connessioni dei vecchi XRF al nuovo XLX077 occorre dire che
quest’ultimo accetta solo connessioni in ingresso nella
modalità DEXTRA quindi l’ XRF che vuole lanciare la
connessione deve eseguire il comando da console “lrf AXRF077A”
per connetterlo sul modulo A e inserisca nel file di
configurazione xrfs.txt il record XRF077 xrf077.duckdns.org
La
Dashboard
è
visionabile
all’indirizzo: http://xrf077.duckdns.org/db/dashboard/index.ph
p
Un nuovo software per creare
un reflector D-Star
Da pochi giorni è comparso sul panorama D-Star un nuovo
software per creare un reflector. E’ molto interessante, con
un codice sorgente programmato in C++ ed estremamente
orientato agli oggetti e pulito, quindi facilmente espandibile
a nuove implementazioni per un programmatore. E, cosa molto
importante, è open source. Il software gira su server linux.
Di seguito le caratteristiche più importanti ed i link di
riferimento. Al momento della stesura di questo testo il
software (reflector XLX) non permette il collegamento tra XRF,
ovvero X-Reflector con protocollo DExtra, ma l’autore mi ha
assicurato che è prevista quanto prima l’aggiunta di questa
funzione.
Descrizione:
Il sistema è composto da un software scritto in C++ e
una Dashboard in PHP;
XLX è il primo ed il solo reflector multiprotocollo e
supporta tutti gli standard D-Star (DCS, DExtra, Dplus);
Multiprocesso;
di facile installazione su server linux;
opera come “demone” in background senza necessità di
database;
non necessita di ID-DMR per l’accesso;
ha una dashboard completamente in PHP.
Un esempio della dashboard:
E’ disponibile, in versione
3D: http://xlx.epf.lu:8080
beta,
una
dashboard
in
Per maggiori informazioni è possibile contattare l’autore
all’indirizzo: [email protected]
o direttamente (presente anche la procedura di installazione
nella
sezione
File)
sul
gruppo
Yahoo: https://groups.yahoo.com/neo/groups/xlxd-star/info
Un
backup
periodico
e
completo per il Raspberry Pi
Avete il vostro Raspino, con l'”immagine” del sistema
operativo diligentemente scaricata dal sito originale e
clonata sulla microSD.
Avete avviato, configurato, aggiunto programmi, funzioni, app…
… e adesso vivete con l’angoscia, col pensiero che non smette
di assillarvi. “Poni il caso che la schedina di memoria si
guasti: devo rifare tutto daccapo!”
Non è un rischio tanto remoto, vista la possibilità, per noi
smanettoni, di qualche spegnimento improvviso o necessario e
“senza passare dal via”… oltre al fatto che la schedina di
memoria (a prescindere dalla garanzia del produttore…) è sì “a
stato solido” come i nuovi dischi SSD, ma senza le loro
caratteristiche di ridondanza e di correzione “trasparente”
degli eventuali bit danneggiati.
Ma qui c’è adesso la giusta camomilla per farvi dormire sonni
tranquilli! E gli ingredienti per prepararla sono semplici.
1) Prendete una chiavetta USB magari di dimensioni non grandi
(sennò raddoppia l’ingombro del sistema!) e di capacità almeno
doppia rispetto ai GB della schedina SD utilizzata.
2) Loggatevi e datevi i superpoteri di root (sudo -s)
3) Inserire la chiavetta USB in una delle prese USB libere del
Raspberry (sempre che ve ne sia rimasta libera almeno una).
La memoria inserita dovrebbe essere riconosciuta come
/dev/sda1 (verificare col comando “df”, nel caso prendere nota
del valore se è diverso, da sostituire poi nei comandi
successivi).
4) Provate ad eseguire il seguente comando. Lo scopo è di
clonare, nella memoria USB inserita, l’intero filesystem
utilizzato dal Raspberry in un file immagine (.img), in
pratica l’inverso di quanto si era fatto per la creazione del
“disco a stato solido” su SD contenente sistema operativo e
app originali:
mount /dev/sda1 /media/pi
dd bs=4K if=/dev/mmcblk0 of=/media/pi/<nome del file>.img
Occorre aspettare diversi minuti (anche una mezz’ora o più, se
il filesystem è su microSD da 16 o 32 GB e/o la velocità di
scrittura della chiavetta non è elevata). Al ternine ricompare
il prompt di root “#”.
Per verificare l’avvenuta operazione dare il comando “ls -l”
che dovrebbe mostrare (ad esempio nel mio caso) una schermata
così:
-rw-r–r– 1 root root 7948206080 gen 11 07:41 RaspiFKA.img
cioé la clonazione della mia memoria SD da 8 GB come
“immagine” aggiornata alla data della sua creazione e che
potrà essere poi ri-clonata su di una nuova schedina in caso
di danneggiamento del filesystem.
Automatizziamo la procedura.
Sempre come root creiamo un “crontab” ovvero una procedura che
avvia l’operazione periodicamente (un altro utilizzo del
crontab è spiegato nell’articolo, riguardante il riavvio
automatico
del
sistema,
http://dstar.grupporadiofirenze.net/?p=337)
crontab -e
Aggiungere alla fine questa riga che indica al sistema l’avvio
della clonazione:
mm hh * * * /bin/umount /dev/sda1; /bin/mount /dev/sda1
/media/pi; /bin/dd bs=4K if=/dev/mmcblk0 of=/media/pi/(nome
file).img; /bin/umount /dev/sda1
sostituendo mm e hh il minuto e l’ora di avvio della
procedura.
Ovviamente tutto in una riga: è infatti possibile dare nella
shell di Linux (e quindi anche qui) più comandi di seguito
separati dal “punto e virgola”.
Cosa abbiamo chiesto al sistema? Che tutti i giorni al minuto
mm dell’ora hh venga eseguita in sequenza:
1) Smontaggio della chiavetta, qualora fosse già montata,
magari in altre locazioni;
2) Mount della stessa nella locazione /media/pi (il default
nel Raspberry);
3) Clonazione del filesystem con il comando “dd” visto prima;
4) Smontaggio della stessa al termine dell’operazione.
Il tutto eseguito in background quindi senza attese o blocchi
di sistema. Ovviamente si sceglierà un orario in cui si sa che
il Raspino è acceso e operativo. E tenere ovviamente sempre
inserita la chiavetta USB nello slot del Raspberry.
Facile, no?
73 de IK5FKA Roberto [ [email protected] ]
Configurazione
Dstar-Repeater
Annuncio
Il comando Annuncio è disabilitato, basta abilitare
selezionare il tempo; di default è settato a 8 minuti,.
e
Per registrare il messaggio di benvenuto o qualsiasi altro
annuncio la procedura è questa:
Per registrare impostare sulla tua radio RPT1:RECORD A e
RPT2:RECORD G sul campo UR:CQCQCQ
a questo punto premete il ptt e cominciate a registrare il
tempo massimo non l’ho ancora verificato ma credo oltre un
minuto poi vedremo.
Per cancellare
impostare sulla radio RPT1:DELETE A e
RPT2:DELETE G sul campo UR:CQCQCQ
e premere il ptt così facendo l’annuncio viene cancellato.
NOTA BENE:
Questi comandi rispettano lo standard “ripetitore”, per
funzionare la vostra frequenza memorizzata dovà avere Shift
impostato +/-e offset a 0
Quando date questi comandi il vostro Hotspot o ripetitore non
darà nessuna risposta, vedrete spengere o riavviare il vostro
raspberry.
Consiglio l’ultima versione di Dstar-Repeater come da foto, le
altre davano problemi su raspberry
Buone prove Roberto iz5ilh
Nuovo software di gestione
per la DV4mini USB
Perché un altro software di controllo della chiavina usb
DV4Mini? La questione è emersa perchè in origine non vi era
alcun supporto nativo al server BrandMeister per la
DV4Mini. Ero alla ricerca di una soluzione affinchè potesse
essere confortevole viaggiare in due reti DMR. Mi sono messo
così a sviluppare il mio software di controllo DV4MF2 che
permette agevolmente di gestire le due reti DMR, BrandMeister
e DMRPlus.
Questo software ha inoltre una modalità operativa “compatta”,
quindi agevole sui dispositivi mobili.
Le caratteristiche del pannello di controllo DV4MF2 nella
panoramica:
interfaccia utente ordinata e chiara supporta la
configurazione rapida e senza problemi di funzionamento
piena integrazione con tutte le modalità operative
scelta di 2 interfacce (versione standard e compatta)
con la commutazione al volo
elementi di visualizzazione configurabili per
alleggerire la CPU, migliora le prestazioni e la durata
della batteria, come ad esempio gli hotspot mobili
opzione di selezione per disattivare la query QRZ.com,
riduce il volume dei dati e migliora la qualità della
voce quando si utilizzano gli hotspot con connettività
GSM / UMTS
inoltre, molti altri cambiamenti minori sono stati
attuati per rendere il funzionamento di un hotspot con
la DV4mini più confortevole possibile.
Il software DV4MF2 e quanto necessario è stato testato su
Windows (XP / Vista / 7/8 / 8.x / 10) e Linux (Ubuntu 12.04 /
14.04 Xbuntu / Raspbian). Per avviare il programma è
fondamentale sia installato il software originale della
DV4mini
e
deve
essere
copiato
nella
stessa
directory. L’utilizzo è semplice, è possibile l’alternanza con
il software originale dv4mini.exe perché entrambi i programmi
memorizzano le impostazioni separatamente in cartelle dei
profili utente. Il dv_serial (.exe) viene utilizzato da
entrambi i programmi per accedere alla configurazione della
DV4mini. Dopo aver fatto le prime configurazioni necessarie,
chiuderlo e riavviarlo.
nota bene (7 gennaio 2015) : per leggere la lista degli XRF in
modalità D-Star occorre copiare il file xrf.ip nella stessa
directory e rinominarlo DV4MF2_xref.ip
Per operare sotto Linux il pacchetto ha bisogno di “monocomplete”, il software è stato testato su Ubuntu 12.04 su un
PC, Xubuntu 14.04 su un thin client FUTRO S400 e il Raspberry
Pi.
Per l’installazione seguire questi passaggi:
aprire una finestra di terminale (Alt-T)
eseguire sudo apt-get install mono-complete
inserire la dv4 e verificare con ls /dev/tty* se questa
viene rilevata
eseguire sudo gpasswd –add username dialout
creare una cartella dv4mini o DV4MF2 in /home/nomeutente
copiare dentro dv4mini.exe e dvserial.bin scaricati per
Linux x86 (prestare attenzione a Linux a 32 bit, un
dvserial a 32 bit per la versione ARM Raspberry !!!)
eseguire chmod 755 *
eseguire chmod + x dv_serial.bin
ora copiare solo il file DV4MF2.exe dentro la stessa
directory
per eseguire i programmi: mono dv4mini.exe o
mono
DV4MF2.exe dalla finestra del terminale o con un doppio
clic dal file manager.
Meinhard F. Günther, DL2MF
Link al sito ove poter scaricare il software
Link al wiki ufficiale della DV4mini
Alcuni aggiornamenti sulla
DV4mini per collegare il
talkgroup 222
Funzionando perfettamente come dongle/hotspot privato in DStar la chiavina USB DV4mini permette anche la connessione in
DMR. Una interessante “modifica” software è quella di inserire
all’interno del file hosts.txt (per Windows, si trova
sotto C:\Windows\System32\Drivers\etc editabile con il
Notepad, per Linux sotto /etc editare il file hosts usando, ad
esempio, l’editor nano o vi) il seguente dns:
185.79.71.94
ham-dmr.de
Lanciando il Control Panel (software di gestione della
chiavina USB) ed andando sotto “expert settings” si può così
scegliere come “server dmr master” il MASTER-2221 (senza la
modifica in hosts.txt non appare) e connettendo il gruppo 4250
si entra nella rete italiana (al momento solo il TG 222 ovvero
il “canale/gruppo” nazionale). E’ possibile monitorare i
passaggi visionando questo link al control center DMR TAA.
Altra interessante novità sempre in ambito DMR (permettetemi
questo “off topic”) e DV4mini è quella di poter utilizzare gli
apparati DPMR di debole potenza, quelli per i classici “usi
civili”. In questo caso occorre aggiornare il firmware della
schedina (procedura semplicissima, dopo il download dal sito
basta premere un bottone nel Control Panel e riavviare alla
fine del caricamento il software di gestione) ed utilizzare
l’ultima versione del Control Panel (attualmente in test la
1.64). Verrà visualizzata una opzione relativa alla
connessione su rete DPMR (in simplex) con relativi gruppi.
Allego la traduzione (in inglese) fatta da Adrian, dove sono
indicati gli aspetti tecnici.
dv4mini_V1.64
Infine, per i colleghi che utilizzano una radio tipo la mia DM
380 della Thytera, segnalo l’importanza di agire sulla voce
(sotto “expert settings”) DMR-QRG Correction; ho dovuto
impostare un offset di -200 per trasmettere senza
interruzioni. Importante fare delle prove con un
corrispondente, ogni dispositivo ha una propria taratura.
73, David IK5XMK
Misuriamo la velocità della
connessione
internet
dal
nostro raspberry
speedtest.net è un ottimo sito che permette di misurare il la
velocità della connessione internet in upload e download. E
‘utile per controllare le prestazioni, sia per ricerca guasti
che per vedere se il servizio promesso dal fornitore è
effettivamente attivo. Matt Martz ha creato un progetto Python
chiamato speedtest-cli che permette di fare una misura di base
upload / download utilizzando l’infrastruttura di SpeedNet.
Funziona benissimo sul Raspberry Pi ed è veramente facile da
provare utilizzando la riga di comando, così possiamo
monitorare il nostro ponte ripetitore D-Star anche da remoto e
capire se ci sono problemi all’infrastruttura di rete.
Come prima operazione, dopo essere entrati nella shell del
nostro sistema, eseguire il comando
git clone https://github.com/sivel/speedtest-cli.git
e successivamente entrare nella direcotry
cd speedtest-cli
ed eseguire il programma con
python speedtest_cli.py
per vedere quindi un risultato tipo questo:
ottenendo quindi un valore per la velocità di download (in
Mbit/s) che per l’upload. Buone prove.