DIGIS.TXT AUTOMATIC PACKET REPORTING SYSTEM DIGIPEATERS Document version: 8.5.0 Document dated: 26 Sept 2003. (prior version was 15 Sept 2001) Author(s): Bob Bruninga, WB4APR ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This file is the basic APRS description of APRS digipeating going back to 1994. It is still current and is a MUST read for anyone who seriously uses APRS. Further, users must also read the on-line NEW N-N PARADIGM concept that tells what is WRONG with many area implementations of APRS on 144.39 and how many local nets are totally saturated and what must be done to fix it. http://www.ew.usna.edu/~bruninga/aprs/fix14439.html Digipeaters are the most important APRS asset, our lifeline if used properly, but a source of QRM and inconsistencies if not. First, some fundamentals... APRS is built on these fundamentals: 1) A net cycle time of 10 minutes for local (direct or 1 digi ops) 2) A net cycle time of 30 minutes for area wide operations. 3) A 1200 baud system operating as an ALOHA random access channel 4) An ALOHA channel (with hidden transmitters) has an optimum throughput at about 20% of channel capacity for maximum reliability. This means in a 30 minute period the most reliable throughput on the local RF channel can be about 360 total packets. Yes, you can get MORE packets through, but at the EXPENSE of reliability (more packets are lost due to collisions). And the reliability falls off much FASTER than any improvement in throughput. DIGIPEATERS: Digipeaters exist to extend the range of your local area APRS network to serve useful communications needs that strive to use these 360 packets per 30 minutes in a meaningful way. Although the use of APRS can be emotionally debated, it still boils down to the fact that no more packets can be reliably shared among all people in a net RELIABLY if these limits are exceeded. By making some rough assumptions about what you want your network to support during EVENTS, or EMERGENCIES or when you need RELIABLE communications, then it is easy to arrive at the number of stations YOUR RF network can reliably support and therefore how many digipeaters can be used to support that task. ALOHA CIRCLE: This magic number of surrounding stations that can be supported reliably on your local RF LAN is the ALOHA limit. It is about 50 users. Looking at a map, draw a circle around your 50 nearest users and that is your reliable APRS network range for that area. It might be only 15 miles in the middle of LA or it might be over 100 miles in Wyoming. The topology doesn't matter. What matters is the number of users on the same 1200 baud channel that can share it reliably with APRS. Here is an example of how I came up with about 50 user stations... TYPE STATION PKTS/30m ea Total PCT of LOAD ------------------- ----------- ----- ----------- 30 Home stations 2 60 16 % 3 LOCAL digis (evy 10m) 3 9 2.5% 9 2nd-tier digis (evy 30m) 1 9 2.5% 5 area WX stations 6 30 8 % 4 Mobiles evy 5m 6 24 6 % 4 Mobiles evy 3m 10 40 11 % 4 mobiles evy 2m 15 60 16 % 4 mobiles evy 1m 30 120 33 % Since this represents the most number of packets that your local network can handle in 30 minutes, this is what drives then how many digipeaters and how many HOPS users must use to be able to communicate within this network of local users. NETWORK OVERLOAD AND QRM: These days, too many users are totally blind to the limitations of the 1200 baud APRS national network and are not satisfied unless they can see hundreds and hundreds of users from the 5 surrounding states covering millions of square miles. This is just impossible and we must get users to only use the path necessary to cover their ALOHA radius as noted above.. Trying to propogate packets too far will KILL the APRS network due to too much QRM and lost reliability. DIGIPEATERS: The range of any AX.25 packet may be extended by specifying one or more digipeater callsigns in the UNPROTO PATH. The packet will be relayed by each such digipeater in turn. After each such digipeat, that callsign is marked as used up so that at any instant, only the "next" digipeater in the list has the potential to digipeat the packet. For conventinoal packet, this requires users to know the complete intended path for their packets... But not in APRS. GENERIC ALIASES: APRS satisfies its real-time, emergency tactical needs without prior knowledge by using generic TO and DIGI callsigns. Even home stations in good locations can help surrounding mobiles if given the generic digipeater callsign alias of RELAY and all digipeaters are aliased as both RELAY and WIDE. This way any station can use any digpeater by using an UNPROTO path of WIDE or he can use any other station as a digipeater by simply addressing the packet VIA RELAY. With this generic digipeating, a mobile, or new station does not have to know anything about the network in advance in order to be seen by adjacent nodes. After 10 minutes and his map begins to show the location of all local stations and digipeaters on frequency, he can then customize his outgoing Unproto path to specific digipeater callsigns to cover his intended area without as much QRM. ROUTES: It is important that as APRS networks mature with fixed, known digipeaters, that users at FIXED stations should avoid using the generic RELAY or WIDE addressing. Although it still makes sense for mobiles to use the path of RELAY,WIDE, the path of RELAY should NEVER be used after the first hop by ANYONE, and never after a WIDE. Remember, every packet addressed via RELAY will key up EVERY APRS station that hears it. In any but the sparsest areas, the result is congestion and collisions which block anyone from copying the packet. APRS WIDE AREA DIGIPEATERS: Wide area APRS digipeaters in sparse areas should be widely separated to provide long distance coverage with the minimum of hops. If there is a need for interim digipeaters to fill in weak signal areas or valleys, then a local RELAY should be installed as needed but ONLY with the RELAY alias. These days (post 2001) any RELAY digi should do callsign-substitution so that the source of the packet and location of the RELAY is included in every such packet. TRACE DIGIPEATING: At Dayton 97, PacComm introduced new TNC ROMs which do callsign-substitution. They insert their callsigns in place of their generic RELAY and WIDE aliases whenever a packet is digipeated. This is called a TRACE digi. The big advantage besides callsign substitution and route identification is that the substituted call is a DUPE elimination mechanism because the digi will never digipeat a packet that has its own callsign already used. This completely eliminates looping duplicate packets. This was a great advance for APRS! This was followed in 1998 with Kantronics finally implementing my APRS WIDEn-N algorithm which further improves long multi-hop effeciency. (Though these days (post 2003), FLOODING the network with long-hop WIDEn-N packets into conjested areas is considered bad amateur practice.) WIDE DIGIPEATING: ALthough in start-up areas any TNC can be used as a WIDE digi simply by setting its MYALIAS to WIDE and its BText to include its APRS position, this is NOT recommended today in areas in a mature APRS environment. Today, only TNC's with the new PacComm 4.0 and Kantronics 8.2 Roms or any of the newer improvements such as UIdigi and DIGI_ned, etc should be used. They should be set up with the four generic calls of RELAY, WIDE, TRACE and your state abbreviation, SS. Though TRACE is not really needed any more. The functions of each of these generic aliases are as follows: RELAY - The universal default for all APRS digipeaters and stations WIDE - Provides generic WIDE area callsign-substitution digipeating TRACE - Identical to WIDE, but because only the TRACE Capable DIgipeaters have TRACE, then it is a safe way of setting a path that will only use these new digis and not cause multiple dupes in the old ones without callsign substitution. (note, these days there should not be SS - Useful for state wide only digipeating HOME STATIONS should no longer set their alias to RELAY by default. That was good back before we had a permanent network of digis, but is BAD now unless the home station is in a favorable location, does callsign- substitution, AND can serve local mobiles that cannot hit the nearest digi otherwise. TRACE DIGIPEATERS: Although WIDE and TRACE are identical in function, the difference is that old WIDE-ONLY digis will not respond to TRACE. Thus using the path of TRACE,TRACE,TRACE is identical to WIDE,WIDE,WIDE but will only be digipeated by callsign-substituting (anti-duplicating) digis whereas WIDE,WIDE,WIDE could loop for a total of 27 dupes if there are enough old WIDE digis in the area. It is time to remove any WIDE-only digipeaters (that do not do callsign substitution and dupe elimination) from the network. WIDEn-N DIGIPEATERS: This was conceived back in 1994 as the most efficient way to FLOOD APRS packets out multiple hops in all directions. It was implemented as the UIFLOOD feature in the Kantronics TNC's. ALthough it has tremendous power for FLOODING the network, it is almost too much of a good thing now (2003). This is because we no longer need it in most populated areas: 1) In 97 the APRS-IS began to use the Internet as an APRS backbone 2) The number of users has grown from hundreds in 1995 to 20,000 now 3) Most areas can't afford FLOODING by packets from far away! Please see the COMPLETE WIDEn-N section further down this page to understand WIDEn-N routing. MOBILES: Mobiles typically use the path of RELAY,WIDE because they may be out of range of a WIDE digipeater but be near someone's home station acting as a RELAY. Even if WIDE digipeaters are 30 to 50 miles apart, as long as every home station and local RELAY digipeater can hit at least one WIDE, then the mobile path of RELAY,WIDE can cover the local area well! Wider ranging mobiles can use the RELAY,WIDE,WIDE path without causing too much QRM because of their low antennas. BUT CONVERSLY, paths starting with RELAY should NEVER be used by a *home* stations since he will undoubtly hit many home RELAYS all at the same time and therefore generate numerous dupes with every packet. SHORT RANGE FOR MOBILES! Mobiles have less than HALF the range of what you expect compared to your normal experince with VOICE repeaters. The human ear will not consider a QSO to fail until it gets painfully noisy. A packet signal will FAIL at the first even ONE millisecond of a single fade. And SINCE mobiles ALWAYS pass through 6 to 30 dB fades due to multipath, then the effective range of a mobile is much less than half of what it is for voice. SO be sure to take this into consideration in your PATH planning. APRS852 reduced all PHG circles by half to compensate. FEWER HOPS: Although you are tempted to set a LONG path so everyone can see you, remember that to them, you are just QRM. Especially since the amount of QRM you generate grows geometrically with the number of hops as shown in the following table. ALSO the probability of a successful packet also goes down greatly. The following table shows the decreasing probability of a successful packet if we assume a 50% probability of collision and each WIDE can hit 4 other WIDES. HOPS PROBABILITY #COPIES COMMENTS ---- ----------- ------- -------------------------------------- 1 50% 1 For local ops & special events 2 25% 5 Routine ops 3 12% 13 extended ops 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 PLEASE limit your hops to just your local region. APRS *IS* designed to assure delivery to EVERYONE in a 1 or 2 hop area for REAL-TIME nets or events. It was NOT designed for large extended area nets with thousands on line... These days you CAN QSO great distances via the IGates, but this is still a LOCAL process with only enough hops to get to your IGate. As MORE people come to APRS, we must begin thinking SMALLER areas... In general all digipeating should be turned OFF in mobiles except in very specifically needed instances of special roving digipeaters. You can imagine what it wouild be like at a Hamfest if as the mobiles converged they all began digipeating each other... DEDICATED WIDE AREA APRS DIGIPEATER SET UP The BEST digi used to be a new Kantronics KPC-3 or 3+. Next best was the PacComm ROM in any TAPR-2 CLONE TNC. But these days there are many better 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, WIDE, TRACE, SS <= these do callsign substitution UIFLOOD WIDE,28,NOID <= turn off to kill DX long hops UITRACE TRACE LT 1 !DDMM.mmN/DDDMM.mmW#PHG5360/A=003456/comments LT 2 !DDMM.mmN/DDDMM.mmW#PHG5360/A=003456/comments) LT 3 !DDMM.mmN/DDDMM.mmW#PHG5360/A=003456/comments) LT 4 !DDMM.mmN/DDDMM.mmW#PHG5360/A=003456/comments) LTP 1 APRS LTP 2 APRS VIA WIDE LTP 3 APRS VIA WIDE2-2 LTP 4 APRS VIA TRACE3-3 BLT 1 E 00:20:00 At 00:00:00 Sends local posit locally every 20 mins BLT 2 E 00:40:00 At 00:10:00 Sends posit out 1 hops every 40 minutes BLT 3 E 01:20:00 At 00:30:00 Sends a 2 hop path once every 80 mins BLT 4 E 02:40:00 At 01:10:00 Sends a 3 hop path once every 160 Mins 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. 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 dB d is directivity in deg/45 # means it is a digipeater / The separator between the LAT/LONG should be: / for WIDE or RELAYS \ for WIDE-RELAYS T for TRACE digis N for WIDEn-n digis /A=xxxxxx is altitude in feet for 3D You can see by the integers in the POWER-HEIGHT-GAIN (PHG) string, there are only 9 plus 0 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: Going out 10 miles in all directions, write down the elevation every mile or so. Average all of these points and compare your elevation to the average. 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 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. The PHG equation assumes nominal stations. It is not good for HAAT's in the thousands of feet. For those digis, chose a value for H or G that gives a good reliable PHG circle that matches actual coverage. OPERATIONS WITH RELAY AND WIDE: The GENERIC WIDE/RELAY digipeating works very well in local areas to assure good reliable local coverage. But care should be given to the use of WIDEn-N routing in BUSY areas. In many cases, the abuse of WIDEn-N large hops by many users brings in just too much DX interference to local operations. Users must remember thta typically, the 1200 baud channel can only support about 50 users in any given RF area. It doesnt matter if this area covers only 10 miles in LA or a million square miles in UTAH, a 1200 baud channel just cannot handle any more packets without severe loss of reliability. SEE HF.TXT for setting up your UNPROTO path for HF and HF/VHF gateways. ********* WIDEn-n ALL DIRECTION GENERIC DIGIPEATING! ************ THE ULTIMATE SOLUTION (back in 1994) FOR MOBILE POSITION REPORTING Since 1994 I had asked for this capability, and it was finally implemented in 1998 Kantronics TNC's. The WIDEn-n digi simply repeats ANY packet with the VIA address of WIDEn-n; but ONLY ONCE. It keeps a copy (or checksum) of the last 30 seconds of packets, and compares each new packet that it hears with these last ones to avoid dupes. This eliminates the multiple looping of packets caused by multiple generic paths such as WIDE,WIDE,WIDE when callsign substituting digis are not used (as many as 21 copies!) In a WIDEn-n network, however, there would only be three packets outward bound 3 hops. (It still generates over 21 packets because it floods all surrrounding digis with packets, but at least there are only one copy per digi)... NUMBER OF HOPS: The "n" in the WIDEn-n path indicates the number of hops. Each DIGI that repeats the packet decrements the WIDE-SSID by one. So the -n decrmenets to zero but the WIDEn portion indicates the original number of hops so that recepients know how far it traveled. A long distance traveler or special event of wide interest might have used up to WIDE3-3 but a local commuter may have only wanted to use WIDE2-2 to limit QRM. SHORT PACKETS! THe biggest advantage of the WIDEn-n routing is that every packet still only has one DIGIpeater call. THis means only 7 bytes of overhead no matter how far the packet goes... This saves 21 bytes in every packet for a 4 hop example. (though 4 hops in most areas is considered bad practice these days)... WIDEn-n ID FUNCTION: Unfortuntely, Kantronics included a SELF-ID function in this algorithm that when enabled at the digipeater, will insert the DIGI's call into the path to identify the digi. But in APRS, THIS ID FUNCTION SHOULD BE OFF! This is because it is destructive. The inserted DIGI ID obliterates (overwrites) any prior path data and the originators intent is LOST. Please understand that it is FAR MORE IMPORTANT to know the FIRST digipeater that a packet hit, not the last. Users therefore begin all packets with WIDE,WIDEn-n so that the first DIGI does callsign substitution and the packet arrives everywhere else as FIRST,WIDEn-n. This is very powerful since it lets recepients estimate the position of a station based on what initial digi he is hitting no matter what his packet contains. This is automatic in APRSdos which will plot the station as a QUESTION mark ICON within about 1 mile of the first DIGI. These are called "vicinity plots" and give you an approximate area until you finally get a real position packet later.. HOWEVER, If ID is ON at ANY digipeater in the path, then the FIRST digi identifier is obliterated and lost. Packets then arrive with the wrong DIGI field and this capability is lost. So never set ID to ON. Leave it as the default of NOID. For more on this topic and the damage that the "ID" setting does to an APRS network, be sure to see the file: http://www.ew.usna.edu/~bruninga/aprs/id-noid.txt UNIVERSAL APRS USER PATH: -------------------------- Now for all the reasons above, the universal APRS path is WIDE,WIDE2-2 ion areas that support WIDEn-N. (Though these days to minimize QRM most areas are encouraging only 2 hop WIDE,WIDE paths).... By starting each path with WIDE, there are two advantages: 1) it is universal and will work anywhere. 2) It does callsign subsititution so that the same digi will never digipeat that packet again and so that you can see where the packet entered the network. TROUBLESHOOTING AND TRACING: ---------------------------- TRACEn-n. Notice, however, that WIDEn-n packets arrive as WIDEn-0, showing that it took n hops, but the receiver has no idea how it got to him. If the WIDEn-n digis also support TRACEn-n, however, then at each hop, not only does the digi decrement the n, but it also INSERTS its MYCALL. This way a TRACEn-n packet arrives as DIGIa,DIGIb,DIGIc, DIGId etc. Although this is very powerful, it also makes the packets grow significanly in length as they propogate and should only be used when you need to know the return path. TNC WIDEn-N COMMANDS: To enable WIDEn-N or TRACEn-N digipeating, there are three new TNC commands: UIFLOOD WIDE, 28, NOID - Sets up WIDEn-n routing. The "28" saves all digipeated packets for 28 seconds and will ignore dupes. Notice "28" so that 30 second trackers will get through in special events... UITRACE TRACE - Same as WIDEn-n but does callsign insertion ***** WARNING: These KPC-3 and Paccomm algorithms are so powerful, that they should never be enabled at homes, but ONLY at HIGH WIDE sites. If it is enabled at any home stations, this will SEVERLY QRM the network... Only UIDIGI RELAY can be used at user stations. LEVEL FOUR NETWORK CONSIDERATIONS: Since NODES are so much smarter than digipeating, the ultimate solution is to have special 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. EXAMPLE: A typical mobile just wanting to keep his spouse informed of his whereabouts might want to just use the UNPROTO path of APRS VIA HOME. Then his UI frames will be digipeated by the local HOME node or digi and will also be routed back to HOME by all NET-NODES along his travels. If he also wants to be seen by most HAMS in the areas of his travels, then he sets his path to APRS VIA WIDE,HOME. If he travels through a region that has both DIGIs and NODES, he might choose APRS VIA WIDE,WIDE,HOME. This way any areas with digis would digipeat via WIDE,WIDE and if he gets to an area with nodes which are aware of the path to HOME, then they will forward his packet there. SPECIFIC NOTES FOR APRSdos USERS: NOTE: In APRSdos your maximum reporting period is dependent on the length of your digipath. This is so that at a special event or local area, using direct or one hop, then your net-cycle time is 10 minutes. Two hops is 20 minutes, 3 hops is 30 minutes etc up to the maximum value in your CFIGxxx.APR file. Currently the MaxTime defaults to 30 minutes. WHERE ARE THE DIGIS? Use the MAPS-OVERLAY-DIGIS command to see the location and range of all APRS digis no matter where you are. Please NOTIFY Jeff of dididahdahdidit.com of any new digipeaters so that he can update the original DIGIS.POS file. The DIGIpath page in APRSdos lets you see what digi paths other stations are using and it also marks stations that you can hear direct. Also under the OPS-DIGI command, users can save up to 12 different unique DIGIpeater paths. Users can select any given path that is optimum for their present application with a single key stroke. The MAPS-PLOTS-POWER command will display a range circle around all stations proportional to their power, and antenna. Users can use these plots to estimate what paths, through what stations, might be useful. de WB4APR, Bob