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 <bruninga@nadn.navy.mil>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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
