APRS Digipeating and Path Selection 101

This discussion starts by describing the traditional APRS path conventions now considered obsolete. This makes the reasons behind the  "New Paradigm" shift to exclusively WideN-n type paths (that do away with RELAY and plain WIDE), easier to understand.

The primary reason for the shift is that stand-alone digipeaters based on Kantronics KPC3+ TNCs effectively suppress duplicate transmissions based on N-n type paths but DON'T duplicate-filter on WIDE or RELAY. The original conventions were established decades ago. Today, there is so much traffic on APRS that channel congestion generated by needless duplicate packets generated by stupid digipeaters is a major problem. 

Jump To Today's Recommended Path Settings
(Lower Down On This Page)

*** WHY DIGIPEATING IS REQUIRED ***

"Digipeater" is short for "Digital Repeater"; a repeater for packet data rather than voice. Unlike the standard voice repeater that receives on one frequency and retransmits what it hears simultaneously on another frequency, the usual digipeater is a single frequency device.   It receives a packet of data, stores it in internal memory and then a moment later retransmits it on the SAME frequency. 

The implication of this is profound.  Every transmission made on the channel occupies not just the time the original user took to send it, but two, three or more additional time slots depending on the number of digipeater "hops" (retransmissions) requested since digipeating is sequential, not simultaneous.  Using just one digipeater cuts the channel capacity (the number of users that can be accommodated per hour in a given area) in half! The indiscriminate use of three, four or more digipeater hops can reduce the channel capacity 75 percent or more. 

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 overwhelmingly used between fixed locations, typically with better antennas and more power.] 

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 marginal, noisy, scratchy, not-completely-hard-quieted, signals so many people inflict on voice repeaters 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 error-free. 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 acknowledges this fact by stating that you can't expect reliable packet operation until the S-meter reads full scale. ] 

*** TRADITIONAL (Now Obsolete) APRS DIGIPEATER USAGE ***

To increase the reliability of transmission from mobile units (i.e. likelihood 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 responded to the alias call sign 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 traditionally responded to the alias call sign "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 (and has the considerable advantage of not being in motion). The home station's probability of successfully transmitting to even a fairly distant WIDE is much greater than the probability of a mobile reaching a WIDE directly. This is especially true for an area situated in a geographic low spot, or in "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 on RF and transfer it into the Internet (an Internet Gateway station a.k.a. "Igate").   Once packets enter the Internet, they are captured by an extensive world-wide network of interconnected APRS servers. In turn public websites like findu.com & aprs.fi -and- other other APRS users are connected to these servers instead of (or in addition to) a radio. 

The now-obsolete transmission path of "RELAY, WIDE" was requesting the helping hand of nearby cooperating home stations as the first step into the APRS network. [ Normally, WIDE digipeaters would also respond to the alias "RELAY" so if a WIDE heard you directly, it could also serve as the first hop. This path then requested any and all high-level WIDE digpeater(s) that heard the home station to retransmit the packet a second time over a larger area. ] 

If you want multiple digipeater hops, you specified something like "RELAY, WIDE, WIDE". As in conventional packet, each digipeater in the chain "crosses off" the call sign it responded to. The example below shows results as a user tried to use three wide area digipeaters in succession. The path string will change like this as the packet propagates from digi to digi 

[Most packet software shows a "used up" or "crossed off" hop in a path by appending an asterisk to the "callsign".] 

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 a digipeater. 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 any area supporting the current "New Paradigm" N-n-only paths) you won't get digipeated at all, no matter what call signs are in the following positions!

Because all APRS digipeaters use the same generic "call signs", the re-transmission process can happen in several geographic directions simultaneously if several more digipeaters 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 flooding, is sharply different from the directed linear sequence of digis, each identified by a unique call sign, used in traditional connected packet. 

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

In order to shorten the path strings to allow more packets per minute , APRS introduced a new convention to the existing AX-25 packet standard. A fake "SSID" was added to the WIDE "call sign" 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. An example of this kind of path is "WIDE3-3" .

• To conventional, non-APRS-aware packet software and TNCs, this kind of path appears to be a "call sign" of "WIDE2" with an SSID of "-2". 
   
• To current APRS-aware TNCs and software, this is interpreted differently (as instructions for multiple digipeater hops) as shown below.

Note that the path string is half the length of the one before for exactly the same results.

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

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. In some areas, it is being phased out completely as part of the shift to the "New Paradigm" path settings described below.

Actually I have simplified the path examples for purposes of discussion. In reality, the very first WIDEn-N digi (but no subsequent ones) is supposed to automatically insert it's own real call sign (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 where the packet originated.

Note that these advanced paths require that the "call sign" actually be changed by each digi that processes it. This process of "call sign substitution" is unique to APRS and requires special APRS awareness in TNCs. Currently only the Kantronics KPC3+/KPC9612+, SV2AGW uTNC, the TNC-X with it's piggyback digipeater add-on board, and TNC2 clones equipped with UI-DIGI firmware, can do this "standalone" without a computer's  assistance.  The thousands of AEA/Timewave TNCs such as PK-12s, PK-88s and PK-232s that turn up in considerable quantities at hamfests CANNOT be updated to do callsign substitution.

As APRS grows, WIDEn-N digipeating, because of it's superior duplicate transmission suppression, has become the standard nearly 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" call sign 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. 

*** THE "New Paradigm":   Changes In Path Settings ***

The discussion above describes APRS paths as they were defined decades ago. With the increasing popularity of APRS, channel congestion increased dramatically.  Much of this congestion is caused by unnecessary duplicate packets generated by WIDE digipeaters hearing and re-transmitting their own packets after they have been transmitted by a neighboring digipeater.  Packets with paths like RELAY,WIDE,WIDE or RELAY,WIDE2-2 would ping-pong back and forth between pairs of adjacent digipeaters repeatedly, creating numerous additional transmissions for every original made by a user. Additionally, users that failed to understand the limitations of a shared 1200-baud channel were abusing the channel by placing paths like WIDE4-4, WIDE5-5 or higher in their transmissions. 

A large proportion of all the digipeaters in the U.S. use Kantronics KPC3+ TNCs.  These TNCs have internal software that can detect duplicate packets and avoid retransmitting them, but only if the path is a WIDEn-N path.  They will stupidly retransmit plain WIDE or RELAY repeatedly.   

In late 2004 and early 2005, an entirely new path convention was introduced to address this problem.  The "New Paradigm" path convention completely discontinues the use of "RELAY" and "WIDE", and exclusively uses WIDEn-N-type paths. Furthermore, many digipeaters are now set to ignore (or truncate) paths greater than WIDE2-2. This greatly reduces channel congestion caused by duplicate packets generated by dumb "RELAY" and "WIDE" digipeaters, and stops out-of-area QRM from distant clueless channel abusers.

The problem that arose is that since high-level digipeaters no longer respond to "RELAY", users have the dilemma of whether to:

1. Place "RELAY" in the first hop of their paths to take advantage of home stations which guarantees that they won't go anywhere if no home station hears them first, even if a WIDEn-N high-level digi is nearby. 
   
2. Use only WIDE2-2 or WIDE3-3 in their paths which will be acted on by high-level digis, but forfeits the possible help of nearby home stations. 

The solution was to turn home stations into "fake" WIDEn-Ns also. The replacement alias for the home station fill-in RELAY is now WIDE1-1 . (To enable it, you just place "WIDE1-1" into MYALIAS of the home station TNC or software instead of "RELAY") The home station digi typically isn't smart enough to understand how to decrement WIDEn-N. It will simply process it as a callsign of "WIDE1" with an SSID of "-1".  It will "use it up"  and mark it as used in one hop, no matter what number is in the SSID. 

By placing two WIDEn-N statements in series in the path, you allow a simple home station "new relay" to "eat" the first hop while leaving the second n-N hop(s) for "real" WIDEn-N digis to properly process and decrement.  However, WIDE1-1 will also work with a real WIDEn-N, if it happens to be the first digi to hear a station. 

In areas without home station fill-in digipeaters, a "real" WIDEn-N digi will act on the first hop and decrement it to zero (WIDE1-0) which shows on-the-air as " WIDE1* " . By contrast  a dumb home station will retransmit the packet as " WIDE1-1* "; i.e. not N-n decremented but still marked as used.  The next digi to hear the packet will act on the second hop WIDE2-2 and transmit it decremented to WIDE2-1. The third digi, if any, will transmit the packet decremented to to WIDE2-0 . (actually shows as "WIDE2*" ). No further digipeating will occur.

Thus the life of this packet looks like this:

Note that simply placing a single "WIDE3-3" in the path won't work, if a home-station fill-in hears the packet first. The home station: a) only responds to WIDE1-1, and b) isn't sophisticated enough to decrement N-n if it did respond to it. If the home station was set to respond to an alias of "WIDE3-3", it would simply retransmit the packet as WIDE3-3* (marked as "used up"), thereby preventing any subsequent high-level digis from ever re-transmitting it. 

Thus the "double WIDEn-N" path is universal, able to take advantage of either a "dumb" home fill-in "WIDE1-1" digi or a smart high-level N-n digi on the first hop, --AND-- smart N-n digis on the subsequent hops. 

Some other considerations

1. NEVER put WIDE1-1 in a path anywhere but the first position of a new standard path.  (I.e. never after WIDE2-1, etc.) If you do this, dozens (or hundreds) of home stations within earshot of one or more WIDEs will needlessly clog the channel retransmitting the WIDEn-N's packets for no reason.
   
2. Paths longer than about WIDE3-3 are almost completely useless. The probability of success goes down exponentially as the area covered by the transmission expands outward, and the packet is exposed to more possibilities 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 in every direction. In many areas, intelligent digipeaters are now automatically reformatting excessively long or abusive paths to something more reasonable such as WIDE2-2 or WIDE3-3. (Or simply ignoring anything over WIDE2-2 entirely). 

Some miscellaneous questions and comments from Internet mailing list posts:

In a message dated 5/11/2003 8:26:55 PM Pacific Daylight Time, jwsteven@concentric.net writes:

> I do have a question about gateways and the Internet. I am guessing here,
> that now and then where ever access is available, one of the RELAYs or WIDE
> digis will also direct traffic to the Internet. 

You've got it! Typically Internet gateways ("Igates") are located at home stations since an effective Igate has to have 24/7 Internet access (i.e. cable, DSL, T1, etc ) which is hard to come by on top of a mountain or water tower. In other words, Igates are not typically co-located with WIDEs (unless they happen to be located in a tall building in a big city where Internet connectivity WOULD be available) All the standard APRS programs for Windows and Linux can perform the Igate function if desired. 

> I haven't thought much
> about how APRS data enters and exits the Internet for that matter. Is
> the traffic logged on a server(s) somewhere and a request to findu retrieves
> it? 

Exactly! The APRS Internet System (a.k.a. "APRS-IS") is a web of multiple servers around the world cross-connected in two tiers that constantly exchange heard data with each other. In turn, thousands of home stations around the world are logged into these servers (the connections are standard Internet Telnet sessions). The local stations feed packets heard off-the-air in their vicinity into the IS (and under some conditions allowing Internet data to go back to RF). 

In turn, Findu.com connects to some of these servers, captures and archives everything the IS hears, and then does huge, fast database queries every time someone hits Findu with a request for a map of a particular station's location. 

It's not just Findu that can use the data flowing through the APRS IS. Any standard Windows or Linux APRS end-user program can connect to any of the Internet servers in addition to (or instead of) your off-air serial-port-interfaced TNC. That is, you can install an APRS program on your office computer, log into one of the APRS servers via your company broadband connection, and play APRS with no radio at all! The full, unfiltered Internet feed representing heard stations all over the world is now a constant non-stop approximately 50-100 KB/sec stream of data. You can not only track mobiles but also send / receive APRS messages to / from mobiles "out there". 

The full feed of the APRS-IS will quickly overwhelm a dialup connection; even a 56K modem isn't fast enough to keep up. Many of the servers now have user-definable "filter" ports that let you specify only certain call prefixes, only stations within a certain distance of a location, only station within a certain distance of a given call sign, etc.  Click Here to see details of the user-definable filter port. This reduces the "firehose" of data to a more managable trickle,

> I have a suspicion that long distance tracking can be rather spotty and
> that I might not show up for long stretches. 

Again, you have correctly grasped the implications of the APRS architecture. Igates tend to be few and far between, outside of the larger cities, and in the less populated and mountainous areas. The southwest WIDE digipeaters in CA, NV, AZ and NM tend to be really really wide since they are on 6000', 7000', 8000' or even higher mountain tops. The trick is to bounce the packet from your mobile through enough (but not too many) digipeaters to finally reach an area where an Igate station is listening. 

Normally, really long-haul over-the-air multihop digipeating is doomed to fail because the probability of packet collisions with local activity in the vicinity of each WIDE. The AZ-NM corridor is a rare exception because of the low population density and correspondingly low level of local activity. In any case, trying to use more than three hops is virtually hopeless. 

Once you leave the densely populated coastal regions on either side of the US, or the southwestern mountains (with their "monster" wides), APRS coverage tends to be spotty islands around mid-sized or larger towns with huge areas of nothing in-between. Of course the Internet APRS server system acts as a "worm hole" that connects these isolated areas. In this respect, APRS-IS behaves in a manner similar to EchoLink, IRLP, etc. 

> NM has an extensive
> mountaintop APRS system mostly on 144.39 now, I think. 

144.390 is THE APRS frequency everywhere in the US and Canada. In Europe, the APRS action takes place on 144.800.  In Australia, 145.175MHz is used.

When you get REALLY out in the boondocks, an alternative is the HF APRS system. Virtually all HF APRS in North America is on 30 meters using 300 baud / 200 Hz shift HF packet format on 10.149.200 / 10.149.400 (actual mark and space freqs). This band is normally open for long-range (500-to-2000 miles) transmission around the clock (and isn't plagued by the massive shortwave broadcast interference that makes 40 meters unusable after dark).   CLICK HERE for details on HF APRS operation.

The 30-meter APRS frequency is mostly populated by unattended Igates that gate transmissions heard to the Internet, and Gateways that retransmit HF activity to 2 meters where it can then find it's way to a normal 2 meter Igate. Normally on HF, you don't digipeat on frequency -- HF propagation is too erratic and unpredictable. The typical path is either:

1. No path at all - You hope to be heard directly by an HF igate station (which is almost certain to happen).
   
2. GATE, WIDE2-2 which tells the receiving HF station to retransmit you onto VHF. This will not prevent you from also being inserted into the Internet System directly from HF by a 30M igate. [The majority of HF gateways are using Kantronics KAM dual-port TNCs which have built-in ability to cross-gate the separate HF and VHF ports. ] This can either amuse or annoy VHF users in systems thousands of miles apart that suddenly start getting position reports from "DX mobiles" on their local 144.390 network. 

NEVER  NEVER  NEVER gate VHF activity the other way to HF!!! HF operates at a mere 300 baud. Even a single moderately active 1200 baud feed from a two meter channel would monopolize the 30M frequency non-stop over half the country! 

Note that all this HF activity is done using SSB, not FM, which means your receiver has to be tuned v-e-e-r-r-r-y precisely (typically within 10 Hz) and stay there indefinitely. Often you are shooting in the dark with no received signals to tune in to verify the frequency. Modern transceivers with 10-Hz resolution digital displays and (often optional) high-stability master oscillators can easily do this, but don't expect the vintage Kenwood TS-820 or Yaesu FT-101 VFO rig to be even remotely usable for this application. 

Note that the TinyTrak Ver 3.1 can do the 300 baud format required for HF, but earlier versions can't. The commercially-built TigerTronics TigerTrak can also do 300 baud HF but it lacks the TinyTrack's speed-sensitive smart beaconing. If you run a laptop mobile, an alternative is a software TNC that uses the sound card through a standard sound card interface (the same kind you would use for RTTY, PSK31, etc) . Both the AGW Packet Engine (freeware) and MixW ($60 registerware) can act as HF 300 baud TNCs entirely in software.