DIGIS.TXT 6.2b+     AUTOMATIC PACKET REPORTING SYSTEM DIGIPEATERS

VER 6.2b+ ADDED NEW SECTION ON THE WIDE-N GENERIC DIGIPEATER ALGORITHM.
          and also on RELAY-WIDE digipeating

     To satisfy the objective of instantaneous response, APRS stations are
designed to begin operating without any prior knowledge of the network.  For
this reason, all APRS stations are initialized with the digi alias of RELAY
and to send all UI frames via the path of RELAY.  With this form of generic
alias callsign (RELAY) and wildcard digipeating (RELAY), a mobile, or new
station on the air does not have to know anything about the network in advance,
but to simply turn on his computer to be seen by adjacent nodes.  After 10
minutes and his map begins to show the location of all stations and digipeaters
on frequency, he can then customize his outgoing Unproto path to specific
digipeaters to cover his intended area without as much QRM.

    It is important in any APRS network to avoid using the wildcard addressing,
when possible, to minimize unnecessary QRM on frequency.  The D-list command
lets you see what digipeater paths other stations are using and it now also
marks stations that you can hear direct.  Also under the OPS-DIGI command,
users can save up to 13 different DIGIpeater paths.  Then they 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 transmitter power, antenna height above
average terain, and gain.  Users can use these plots to estimate what paths,
through what stations, might be useful.

     Although digipeaters work poorly for AX.25 level 2 connections, they are
ideal for APRS operation using UI frames only.  All along the east coast we
are establishing an APRS network of WIDE area DIGI's on the frequency of
145.79 for mobile position reporting.  The low duty cycle of this mode, also
permits Keyboard QSO's and other UI frame applications.  Even leaving Personal
mail boxes on the frequency is welcome, since mail is posted at keyboard rates
and is read off-the-air by the mailbox owner without QRM.  The normal
CONNECTED operation of BBS's, mail forwarding, file transfers, TCP-IP and
DX clusters are discouraged!

WILDCARD DIGIPEATING:  To make these WIDE area digipeaters respond to mobiles
and new stations, all wide area digipeaters have the same alias of WIDE in
addition to their normal FCC callsign.  The generic alias of WIDE adds
tremendous flexibility to APRS networks by significantly extending the
ranges for wildcard digipeating using well situated permanent digipeaters.
These wide area Digi's are spaced several tens of miles apart so that they
are not too close, but that they can hit their adjacent other WIDE digi's.
Assuming WIDE area digipeaters are about 30 to 50 miles apart it is very easy
to select an UNPROTO path prior to a road trip which will assure that your
location packets will always get back to your home area.  The following
example shows a string of digipeaters along the east coast.  The HAM calls
of SOUTH and NORTH are used for clarity.

CALL:   NORTH-3    NORTH-2    NORTH-1   HOME-0    SOUTH-1   SOUTH-2   SOUTH-3
ALIAS:   WIDE       WIDE       WIDE     RELAY     WIDE      WIDE      WIDE

    If the mobile is going south for the day, and will be operating in the
vicinity of SOUTH-3 digipeater, the operator can preset his UNPROTO path to be
via WIDE,SOUTH-2,WIDE.  Notice that not only will his packets make it back to
home from the area of SOUTH-3, but also from the area of SOUTH-1 since SOUTH-1
will also respond to the first WIDE in the list.  Similarly, stations in the
vicinity of SOUTH-3 are alerted to his movements as he leaves home, since the
WIDE,SOUTH-2,WIDE specification is symetrical.  If he set the UNPROTO path to
SOUTH-3,SOUTH-2,SOUTH-1 in the usual manner, he would not be tracked at his
home until he actually arrived at his destination.  As you can see, having the
flexibility to alternate the generic alias's of RELAY or WIDE with other
known sites gives a good degree of flexibility without having to change the
UNPROTO path while on the road.  Using the three digipeater string, he can
wander up to 150 miles in his planned direction and still be tracked by the
XYL.  If he has no idea where he is going, he can always use the path of
WIDE,WIDE or even WIDE,WIDE,WIDE and go anywhere, but with greater QRM on the
channel.  Yes there are multiple collisions, and repeats, but the packet does
get out to the third tier!  With over a dozen WIDE's now on the air, using
WIDE,WIDE,WIDE should usually be avoided except for special events....


DEDICATED WIDE AREA APRS DIGIPEATER SET UP

   To set up a WIDE area APRS digi, simply connect a TNC to a radio, and put
it as high as you can get it.  Set the following minimum commands:

cmd:   MY W3XYZ-x                 (the digipeater call and SSID)
       MYA WIDE                   (this makes it digipeat WIDE packets)
       UNPROTO APRS VIA WIDE,WIDE (so everyone sees it)
       B E 60                     (Sets Beacon to once every 10 minutes)

       BT !DDMM.mmN/DDDMM.mmW#Pwr5360/WIDE...(identifying comments)...
            |         |      | | ||||  |_____ makes station show up green
            |         |      | | ||||________ Omni (Direction of max gain)
            |         |      | | |||_________ Ant gain in dB
            |         |      | | ||__________ Height = log2(HAAT/10)
           LAT      LONG     | | |___________ Power = SQR(P)
                             | |_____________ Power-Height-Gain PHG indicator
                             |_______________ # is symbol for digipeater

As you can see by the integers in the Pwr 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 Pwr 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      0,45,90,135,180,225,270, 315, 360,   .  deg    D/45  This offsets
                                                   the range circle in the
                                                   indicated direction
                                           
NOTE ABOUT POWER LEVELS:  There is little justification for making a WIDE
area digi run any more power than an average mobile rig.  The function of the
WIDE digipeater is to PICK UP SIGNALS FROM MMOBILES and to relay those posits
to fixed stations.  The mobile is usually at ground level and is using an
omni directional whip.  If his path gets him into the digipeater, then he
should be able to hear it.  Home stations, however, usually run higher
antennas and will easily be able to hear the digipeater.  Both WIDE area
APRS digipeaters that I have installed use only 1 and 5 watt radios.  Running
real high power just adds QRM beyond the effective range of the repeater.
If you are concerned about linking to the next WIDE, forget it.  If your digi
can hear it, then it should be able to hit it with 10 watts!


SETTING UP THE X1J NODES:  You may set up an X1J node to act as a generic
WIDE area APRS digi, depending on whether the ALIAS callsigns are not already
in use.  The X1J permits 5 callsigns.  The first two are the NODE callsign
and the NODE alias.  These pertain to level-4 NODE operation and can NEVER
be made WIDE or you will LOCK-UP the network.  The next three ALIASES are for
a BBS, DXCLUSTER or HOST mode operation.  By enabling one of these extra
aliases to WIDE, then the node will digipeat APRS UI frames as long as the
following commands are also performed:

   PARM / 23 1     Digipeat enable
   MODE / 14 1     Extra alias monitoring enable
   MODE / 17 3     Refuse digipeated L2 node uplinks & downlinks

If you have mobile GPS stations, you may also want to consider setting a
second alias (if available) to RELAY.  See the next section.


OPERATIONS WITH RELAY AND WIDE:

     Until we get new UI forwarding algorithms in standard TNC's, however,
the general aliases of WIDE and RELAY will do nicely.  If fixed, known
digipeaters are available, even with the generic alias of WIDE, it is best
for fixed APRS stations to use the digipeaters unique callsign instead of
alias to avoid any ambiguity.  Also avoiding the wildcard addresses except
when necessary, significantly reduces QRM on the channel.

     APRS now has a special command SETUP-WIDE that sets ones own station to
the ALIAS of WIDE vice RELAY.  This is so that an APRS station that is well
situated, can temporarily serve as a WIDE digipeater.  This special command is
used to override the automatic TNC initialization routine that always sets
APRS TNC's to the generic alias of RELAY.  This command should be used with
caution and with the agreement of all stations on the net.  Too many WIDE's
and too close together causes too much QRM.  The command has to be used each
time APRS is run, since the initialization routine will always reset your
alias to RELAY.  Also, if you use the SETUP-WIDE command, your symbol will be
set as a digipeater and the word WIDE will be installed in your POSIT comment
field so that your station will show up on all screens in green.  This color
(showing you as WIDE) will be lost, however, if you have a weather station
hooked up to COM2, since it re-writes the POSIT string every few minutes.

SEE README.HF for setting up your UNPROTO path for HF and HF/VHF gateways..

RELAY-WIDE DIGIPEATERS:  I am beginning to ask the TNC manufacturers to
include a second alias for UI frames only.  This second alias will be just
like the MYA alias, and will be set up using the MY2ND command.  In an APRS
WIDE area network, this second alias will be set to RELAY.  This way a WIDE
area APRS digi will not only respond to WIDE, but also to RELAY.  This is an
important topological concept, since it ties together the local cellular
(RELAY) concept to the wide area backbone network (WIDES).

     The generic WIDE's should be widely spaced to minimize QRM.  THey are
the long distance backbone of the APRS network.  Wide spacing, however, makes
it difficult to pick up local low power mobiles.  Since every APRS station on
the air, is already serving as a RELAY site, it is very easy for a mobile to
set up his path as RELAY,WIDE.... so that he is picked up by ANY APRS station
and then digipeated into the WIDE network.  The problem is, by setting
RELAY,WIDE...  he can be sitting right under a WIDE digipeater and NOT be
digipeated because there is no nearby RELAY.  If we can get the TNC coders
to add this MY2ND alias and set it to RELAY, then the WIDE area digipeaters
will also perform the local function as well.

     Every APRS commuter begins his commute in the vicinity of his own home
station (RELAY).  In my case, I live too far from a WIDE to be heard, until
I am 1/2 of the way to work (which is 1 mile from a WIDE).  I currently have
installed a small RELAY at my office, so that I can operate mobile via
RELAY,WIDE....  But it would be far better to have the WIDE digi, also
recognize RELAY!.   A refinement would be that the digi ONLY recognize the
MY2ND as the FIRST digi in the string.  This assures that the MY2ND (RELAY)
is only used as an entry point in to the WIDE network, and does not then get
accidently missused by a new user who tries RELAY,RELAY,RELAY....




**********     WIDE-N ALL DIRECTION GENERIC DIGIPEATING!     ****************
          THE ULTIMATE SOLUTION FOR MOBILE POSITION REPORTING

    This may be the simplest mechanism for making an order of magnitude
improvement in APRS status and position reporting networks.  In a WIDE-N
network, each WIDE digi simply repeats ANY packet with the VIA address of
WIDE-N; but ONLY ONCE.  If it keeps a copy of the last 30 seconds of packets,
(or at least a copy of the FCS) and compares each new packet that it hears
with the LAST one that it digipeated, then it could decide NOT TO TRANSMIT
it again!  This would completely eliminate the multiple round-robin
multiplication of packets generated when a mobile station uses the present
generic path of WIDE,WIDE,WIDE.  As it is now, such a 3 tier path launched in
the middle of 3 WIDE digipeaters that all hear each other can generate as many
as  3x3x3 or 27 duplicates in the area.  If each WIDE-N only digipeated the
packet once, then there would only be 3 local copies generated, and the packet
would still propagate outward 3 levels in all directions in the usual manner!
Since this algorithm has uses on ALL amateur packet networks needing a
FLOODing mechanism for special packets of interest to everyone, I am calling
it the FLOOD-N algorithm.  For APRS, however, I will still refer to it as
the WIDE-N algorithm.

NUMBER OF HOPS:  Using the via path of WIDE-N, each DIGI that repeats the
packet decrements the WIDE-SSID by one.  This way, each packet carries along
with it information on how many times it has bounced through the network.
The user specifies how far it goes, by the initial setting of the SSID!
If he sets it to WIDE-7, then the packet could be digipeated as many as
seven times outward.  A local commuter might select WIDE-2 to cover his
area while limiting DX QRM.


NEW TNC COMMANDS REQUIRES:  To make this work, there are three new TNC
commands needed:

     MYFlood:  This command, similar to MYAlias, sets up the callsign at the
     digipeater to be used as the FLOOD-N callsign.  In APRS networks, we
     will use WIDE.  THIS IS FOR UI FRAMES ONLY!  That plus the AGELimit
     below, makes it un-useable for connected frames, and for abuse.

     HOPLimit:  This is a SYSOP parameter that can be used to limit the
     maximum number of HOPS permitted in a network.  Already the maximum
     number of hops is limited to 7, since the upper bit of the SSID is
     reserved for future use.  However, on NON-APRS networks, some SYSOPS may
     feel empowered to limit the maximum number of hops to some smaller number.

     AGELimit:  The WIDE-N digi has to keep a copy of all digipeated packets
     for a brief period for comparison with new packets heard.  This is the
     key to the WIDE-N algorithm.  Every digi that hears a UI packet will
     digipeat it, BUT ONLY ONCE.  To do this, it compares each new packet with
     all packets digipeated in the last X seconds.  This X age-limit needs to
     be a variable depending on the speed of the network.  If the time is too
     long, then the list is big, If it is too short, then there is the chance
     that a packet may propogate in a circle and get repeated again.  My guess
     is that 30 seconds is a good default value for 1200 baud channels.  Howie
     Goldstein, N2WX has improved the effeciency of this idea, by only saving
     and comparing the CHECKSUM of the packets, instead of the whole packet.

     If ALL APRS WIDE area digipeaters changed over to the WIDE-N code, we
would HAVE THE ULTIMATE GENERIC MOBILE GPS NETWORK!  Metropolitan area
commuters could set their digi paths to WIDE-2 and Mobiles on extended trips
within a 200 mile radius of home could be tracked with a path of WIDE-5,
without fear of clogging the network!  This WIDE-N algorithm is so powerful
that it could even be added to ALL TNC's as a FLOOD-N mode.  It would only
work on UI frames and would default to the generic callsign of FLOOD.
That way, on ANY packet frequency, a UI frame launched into the air, could
be seen by EVERYONE!


ADDITIONAL GENERIC ALIAS FOR APRS DIGIPEATERS:

    In the meantime, until we get the WIDE-N algorithm in most TNC's, another
simple solution would be for the TNC to accept a SECOND ALIAS FOR UI FRAME
DIGIPEATING only.  Lets call this the MYA2 command.  With this second UI ALIAS,
an existing APRS WIDE area digipeater could also listen for, and digipeat,
packets sent VIA RELAY.  This is important, since ALL other user APRS stations
are already acting as RELAY digipeaters, but the WIDE's are NOT.  So if a
fringe area mobile initially sets his path via RELAY,WIDE so that his home
station repeats him over to the WIDE digi, once he travels closer to the WIDE,
he will NOT be heard, unless there is another RELAY nearby.  If the WIDE area
digipeater would ALSO repeat the generic RELAY, as well as WIDE, then we
would have a completely homogeneous network.  Mobiles would all set their
paths via RELAY,WIDE,.....  This would assure that they were seen in the
vicinity of thier home QTH, as well as any time they were near another
APRS station!  Setting the home stations to WIDE is NOT a solution, because
then you have just DOUBLED the QRM on frequency, for EVERY packet on the
air!  Having the generic path of RELAY be the first entry into the network
from ANYWHERE avoids the multiplicity of WIDEs, while still providing for
effective WIDE area distribution.


LEVEL FOUR and TheNET CONSIDERATIONS:

     Since NODES are so much smarter than digipeating, the ultimate solution
is to have the NODES do all UI frame routing.  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 (internode, 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!

    The G8BPQ TheNET code for the DataEngine includes a DIGIon command that
can restrict Digipeating to UI frames only.  This is very useful, in that it
allows SYSOPS to leave DIGI ON without inviting LEVEL-3 connects to use it
which is detrimental to normal level-4 operation.  The problem, however, is
that the generic APRS RELAY and WIDE aliases cannot be used on a NODE, since
the digipeat ALIAS is the same as the NODE alias, and you cannot operate more
than one NODE with the same ALIAS on the same frequency or even in the same
network!  We are asking NODES to consider adding a secondary ALIAS for UI
frames only that is not tied to any of the node functions.


DIGI/NODE COMPATIBILITY:  Since the user should not have to change his digi
path as he drives from one area to another, he should be able to specify a
path that is compatible with both nodes and digipeaters.  This is easily
accomplished by assuming that the LAST field in an UNPROTO digi list is the
HOME NODE and should be the ultimate destination for the UI frame through any
level 4 network.  Any and all preceeding fields are assumed to be DIGI's only.
With this arrangement, the user could use an UNPROTO path of APRS VIA WIDE,
HOME so that any generic WIDE digipeaters would repeat his position to their
local area as would any WIDE NODES in the usual digi fashion.  Only the
node that hears the direct packet would also forward it through the network
at level 4 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.  It is important that NODES hearing
digipeated UI frames from other digis do NOT enter the packet into the network,
to eliminate duplication.  Only the ones hearing the direct signal should
be repsonsible for doing the level 4 routing..

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.

     Finally, since I hope to build a regional area Tracking network, the node
should also permit the SYSOP to turn off other level 4 routing if he wants to
make a dedicated network of APRS nodes just for tracking.  Such a network would
be swamped if all of the BBS and other CONNECTED protocol users began to use
it, and the original purpose of the network would be defeated.

   Still, most of these APRS support ideas could be included in all NODES so
that a minimum of APRS tracking could be supported by ALL networks on all
frequencies, especially where there is not yet a dedicated APRS TRACKING
NETWORK.  I think there are other undeveloped applications for shipping UI
frames through ALL networks which have not yet been explored.  The capability
should be there, in any case, so that experimentation can proceed.  Time will
tell.  These few paragraphs were primarily written to the NODE CODE writers
such as John G8BPQ and Mr. Roberts of X1-J.  But are included here in general
distribution for all to read.


