DIGIS.TXT DIGIPEATER SET UP IN APRS Document version: 8.7.3 19 Feb 2005 (Previous was 867 of 24 July 2004) Author(s): Bob Bruninga, WB4APR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In Nov 2004 and then in earnest in early 2005, we launched a major new Paradigm for APRS digipeating called the New n-N Paradigm. In summary, it brings about a drastic reduction in QRM to the APRS network by encouraging the use of WIDEn-N for small values of N and by discouraging the old WIDE,WIDE and RELAY,WIDE paths that can produce 3 to 5 times the number of dupes as the more efficient WIDEn-N system. It also provides custom traps for large values of N depending on local loads. This is important because WIDE7-7 for example can generate as many as 200 packets! The New n-N Paradigm also introduces SSn-N systems for state wide communications for special events (not routine). In July 2004, much of the USER PATH information was split from this file and placed in PATHS.TXT and only the DIGIPEATER information needed by DIGI sysops was retained in this file. But SYSOPS must be fully familiair with PATHS.TXT also. PLEASE SEE THE WEB PAGE FOR HOW TO SET UP A DIGI: http://www.ew.usna.edu/~bruninga/aprs/fix14439.html BACKGROUND: This file originated in 1994 to describe the detail objectives of the unique generic APRS approach to digipeating. It is a MUST READ for anyone who seriously uses APRS including the web page above. Or google for "fix14439.html" Digipeaters are the most important APRS asset, our lifeline if used properly, but a source of QRM and inconsistencies if not. First, here is what an APRSdigi is expected to do: 1) OBSOLETE: Digipeat with callsign substitution for the alias of RELAY. NEW WAY: The new way, the old RELAY is replaced with WIDE1-1. This lets every WIDEn-N digi support it without duplication while simple TNC fill-in digi's can still support WIDE1-1 only. 2) Under the New n-N Paradigm, the additional aliases are used as *traps* for large values of N. By adding the UIDIGI aliases of WIDE4-4, WIDE5-5, WIDE6-6 and WIDE7-7, the digi will effectively trap the large hop n-N paths from any further propogation. They will be digipeated once, but then the digi's call will be substituded and they go nor farther. 3) WIDEn-N becomes the universal APRS path with N being limited as needed in each area. WIDEn-N is supported using the UITRACE parameter so that all paths are traceable. 4) SSn-N is a new capability for allowing larger N's for State or Section wide communications while limiting the out-of-state QRM to other states. Larger values of N for special events or nets is possible because there are only so many digis to hit. SSn-N is supported using the UIFLOOD parameter set to SS, 30 where SS is the state or section abbreviation. Also the ID parameter is enabled so the path is at least traceable to the last hop. 5) CONSISTENT IDENTIFICATIONS: DIGI's should identify themselves to users with consistent nomenclature so that any mobile at any time can be fully aware of the capabilities surrounding him. We want the DIGIs to send a position packet once every 10 minutes LOCALLY and DIRECT only. Then every 30 minutes via one hop, and no more than once every hour or more for 2 hops. A special technique using the LText, LTPath and BLT functions is used to implement this complex technique but with no dupes. 5) DIGI OVERLAYS: The DIGI's POSITION packet should indicate the proper ICON and overlay character. New-N-N type digis supporting the SSn-N should use the "S" overlay otherwise the "L" character. Also the old PacComm "T" Trace digis can now be improved to "P" digis which are compatible with the New n-N Paradigm too. 6) LOCAL ASSETS: The digi's unused BText may be used LOCALLY and DIRECT to also put one special local object of local interest on the map periodically, such as the local voice repeater most used by travelers and APRS users. DIGIPEATER LOCAL NETWORK SIZE: As noted in PATHS.TXT, a local network cannot possibly support more than about 60 to 100 or so users on the 144.39 channel because that is the number of stations that can statistically generate a 100% busy channel! Users and DIGI owners must understand that their RF APRS Network can be no larger that this or else reliability drastically suffers. In a local area with no digipeaters and everyone operating direct, actually 300 stations might be able to share the channel. But one digi and one hop will drop this to about 150. The typical 2 hops in the big cities drops this to the 60 to 100 count we generall refer to. In big cities, this might only be a 20 mile radius needing only one DIGI. In other sparse areas, it might be 150 miles and need 9 digis to cover the typical 50 or so users. This range is called the ALOHA circle and is easily determined anywhere. Everyone should operate with a path only sufficient to hit only their ALOHA area. Anything beyond that is just causing QRM to everyone else. FEWER HOPS: This table from PATHS.TXT is repeated here because it shows the futility of long multi-hop paths. It is just not worth it and is not the design of APRS to go beyond its own local network of 60 or so users. If users want a bigger picture, they should go to the internet! HOPS PROBABILITY #COPIES COMMENTS ---- ----------- ------- -------------------------------------------- 1 50% 1 Local ops & special events (The APRS mission) 2 25% 5 Routine ops (24/7 monitoring for experience) 3 12% 13 extended ops (only occassionally) 4 6% 25 statewide ops Heavy QRM 5 3% 41 Nothing gets through. Too much QRM 6 1% 61 Useless AND totally boggs down network THE NEW n-N PARADIGM: --------------------- In 2003, we realized that over the last 11 years, APRS had grown by orders of magnitude above its self-replicating beginnings, and that the original goals of omni-local flooding of all packets to all nearby digipeaters was killing the network. In busy areas, anything beyond 1 hop is usually going to hit more than 60 surruounding users! To combat this, the new N-N PARADIGM was defined to give local SYSOPS several tools they could use to regain control of the traffic in their local area without significantly having to modify user behavior: 1) Simply trap large values of WIDEn-N by placing WIDE7-7,WIDE6-6, WIDE5-5,WIDE4-4 in the UIDIGI or ALIAS list. 2) MOVE WIDEn-N support to the UITRACE parameter. This allows all WIDEn-N traffic to be traced. This eliminates the need for the old WIDE,WIDEn-N type of path to find out where the packet originated. Any path that begins with WIDE (or RELAY) generates from 3 to 5 times the number of dupes of a WIDEn-N packet. 3) Now use UIFLOOD for supporting SSn-N for your state use. In small states, it inherently limits QRM from crossing state borders. Turn the ID parameter on so that at least we get to see the last digi used. ALT-CHANNEL INPUTS: Another very powerful local improvement in reliabilty can be achieved by adding an additional local digipeater input channel such as 144.99 if available in your area. It will only hear locals and not the other 98% of QRM on 144.39. This is the only reliable way that lower power devices can be heard. Digis on 144.39 hear 98% of channel QRM from out of area. GOOGLE: alt-channel.html DEDICATED WIDE AREA APRS DIGIPEATER SET UP The EASIEST digi is the Kantronics KPC-3+ as is. Older TAPR-2 clones can be programmed with a UIDIGI-ROM, or any TNC can be operated in KISS mode with a dedicated old PC using DIGI_NED. Since I cannot address all of the various settings in every type of TNC, here are the settings for the KPC-3: MYCall W3XYZ-x UIDIGI ON WIDE4-4,WIDE5-5,WIDE6-6,WIDE7-7 <= these do callsign substitution. UIFLOOD SS,30,ID <= Supports SSn-N for your state UITRACE WIDE,30 <= Supports WIDEn-N CD SOFTWARE HID OFF LT 1 !DDMM.mmNSDDDMM.mmW#PHGphgd W3,SSn comments... A=003456 LT 2 !DDMM.mmNSDDDMM.mmW#PHGphgd W3,SSn comments... A=003456 LT 3 !DDMM.mmNSDDDMM.mmW#PHGphgd W3,SSn comments... A=003456 LT 4 !DDMM.mmNSDDDMM.mmW#PHGphgd W3,SSn comments... A=003456 LTP 1 APRS LTP 2 APRS LTP 3 APRS VIA WIDE1-1 LTP 4 APRS VIA WIDE2-2 BLT 1 E 00:30:00 START 00:00:00 at 00 and 30 BLT 2 E 00:30:00 START 00:10:00 at 10 and 40 BLT 3 E 01:00:00 START 00:20:00 at 20 BLT 4 E 02:00:00 START 00:50:00 at 50 every other hour The result is one local packet every 10 minutes and one area packet every 30 minutes which covers the two APRS standard net-cycle times. And once every 2 hours it lets the area know of its presence. Note that HID MUST BE OFF. See HID.TXT. POSIT TEXT: The posit text above is standard APRS posit as follows: ! means it is a fixed, non moving posit DDMM.mmN/DDDMM.mmW is LAT/LONG in degrees and minutes PHGphgd where p is power as the SQRT of P h is log2(HAAT/10) G is gain in dBd d is directivity in deg/45 # means it is a digipeater / The separator between the LAT/LONG should be: R for old RELAY-only digis W for WIDE-RELAYS (obsolete) N for old WIDEn-n digis P for New-N PacComm TNC's S for New-N WIDEn-N digis with SSn-N L for New-N Limited WIDEn-N digis 1 for New-N 1 hop enforced /A=xxxxxx is altitude in feet for 3D. Put at end of comment field to preserve first 20 chars that can be seen by Mobiles. This field is optional and not needed if you have something else more important to say. You can see by the integers in the POWER-HEIGHT-GAIN (PHG) string, there are only 10 possible values for each of these fields as follows: DIGITS 0 1 2 3 4 5 6 7 8 9 as used in the PHG field ------------------------------------------------------------------------- POWER 0, 1, 4, 9, 16, 25, 36, 49, 64, 81 watts SQR(P) HEIGHT 10,20,40, 80,160,320,640,1280,2560,5120 feet LOG2(H/10) GAIN 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 dB DIR OMNI,NE, E, SE, S, SW, W, NW, N, . This offsets the range circle in the indicated direction HEIGHT ABOVE AVERAGE TERRAIN: Although formulas exist, use common sense. If your DIGI is only a hundred feet or so up, estimate the average terrain going out 10 miles around the digi. If it is above several hundred feet assess average terrain going out 20 or more miles. Subtract the altitude of this surrounding terrain from the height of the antenna to get your HAAT. You may be at 2000 feet above sea level and have a 150 foot tower, but if the ground around you is at 2200 feet, then your HAAT is -50 feet!!! Be honest! Your PHG circle should go no further than the distance to which you can reliably copy an HT. Even though you have an OMNI antenna, if the terrain favors a certain direction, then put that in for your directivity. APRS will offset the circle in that direction by about 6 dB If your HAAT is in the thousands of feet, fudge the values to give reliable PHG circle that matches actual coverage. A 5000 elevation never gives a HAAT of 5000 feet unless it is on an island. SYSOP REMINDERS! HID should be OFF. It is just a wasted packet every 10 minutes. We used to insist that UIFLOOD must be set to NOID and NOT to ID. This was so that WIDEn-N packets could be traced by preceeding them with WIDE,WIDEn-N to force callsign substitution on the first hop. Problem was, this also generated multiple dupes. Since WIDEn-N will now be fully traced, this is not an issue and since UIFLOOD is now for SSn-N routing, it will be best to have ID ON to at least show how packets arrive. Also be sure to see the entire new n-N paradigm and all the other problems we need to fix on the global APRS network (144.39 in North America). GOOGLE: fix14439.html RELIABILITY is the goal of APRS, NOT seeing how many stations you can see. If you are seeing more than about 60 stations on your RF channel then your local reliability is suffering and weak signals or new data cannot get through reliably. Keeping paths short and using the new LINKn-N, SSn-N and LANn-N limited networks can make your local area less vulnerable to abuse by user mistakes. See PATHS.TXT ORIGINAL LEVEL FOUR NETWORK CONSIDERATIONS: These concepts were proposed in the early days of APRS (1994) but were made more or less obsolete by the growth of the APRS Internet System. They are retained here for historical purposes. Since NODES are smarter than digipeating, the ultimate we should have NODES do all UI frame routing via high speed backbones. The APRS station simply sends his UI frame TO APRS VIA HOME; Any NODE hearing that transmission that has knowledge of the route to HOME, will send the single packet via the NODE network (level 4) to the HOME node! When it arrives at the HOME node, it is transmitted once as a UI frame. With this arrangement, a mobile only has to specify his one intended destination, no matter where he travels! In this example I use the DIGI call of HOME just to represent the digi near someone's HOME... DIGI/NODE COMPATIBILITY: Mobiles should be able to specify a path that is compatible with both nodes and digipeaters. The nodes should only look at the LAST digi field in an UNPROTO list for the final NODE destination. Any preceeding fields are assumed to be DIGI's only. This way a path of APRS VIA WIDE,HOME would be repeated by any WIDE that heard it, but any level 4 node that heard it would forward it to the HOME NODE. If only one field is included in the digipeater string, it would be interpreted as both a digi and a HOME destination without any difficulty. Digi's and NODEs would digipeat it, and nodes (hearing it direct) would forward it at level-4. de WB4APR, Bob