1. An Introduction to UIDIGI
Copyright © 2000
Marco Savegnago IW3FQG

2. 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 .

3. 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.

4. Who needs UIDIGI ?
Any APRS digipeater owner/operator who has a TNC2 and wants to optimize performance in the APRS network.

5. 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.

6. 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.

7. 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)

8. 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.

9. 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

10. 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*

11. 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.

12. 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.

13. 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.

14. 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 .

15. 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)
KENWOOD TM D-700
Recently released radio/TNC supports most UIDIGI routing methods
No preemptive digipeating

16. 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

17. 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).

18. 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

19. 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.

20. 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

21. 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.

22. Addresses
UIDIGI Home page
UIDIGI mailing list:
Addresses for IW3FQG
Packet I3KUH.IVEN.ITA.EU
Internet:
Geographic Coordinates:
Latitude: 45 ° 33' 24" N
Longitude: 11° 32' 34" E

23. Reference
Manual and introduction of UIDIGI by IW3FQG

24. 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