Introduzione a UIDIGI
Copyright © 2000
Marco Savegnago IW3FQG
Cos'e' UIDIGI?
• UIDIGI e' un firmware da
utilizzare con un Terminal
Node Controller tipo
TNC2 o compatibile al
100% per realizzare un
digipeater packet radio
con funzioni avanzate di
soppressione e routing dei
frame APRS (*)
(*) APRS e’ un marchio registrato
da Bob Bruninga WB4APR).
A cosa serve UIDIGI ?
•
Chiunque opera in una rete packet radio APRS sa' che
il sistema funziona se ci sono dei digipeater che
indipendentemente dal loro nominativo siano in grado
di ripetere frame indirizzati a path generici (es
RELAY o WIDE). Per far questo e' sufficiente usare
un normale firmware ma senza una opportuna
gestione del traffico di ripetizione e soppressione dei
frame duplicati, in situazioni di sovraffollamento e
non il sistema diventa ben presto inutilizzabile.
Ciononostante UIDIGI non aiuta a risolvere tutti i
problemi di cui puo’ soffrire un’area in cui molte
stazioni usano disordinatamente il sistema.
A chi serve UIDIGI ?
•
A chiunque possiede o gestisce un digipeater
dedicato al traffico APRS con un TNC2 e vuole
che questo gestisca al meglio il traffico delle
stazioni che operano in APRS.
A chi NON serve UIDIGI ?
•
•
UIDIGI non serve a chi deve operare come
stazione fissa o mobile in APRS con programmi
tipo WinAPRS o UI-VIEW. Per questi e’
sufficiente il firmware disponibile nel TNC o un
modem Baycom gestito con l’opportuno driver.
UIDIGI non dispone di funzioni che gli
consentono di operare come una stazione
gateway
Perché ho scritto UIDIGI?
•
•
•
Perché avevo diversi TNC2 a casa
inutilizzati e non avevo nessuna
intenzione (alle soglie del terzo
millennio) di acquistare un nuovo TNC
a 1200bd!
Perché anche se e' possibile usare un
qualsiasi firmware da TNC per
realizzare un digipeater APRS, UIDIGI
implementa una serie di funzionalita’
che lo rendono adatto a venir impiegato
in una rete APRS complessa.
Perché in montagna un PC e’ sempre
difficile da gestire e comunque
consuma molta piu’ di energia elettrica
di un TNC!
Caratteristiche di UIDIGI
•
•
•
•
•
•
•
UIDIGI funziona su un TAPR TNC2 o compatibile al 100%,
progetto ormai obsoleto ma valido e soprattutto disponibile in
tutto il mondo.
Ripetizione dei soli frame AX.25 UI
Routing e call substitution dei frame inviati a indirizzi generici
(RELAY, WIDE TRACE), a scalare WIDEN-N, TRACEN-N e
direzionali in base a SSID
Limitazione automatica della ripetizione di frame gia’
trasmessi
Gestione remota protetta da password
Risposta ai frame di query APRS provenienti da altre stazioni
3 beacon indipendenti
Limitazioni di UIDIGI
• Non puo’ essere usato per realizzare gateway
APRS
• Attualmente non gestisce il preempted
digipeting
• Non gestisce stazioni meteoreologiche
• Il TNC non puo’ essere usato da stazioni che
operano in APRS con programmi di tracking
UI-VIEW o WinAPRS
Perché un digipeater dedicato a
APRS? (1/6)
•
•
Il sistema APRS sfrutta la caratteristica del
protocollo AX.25 (che tipicamente e' un protocollo
dove le stazioni che si scambiano informazioni sono
virtualmente connesse tra loro) di inviare frame con
informazioni definiti UI (Unnumbered Information)
anche tra stazioni che non risultano connesse tra
loro.
Tale metodo al contrario del trasporto di
informazioni tra due stazioni connesse da un lato
permette di trasmettere informazioni con il criterio
uno a molti, dall'altro non garantisce che tutti i
possibili destinatari ricevano le informazioni con
certezza. Il sistema APRS si affida a questa
caratteristica del protocollo AX.25 per trasmettere le
informazioni tra le stazioni.
Perché un digipeater dedicato a
APRS? (2/6)
•
•
•
•
In origine il metodo di propagazione dei frame AX.25 usati dal sistema APRS era
una semplice ripetizione di frame destinati a nominativi generici ( CQ o APRS) e
con percorsi di ripetizione generici (RELAY o WIDE) in modo da permettere a
stazioni in movimento sul territorio di spostarsi permettendo ai propri beacon di
propagarsi senza dover modificare alcun parametro del TNC.
Questo si realizzava semplicemente installando dei digipeater costituiti da TNC ai
quali veniva impostato come nominativo il nome del digipeater e come alias un
nominativo generico (RELAY o WIDE). Questo sistema ha funzionato e funziona
finché stazioni e digipeater isofrequenza sono pochi ma comincia ad andare in crisi
quando le stazioni aumentano e il territorio da coprire si estende.
Così un frame del tipo: IW3FQG>APRS v RELAY, WIDE, WIDE
viene ripetuto dal primo UIDIGI con la sostituzione del call:
IW3FQG>APRS v UIDIGI*, WIDE, WIDE
Questo consente che frame gia' ripetuti da un digipeater non vengano nuovamente
ripetuti generando loop e duplicazioni e in definitiva traffico inutile.
Perché un digipeater dedicato a
APRS? (3/6)
•
•
•
•
Per questo nel corso degli anni sono stati introdotti dei metodi di
ripetizione applicati ai digipeater che consentono di limitare i
problemi dovuti alla progressiva congestione dei canali radio dovuta
al traffico e all'eccesso di ripetizioni dei frame.
Tutte le regole che seguono sono delle modifiche richieste dal sistema
APRS al comportamento standard di un puro digipeater AX.25 perché
va' ricordato che il sistema APRS si serve di AX.25 per funzionare.
Il primo metodo introdotto fu' quello che forza la sostituzione, da
parte del digipeater che ripete il frame, del nominativo generico usato
dalla stazione che ha trasmesso in origine il frame.beacon di
propagarsi senza dover modificare alcun parametro del TNC.
Questo si realizzava semplicemente installando dei digipeater
costituiti da TNC ai quali veniva impostato come nominativo il nome
del digipeater e come alias un nominativo generico (RELAY o
WIDE). Questo sistema ha funzionato e funziona finché stazioni e
digipeater isofrequenza sono pochi ma comincia ad andare in crisi
quando le stazioni aumentano e il territorio da coprire si estende.
Perché un digipeater dedicato a
APRS? (4/6)
•
•
•
Il secondo metodo e' stato quello di introdurre delle semplici regole di
propagazione dei frame fino a certo numero di 'salti' senza dover aumentare
eccessivamente la lunghezza del frame da trasmettere e ricevere.
La prima di queste regole fa' in modo che frame inviati a nominativi tipo WIDEn-n
(con n > 0 e n < 8) vengano trattati in questo modo:
Un frame del tipo: IW3FQG>APRS v RELAY,WIDE1-1
viene ripetuto dal primo UIDIGI: IW3FQG>APRS v UIDIGI*, WIDE1-1
e dal secondo UIDIGI (viene decrementato l'ssid e NON viene settato il bit H):
IW3FQG>APRS v RELAY*, WIDE1-0
e dal terzo UIDIGI (non viene decrementato l'ssid perché e' gia' zero e viene
settato il bit H): IW3FQG>APRS v RELAY, WIDE1-0*
In definitiva il frame pur rimanendo con lunghezza limitate (ogni nominativo nella
lista digipeater occupa 7 byte) viene ripetuto automaticamente fino a un massimo
di 7 volte.
Perché un digipeater dedicato a
APRS? (5/6)
•
Il terzo metodo derivata dalla seconda serve allo stesso scopo ma consente alla
stazione che riceve il frame di conoscere il percorso di ritrasmissione che il frame
ha compiuto cosi’ un frame del tipo:
IW3FQG>APRS v RELAY,TRACE1-1
viene ripetuto dal primo UIDIGI: IW3FQG>APRS v UIDIGI*, TRACE1-1
e dal secondo UIDIGI (viene decrementato l'ssid e viene inserito il call del
digipeater con il bit H settato):
IW3FQG>APRS v RELAY, DIGI1*, TRACE1-0
e dal terzo UIDIGI (l'ssid e' a zero viene fatta la sostituzione del nominativo con
quello del digipeater e su questo viene settato il bit H): IW3FQG>APRS v
RELAY, DIGI1, DIGI2*
Perché un digipeater dedicato a
APRS? (6/6)
•
Infine il quarto metodo più recente e' quello che
consente a una stazione di indicare il percorso di
propagazione geografica da utilizzare e che i
digipeater opportunamente settati facciano
compiere al frame.
•
Questo metodo e' ancora sperimentale e non
completamente documentato
Alternative a UIDIGI basate su
TNC
• KANTRONICS KPC3
• Standard di fatto, supporta call substitution e routing a
scalare, non supporta routing direzionale ha qualche
problema con la soppressione delle ripetizioni
• PACCOM TINY2
• Gestisce solo il routing generico (RELAY, WIDE,
TRACE) e call substituion
• KENWOOD TM D-700
• Implementazione completa di tutti i tipi di routing,
implementazione forse piu’ recente e completa
Alternative a UIDIGI basate su
PC
• APRSDIGI
• Gestisce fino a 2 porte realizzate da TNC in
kiss mode con gestione parziale del routing
• DIGI_NED
• Gestisce fino a 15 porte radio e molti tipi di
hardware e praticamente tutte le
combinazioni possibili di routing previste
• WinAPRS o UI-VIEW
• Entrambi validi ma a mio parere piu’ adatti
solo al tracking
UIDIGI la sua breve storia...
•
•
•
•
Nella primavera del 1995 durante hamvention 95 a Dayton,
OH USA acquisto il mio primo ricevitore GPS portatile, sento
per la prima volta parlare di APRS, assisto a una dimostrazione
durante un convegno organizzato dal TAPR.
Nel 1997 penso di regalare i TNC2 che possiedo e ho costruito
negli anni a aspiranti radioamatori per promuovere l’uso del
packet radio in declino. Mi viene in mente APRS e decido di
provare ad allestire la stazione casalinga e mobile per
effettuare alcune prove di valutazione.
Nel 1998 acquisto (in svendita) un sistema di sviluppo
hardware completo per lo Z80 perche’ non si sa’ mai…
Agli inizi del 1999 comincio a sentir parlare di APRS da parte
di altre stazioni nella zona 3 mi rendo conto che non ci sono
alternative se non quelle commerciali per allestire un
digipeater APRS e comincio a pensare di scrivere il software
per i miei TNC2, usando come base di sviluppo i sorgenti della
nordlink.
...UIDIGI la sua breve storia ...
•
•
•
Agli inizi del 1999 comincio a sentir parlare di APRS da
parte di altre stazioni nella zona 3 mi rendo conto che non ci
sono alternative se non quelle commerciali per allestire un
digipeater APRS e comincio a pensare di scrivere il software
per i miei TNC2, usando come base di sviluppo i sorgenti
della nordlink.
Nella primavera del 1999 dopo alcuni mesi di
sperimentazione in casa il 1 Novembre e’ stato installato il
primo digipeater IR3VIF presso la postazione di Monte
Corno con la versione 1.3 di UIDIGI
Entro la fine del 1999 una versione preliminare del firmware
viene inviata ad altri sysop di digipeater APRS della zona 3
per verificare il funzionamento degli algoritmi di routing e
soppressione delle duplicazioni
...UIDIGI la sua breve storia...
•
•
A Marzo 2000 viene rilasciata la versione 1.6 del firmware e
annunciata la disponibilita’ del firmware nella mailing list aprsnews
(dedicata a APRS e gestita dal TAPR). WB4APR mi scrive
complimentandosi per il lavoro e incoraggiandomi a proseguire per
rendere il firmware quanto piu’ compatibile allo standard APRS in via
di definizione da parte dell’APRS Working Group.
A giugno viene rilasciata la versione 1.7 di UIDIGI che, grazie alla
completa riscrittura del codice di gestione, e’ diventata molto piu’
leggera della precedente e questo ha consentito di aggiungere
numerose funzionalita’ tra cui una rinnovata interfaccia sysop e
l’implementazione completa degli algoritmi di routing e
antiduplicazione standard.
...UIDIGI la sua breve storia
(continua)...
• A Ottobre 2000 viene distribuita la versione 1.8 di UIDIGI. Il progetto
e’ pressoche’ quasi completo.
• A Novembre 2000 UIDIGI viene presentato durante i lavori
nell’ambito della manifestazione TRACE2000 a Verona.
E il futuro?
• Ritengo che il progetto UIDIGI oggi ha raggiunto un buon grado di
sviluppo e stabilita’ e spero possa contribuire alla costruzione del
network di digipeater APRS italiani.
• Ora che l’obbiettivo di realizzare il firmware per il digipeater APRS e’
stato raggiunto conto di tornare a uno dei tanti progetti accantonati
negli anni…
Indirizzi e recapiti
• UIDIGI Home page:
http://gw.ir3ip.ampr.org/~iw3fqg/uidigi.htm
• UIDIGI mailing list:
http://www.egroups.com/group/uidigi
• Racapiti di IW3FQG
– Packet Radio:IW3FQG @ I3KUH.IVEN.ITA.EU
– Internet: [email protected]
– Coordinate:
• Latitudine: 45 ° 33' 24" N
• Longitudine: 11° 32' 34" E
Riferimenti
• Manuale e Introduzione a UIDIGI di IW3FQG