An Introduction to UIDIGI
Copyright © 2000
Marco Savegnago IW3FQG
What is UIDIGI?
• UIDIGI is custom TNC2 (or
TNC2 clone) firmware which
provides advanced APRS*
digipeater capabilities.
(*) APRS is a registered trademark of Bob
Bruninga WB4APR .
Why UIDIGI ?
• UIDIGI is optimized for APRS
digipeating service and provides unique
features for operation within a complex
APRS network.
• UIDIGI uses readily available TNC2 (or
TNC2 clone) hardware.
– The TNC2/clone can be found new or used
and offers the least expensive TNC option
for an APRS digipeater.
Who needs UIDIGI ?
• Any APRS digipeater
owner/operator who has a TNC2
and wants to optimize performance
in the APRS network.
Who DOES NOT need UIDIGI ?
• Fixed (Home) or Mobile Operators
– UIDIGI does not interface with
common APRS user applications
(APRSdos, Mac/Win APRS,
APRS+SA, UI-VIEW).
– Standard TNC firmware or a Baycom
modem should be used for these
applications.
• Gateway Operators
– UIDIGI does not support HF or Internet
Gateway operations.
Why UIDIGI was written?
• I had several unused TNC2s at
home and didn’t want to buy a
new 1200 baud TNC in the year
2000!
• New and used TNC2s (and
clones) are easy to get.
• A TNC-only based digipeater is
more reliable than a computer
based system, which is critical
if the digi is located on a remote
mountaintop.
Characteristics of UIDIGI
•
•
•
•
•
•
•
•
Can be installed in any TNC2 or 100% compatible clone
Digipeats ONLY the AX.25 UI frames
Routes and makes call substitution of frames addressed to
generic addresses (RELAY, WIDE TRACE), flooding
addresses (WIDEn-N, TRACEn-N) and directional addresses
(based on SSID)
Supports preemptive digipeating
Ignores duplicated frames sent in a defined interval
Provides password protected remote parameter modification
Replies to the ?APRS? query
Supports up to 3 unique Beacons (Text /Path/Interval)
Limitations of UIDIGI
• Cannot be used as an APRS gateway
• Does not support weather stations (not yet!)
• Cannot be used in conjunction with APRS
application programs like UI-VIEW or
WinAPRS.
Why an APRS dedicated
digipeater? (1/6)
• APRS is based on the AX.25 protocol but uses
only characteristics which allow data broadcast
via Unnumbered Information (UI) frame types.
– AX.25 is primarily a connection oriented
protocol, but supports unconnected operations.
• UI digipeating differs from transport of
information between two connected stations.
– One packet broadcast to many recipients
– No guarantee that all recipients received packet
Why an APRS dedicated
digipeater? (2/6)
•
Initial APRS operations used simple AX.25 frame addressing and routing schemes
which provided sufficient performance in the low density operating environment.
–
–
–
–
•
Typical digipeating addresses such as CQ or APRS
Simple generic digipeating paths of RELAY and WIDE were used
Mobile (moving) stations could always utilize same digipeating path, without the need to
modify TNC parameters
Digipeater TNCs could be set to respond to their own callsign and the generic aliases of
RELAY and WIDE
The above simple network architecture performed adequately until the number of
users started to increase and network coverage areas widened.
–
–
–
Digipeating paths were increased to span wider coverage areas (e.g. via
RELAY,WIDE,WIDE)
Multiple digipeaters which overlapped a coverage area would create duplicate packets
and/or packet annihilation (simultaneous transmission by multiple digis which results in
packets that destructively cancel each other)
Lack of duplication checking in TNCs could result in a digi sending the same packet
multiple times
•
•
•
•
IW3FQG> APRS v RELAY, WIDE, WIDE
IW3FQG> APRS v DIGI1*, WIDE, WIDE
IW3FQG> APRS v DIGI1, DIGI2*, WIDE
IW3FQG> APRS v DIGI1, DIGI2, DIGI1*
Why an APRS dedicated
digipeater? (3/6)
•
Increasing network complexity and resulting network
congestion required additional techniques to be
devised.
•
APRS functionality is based on standard AX.25 frame
handling; however , modifications would be required
to implement the APRS improvements.
•
An APRS digipeater would act as simple AX.25
digipeater plus it would employ new rules to reduce
channel congestion by minimizing packet duplication
and frame length.
•
The first method introduced forced the substitution of
the generic callsign with the callsign of the digipeater
which repeated the packet.
Why an APRS dedicated
digipeater? (4/6)
•
The second method (called flooding) set simple rules for
propagation of a frame for n-hops without increasing the
frame length.
– A path of WIDEn-N was defined where “n” is the total
number of hops and “N” starts at “n” and is decremented
each time a digipeater repeats the packet.
Example:
A Source Frame of
IW3FQG>APRS v RELAY,WIDE2-2
DIGI1 acts upon the RELAY
IW3FQG>APRS v DIGI1,WIDE2-2
DIGI2 acts upon the first hop of the WIDE2-2 and decrements the hop count:
IW3FQG>APRS v DIGI1,WIDE2-1*
DIGI3 acts upon the second hop of the WIDE2-2 and decrements the hop count to 0
IW3FQG>APRS v DIGI1,WIDE2*
No further digipeating will occur since the hop counter has reached zero.
Why an APRS dedicated
digipeater? (5/6)
•
The third method (called flooding and tracing) is derived from
the above second method, and allows a station to know the path
that a frame has taken to reach its final destination.
– A path of TRACEn-N was defined where “n” is the total number
of hops and “N” starts at “n” and is decremented each time a
digipeater repeats the packet. When a digipeater repeats a frame it
inserts its callsign into the path.
Example:
A Source Frame of
IW3FQG>APRS v RELAY,TRACE2-2
DIGI1 acts upon the RELAY
IW3FQG>APRS v DIGI1,TRACE2-2
DIGI2 acts upon the first hop of the TRACE2-2 and decrements the hop count:
IW3FQG>APRS v DIGI1,DIGI2*,TRACE2-1
DIGI3 acts upon the second hop of the TRACE2-2 and decrements the hop count to 0
IW3FQG>APRS v DIGI1,DIGI2,DIGI3*,TRACE2
No further digipeating will occur since the hop counter has reached zero.
Why an APRS dedicated
digipeater? (6/6)
• The last method allows a station to set the
preferred geographic propagation route
based on the SSID of the destination
address. This is an experimental method
that can be enhanced or changed.
• UIDIGI 1.8 also provides a new method
called preemptive digipeating that allows
a digipeater to preemptively repeat a
frame when it sees its callsign later in the
destination path .
TNC-based alternatives to UIDIGI
•
KANTRONICS KPC-3/KPC-3+
– De facto standard for APRS digipeaters
– Callsign substitution supported
• Digi callsign inserted in place of generic RELAY or WIDE
– Flooding (WIDEn-N & TRACEn-N) supported
– Incomplete packet duplication checking algorithm can result in
multiple transmissions of the same packet
– Doesn’t support directional (SSID-based) routing
•
PACCOM TINY2 (Standard TNC2 Firmware)
– Supports only generic routing (RELAY,WIDE,TRACE)
– Callsign substitution supported
•
KENWOOD TM D-700
– Recently released radio/TNC supports most UIDIGI routing
methods
• No preemptive digipeating
PC-based alternatives to UIDIGI
• APRSDIGI
– Handles up to 2 ports with KISS TNC
– Routing techniques partially implemented
• DIGI_NED
– Handles up to 15 ports of several of types
• TNC, modem, etc.
– Runs under DOS or Linux
– Most routing protocols supported
• WinAPRS or UI-VIEW
– Can be configured for digipeater, but
primarily designed as APRS user
applications
The brief history of UIDIGI (1/4)
•
At the 1995 Dayton Hamvention I purchased my first
GPS handheld receiver and was first introduced to the
concept of APRS.
•
By 1997 most of the local packet activity was focused
on high-speed networking. I was considering donating
my (no-longer useful) TNC2s to friends or young
hams. I then realized that these could be used to
stimulate APRS activity in Italy. Initial demonstrations
didn’t generate much interest.
•
In 1998 I bought a surplus Z80 development system.
•
In 1999 interest in APRS started to grow in my region
of Italy (I3). I wrote my first version of UIDIGI and
installed it in an APRS digipeater in MonteCorno (site
of most of our packet radio network nodes and relay).
The brief history of UIDIGI (2/4)
• Much of 1999 was spent evolving the design of
UIDIGI.
– Testing was performed on my home digipeater
– Several versions of UIDIGI were generated
– In later versions, I introduced the advanced routing and
duplicate suppression algorithms
The brief history of UIDIGI (3/4)
•
In March 2000 I made the worldwide introduction of UIDIGI
and made the first public release (version 1.6).
•
In June 2000 I released version 1.7, which included a complete
code rewrite and included several enhancements.
•
Exposure of UIDIGI to the APRS community leads to
utilization of the firmware in digipeaters worldwide.
The brief history of UIDIGI (4/4)
• At 2000 year-end version 1.8 is in the final beta stage and includes
further enhancements.
• In 2000, a dedicated UIDIGI mailing list was created
– Central location for UIDIGI software and documentation
– Forum for communications between UIDIGI users
– Information on upcoming versions
The future of UIDIGI?
• The UIDIGI firmware has nearly matured to the point of meeting my
personal goals.
• I hope that it can be used worldwide in various APRS networks.
• I have many other projects and enhancements dealing in digital
communications (outside APRS) which I plan on pursuing.
Addresses
• UIDIGI Home page
http://space.tin.it/computer/msavegna/uidigi.htm
• UIDIGI mailing list:
http://www.egroups.com/group/uidigi
• Addresses for IW3FQG
– Packet Radio:IW3FQG @ I3KUH.IVEN.ITA.EU
– Internet: iw3fqg@amsat.org
– Geographic Coordinates:
• Latitude: 45 ° 33' 24" N
• Longitude: 11° 32' 34" E
Reference
• Manual and introduction of UIDIGI by IW3FQG
Special Thanks
Thanks to:
– Greg Noneman WB6ZSU for checking and correcting
my original version of this presentation, for the support
in debugging, testing and for the original UIDIGI
command spreadsheet
– Allan Sadowski AH6LS for checking and correcting
my original version of the UIDIGI English Manual