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 Feb 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. 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 below. http://www.ew.usna.edu/~bruninga/aprs/fix14439.html 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 using typical KPC-3+ firmware, or UIDIGI ROMS, or DIGI_NED software is expected to do: 1) Digipeat with callsign substitution for the alias of RELAY. This is for backwards compatibility. In general using RELAY is now discourged because it can cause multiplication of dupes. Prior to 2005, the alias list included WIDE, TRACE and SS state abbreviation but these are no longer needed. 2) Under the New n-N Paradigm, the additional aliases are more useful as *traps* for large values of N. By adding the UIDIGI aliases of WIDE4-4, WIDE5-5, WIDE6-6 the digi will effectively trap the large hop 4-4, 5-5 and 6-6 paths from any further propogation. They will be digipeated once, but then the digi's call will be substituded and they go nor farther. The very large path of WIDE7-7 will be trapped by peer pressure and user education. 2) UIFLOOD should be set to SS, 30 where SS is the state abbreviation or ARRL section (for big states). This allows the use of SSn-N propogation in the state, but eliminates QRM from going beyond the borders. Larger values of N for special events or nets is possible because there are only so many digis to hit. Also the ID parameter should be enabled. 3) UITRACE should be set to support WIDEn-N so that all paths are traceable. WIDEn-N (typically 2-2, 3-3 or 4-4) can now become the universal path, since abuse can be trapped in most cases. 4) DIGI's should identify themselves with 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) The POSITION packet should indicate the proper ICON and overlay character and in its comment field identify the type of functions supported. The "L" is the new overlay character for the New n-N Paradigm digis with these Limits on N. 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) The unused BText may be used at a low rate 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 BEST digi was the Kantronics KPC-3 or 3+. Others could not do any of the n-N algorithms. But these days there are many comparable options. DIGI_NED is simply software that runs on any old 286PC or clone via any old TNC in KISS mode. UIDIGI is a ROM system that can plug into ANY old TAPR-2 compatible TNC (there are hundreds of thousands of these out there gathering dust)... 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 RELAY, WIDE4-4,WIDE5-5,WIDE6-6 <= these do callsign substitution. UIFLOOD SS,30,ID <= Supports SSn-N for your state UITRACE WIDE,30 <= Supports WIDEn-N HID OFF LT 1 !DDMM.mmNLDDDMM.mmW#PHGphgd/R,W3,SSn,comments... A=003456 LT 2 !DDMM.mmNLDDDMM.mmW#PHGphgd/R,W3,SSn,comments... A=003456 LT 3 !DDMM.mmNLDDDMM.mmW#PHGphgd/R,W3,SSn,comments... A=003456 LT 4 !DDMM.mmNLDDDMM.mmW#PHGphgd/R,W3,SSn,comments... A=003456 LTP 1 APRS LTP 2 APRS LTP 3 APRS VIA WIDE1-1 LTP 4 APRS VIA WIDE3-3 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: 1 for 1 hop enforced (no n-N support) R for RELAY-only digis W for WIDE-RELAYS (obsolete) P for PacComm TNC's N for old WIDEn-n digis L for new Limited WIDEn-N digis /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 pacekt 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 generates 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 have never caught on... 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