2What 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 .
3Why 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.
4Who needs UIDIGI ?Any APRS digipeater owner/operator who has a TNC2 and wants to optimize performance in the APRS network.
5Who DOES NOT need UIDIGI ? Fixed (Home) or Mobile OperatorsUIDIGI 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 OperatorsUIDIGI does not support HF or Internet Gateway operations.
6Why 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.
7Characteristics of UIDIGI Can be installed in any TNC2 or 100% compatible cloneDigipeats ONLY the AX.25 UI framesRoutes 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 digipeatingIgnores duplicated frames sent in a defined intervalProvides password protected remote parameter modificationReplies to the ?APRS? querySupports up to 3 unique Beacons (Text /Path/Interval)
8Limitations 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.
9Why 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 recipientsNo guarantee that all recipients received packet
10Why 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 APRSSimple generic digipeating paths of RELAY and WIDE were usedMobile (moving) stations could always utilize same digipeating path, without the need to modify TNC parametersDigipeater TNCs could be set to respond to their own callsign and the generic aliases of RELAY and WIDEThe 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 timesIW3FQG> APRS v RELAY, WIDE, WIDEIW3FQG> APRS v DIGI1*, WIDE, WIDEIW3FQG> APRS v DIGI1, DIGI2*, WIDEIW3FQG> APRS v DIGI1, DIGI2, DIGI1*
11Why 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.
12Why 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-2DIGI1 acts upon the RELAY IW3FQG>APRS v DIGI1,WIDE2-2DIGI2 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 0IW3FQG>APRS v DIGI1,WIDE2*No further digipeating will occur since the hop counter has reached zero.
13Why 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-2DIGI1 acts upon the RELAY IW3FQG>APRS v DIGI1,TRACE2-2DIGI2 acts upon the first hop of the TRACE2-2 and decrements the hop count:IW3FQG>APRS v DIGI1,DIGI2*,TRACE2-1DIGI3 acts upon the second hop of the TRACE2-2 and decrements the hop count to 0IW3FQG>APRS v DIGI1,DIGI2,DIGI3*,TRACE2No further digipeating will occur since the hop counter has reached zero.
14Why 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 .
15TNC-based alternatives to UIDIGI KANTRONICS KPC-3/KPC-3+De facto standard for APRS digipeatersCallsign substitution supportedDigi callsign inserted in place of generic RELAY or WIDEFlooding (WIDEn-N & TRACEn-N) supportedIncomplete packet duplication checking algorithm can result in multiple transmissions of the same packetDoesn’t support directional (SSID-based) routingPACCOM TINY2 (Standard TNC2 Firmware)Supports only generic routing (RELAY,WIDE,TRACE)KENWOOD TM D-700Recently released radio/TNC supports most UIDIGI routing methodsNo preemptive digipeating
16PC-based alternatives to UIDIGI APRSDIGIHandles up to 2 ports with KISS TNCRouting techniques partially implementedDIGI_NEDHandles up to 15 ports of several of typesTNC, modem, etc.Runs under DOS or LinuxMost routing protocols supportedWinAPRS or UI-VIEWCan be configured for digipeater, but primarily designed as APRS user applications
17The 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).
18The brief history of UIDIGI (2/4) Much of 1999 was spent evolving the design of UIDIGI.Testing was performed on my home digipeaterSeveral versions of UIDIGI were generatedIn later versions, I introduced the advanced routing and duplicate suppression algorithms
19The 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.
20The 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 createdCentral location for UIDIGI software and documentationForum for communications between UIDIGI usersInformation on upcoming versions
21The 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.
22AddressesUIDIGI Home pageUIDIGI mailing list:Addresses for IW3FQGPacket I3KUH.IVEN.ITA.EUInternet:Geographic Coordinates:Latitude: 45 ° 33' 24" NLongitude: 11° 32' 34" E
23ReferenceManual and introduction of UIDIGI by IW3FQG
24Special 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 spreadsheetAllan Sadowski AH6LS for checking and correcting my original version of the UIDIGI English Manual