[aprssig] Re: what is RELAY, WIDE, TRACE, etc?

[Stephen H. Smith]

 > >Is there some documentation (book, URL, etc) that describes APRS
 > >digipeating?  Google gets me bits and pieces, but I can't find
 > thewhole picture anywhere.

Once again, a reprint of my essay on APRS digipeating:

======== PASTE =========

Some background and information on APRS digipeating and path selection.


Digpeating is much more critical to APRS than to conventional packet 
because APRS heavily involves packet data transmission to and from 
moving vehicles.  [ Traditional packet was overwhemingly used between 
fixed locations, typically with better antennas and more power.]

*** WHY DIGIPEATING IS MORE ESSENTIAL ***

Signal levels that you may consider adequate on voice WON'T BE on 
packet, because data transmission is an all-or-nothing proposition. 
--ALL-- of a packet has to be received PERFECTLY to recover --ANY-- data 
from it.  The kind of noisy, scratchy, not-completely-hard-quieted, 
operation so many people inflict on voice repeaters, especially with 
underpowered handhelds,  JUST WONT WORK on data transmissions.   A pop, 
a momentary burst of white noise, flutter, or multipath-induced phase 
distortion that you don't even notice on voice WILL be fatal to a packet 
transmission.

With APRS, the problem is even worse than with conventional [connected] 
packet because it operates in a non-connected mode.  With traditional 
packet, a station receiving a defective packet will automatically send a 
request for retransmission to the sending station (or the sending 
station will automatically retry if the receiving station doesn't 
acknowledge in a reasonable time).  With APRS there is no ACK/NAK 
(Negative AcKnowledgement) handshaking process.  The sending station 
just blasts out packets at intervals and "hopes" the receiving 
station(s) get them.   The receiving station just ignores the packet if 
it is defective in anyway.   [ This is the price you pay for the 
one-to-many broadcast nature of APRS, compared to the one-on-one nature 
of traditional connected packet. ]

Signals to/from mobile units can and do fluctuate in strength by 15-20 
dB as the mobile moves over even a short distance.  For reliable data 
transmission, you must have massively excess signal strength over the 
intended path.  Enough excess signal that even with a 20dB drop, the 
signal will remain noiseless and hard quieted.  [ Note that the 
instruction manual for the Kenwood D700 acknowleges this fact by stating 
that you can't expect reliable packet operation until the S-meter reads 
full scale. ]

{{ FUNDAMENTAL UNAVOIDABLE FACT OF PACKET LIFE:   Roughly speaking, a 
given antenna installation and transmitter power will produce about 1/2 
to 1/3 the RELIABLE range on APRS packet that it produces on FM voice. }}


*** APRS DIGIPEATER USAGE ***

To increase the reliability of transmission from mobile units (i.e. 
likelyhood that a packet will "get through"), APRS uses two categories 
of digipeaters:

1)  "Public" digipeaters in high locations (typically hilltops, the 
tallest building in town, water towers, etc); i.e. similar to the 
placement one would choose for a voice repeater.  This type reponds to 
the alias callsign of "WIDE" .

2)  Personal home stations typically running digipeater duty alongside 
other activities (such as being an APRS client and/or Internet gateway). 
  This type responds to the alias callsign "RELAY".

The assumption is that there are far more home stations then wide-area 
digis.  Therefore a mobile is far more likely to be heard by a nearby 
home station than by a much more distant WIDE.
      On the other hand, even a minimal home station is likely to have a 
better and higher antenna system than anything on a mobile.  Thus the 
home station's liklyhood of successfully transmitting to even a fairly 
distant WIDE is much greater than a mobile's.  This is especially true 
for an area situated in a geographic low spot, or "urban canyons"  where 
mobiles have trouble "getting out".


*** How APRS PATHS ARE USED ***

PATH settings determine what kind and how many digipeaters will be used 
to deliver your packets to their destination. Typically the 
"destination" will be either other stations listening on RF, or a fixed 
station that will receive your packet and transfer it into the Internet 
and then onward to findu.com.

A transmission path of "RELAY, WIDE" is requesting the helping hand of 
nearby cooperating home stations as the first step into the APRS 
network.  [ Normally, WIDE digipeaters will also respond to the alias 
"RELAY" so if a WIDE hears you directly, it can also serve as the first 
hop. ]

If you want multiple digipeat hops, you specify something like "RELAY, 
WIDE, WIDE".  As in conventional packet, each digipeater in the chain 
"crosses off" the callsign it responded to. This example shows results 
as a user tries to use three wide area digipeaters in sucession.  The 
path string will change like this as the packet propagates from digi to 
digi:

   RELAY,WIDE,WIDE,WIDE  {as sent by the user }

  *RELAY,WIDE,WIDE,WIDE  {after home station first digipeat}

  *RELAY,*WIDE,WIDE,WIDE {after first WIDE digipeat}

  *RELAY,*WIDE,*WIDE,WIDE {after second WIDE digipeat)

  *RELAY,*WIDE,*WIDE,*WIDE {after third WIDE digipeat)



The path is now "used up" and no further digis will repeat this packet. 
  This kind of path will work with any kind of TNC pressed into duty as 
digipeaters.  Note that the hops listed in a path are processed 
SEQUENTIALLY, not in parallel!  If you start a path with "RELAY" in an 
area where digipeaters ignore RELAY completely (such as in Southern 
California) you won't get digipeated at all, no matter what callsigns 
are in the following positions!

Because all APRS digipeaters use the same generic callsigns, the 
re-transmission process can happen in several geographic directions 
simultaneously if several digis are within range of the one 
transmitting.  A widening circle of digipeats involving more and more 
digis on each hop will spread outward from the user in all directions. 
This phenomenon, known as "UI-FLOOD", is sharply different from the 
directed linear sequence of digis, each identified by a unique callsign, 
used in traditional connected packet.

If you know them, you CAN use explict callsigns in APRS paths instead of 
the generic WIDE. This is one approach to reducing unneccessary 
retransmissions, especially in your home territory where you likely will 
know the actual callsigns of local digis.

In order to shorten the path strings to allow more packets per minute , 
APRS introduced a new convention.  You add a fake "SSID" to the WIDE 
"callsign" in the path, indicating the number of hops desired.  Each 
digipeater that processes the packet decrements the value of the "SSID" 
but doesn't cross it off as "used up".  When the SSID decrements to 
zero, further digipeating stops.     This type of "WIDEn-N" digipeating 
path looks like this for the example above:

    RELAY,WIDE3-3   {as the user transmitted it]

   *RELAY,WIDE3-3   {after home station RELAY digipeat}

   *RELAY,WIDE3-2   {after first WIDE digpeat - note WIDE IS NOT crossed 
off, just changed}

   *RELAY,WIDE3-1   {after second WIDE digipeat - WIDE still not crossed 
off}

   *RELAY,WIDE3    {after third WIDE digipeat -- all used up, no more 
digipeats}

Note that the path string is half the length of the one before

Sometimes you may want to know what actual digis a signal passed 
through. The generic callsigns conceal the identity of individual 
digipeaters.  To see the actual callsigns, you substitute the callsign 
"TRACE" for "WIDE" Now, each digi will insert it's own (real) callsign 
in the path before forwarding it.  The example now looks like this:

   RELAY,TRACE3-3    {as the user transmitted it]

   *RELAY,TRACE3-3   {after first RELAY digipeat}

   *RELAY,*digicall1,TRACE3-2   {after first WIDE digpeat}

   *RELAY,*digicall1,*digicall2,TRACE3-1   {after second WIDE digipeat}

   *RELAY,*digicall1,*digicall2,*digicall3,TRACE3
         {after third WIDE digipeat -- all used up, no more digipeats}

Note that the path string gets longer after each digipeat. Normally, 
TRACE is only used for testing and discovering the APRS environment in a 
given location; not for routine use.

[ Acually I have simplified the path examples for purposes of 
discussion. In reality, the very first digi (but no subsequent ones) is 
supposed to insert it's own real callsign (marked as used) into the path 
in front of the WIDEn-N phrase, before forwarding it.  This allows users 
many WIDEn-N digi hops away to determine the general location the packet 
originated from. ]

Note that these advanced paths require that the "callsign" actually be 
changed by each digi that processes it. This process of "callsign 
substitution" is unique to APRS and requires special APRS awareness in 
TNCs.  Currently only the Kantronics KPC3+/KPC9612+, and TNC2 clones 
with UI-DIGI firmware, can do this "standalone" without a computer 
attached).

Increasingly, as APRS grows, WIDEn-N digipeating is becoming the 
standard everywhere.  However, some areas are still covered by older 
"dumb" digis using pre-APRS-aware TNCs. [Any 20-year-old junker-clunker 
hand-me-down TNC can do a simple RELAY or WIDE digipeat if it's 
"myalias" callsign is set to "RELAY" or "WIDE". ] In these areas, you 
will be forced to use the longer, less-efficient WIDE,WIDE,WIDE type of 
path.

As a traveler outside of your home area, you may not know whether WIDE 
or WIDEn-N digipeating is in use in a given area.  This is especially 
true of simple trackers that transmit but don't receive -- you have no 
way of monitoring what the locals are using.  Even if you do know, you 
may not have the means (computer and configuration program) with you, to 
reprogram your tracker to the correct path.

A good compromise path for travelers into "terra incognita" is RELAY, 
WIDE, WIDE2-2.  In areas with dumb digis you will get two hops - dumb 
digis will ignore the "callsign" WIDE2-2.   In areas with smart WIDEn-N 
digis, you get up to 4 hops - smart digis WILL normally respond to the 
non-SSID'ed "WIDE" as well as to WIDEn-N.

Some other considerations:

1) Normally, you would never put more than one "RELAY" in a path.

2) --NEVER-- put RELAY in a path after WIDE.  If you do this, dozens (or 
hundreds) of home stations within earshot of one or more WIDEs will 
needlessly clog the channel retransmitting the WIDE's packets for no reason.

3) Paths longer than about WIDE4-4 are almost totally useless. The 
probability of success goes down exponentially as the area covered by 
the transmission expands outward, and the packet is exposed to more 
possiblities of random collisions with users in distant areas.  On the 
other hand, you can create literally thousands of useless packets for 
every transmission, as the UI-FLOOD spreads outward over hundreds of 
miles.   Indeed, in some areas, intelligent digipeaters are 
automatically reformatting excessivly long paths to something more 
reasonable such as WIDE2-2 or WIDE3-3.








WA8LMF (at) aol.com