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