Website Host for:
R.A.C.E.S. | RST Club 

Callsign

APRS Digipeating and Path Selection 101

By Stephen H. Smith WA8LMF

This discussion starts by describing the traditional APRS path conventions now being phased out. This makes the reasons behind the recent "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 dupe filter on WIDE or RELAY. The original conventions were established over a decade 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. 
 

*** WHY DIGIPEATING IS REQUIRED ***

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 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 acknowledges this fact by stating that you can't expect reliable packet operation until the S-meter reads full scale. ]
 

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.
 

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 responds 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 is not constantly moving). Thus the home station's probability 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".
 

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") 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. This path then requests any high-level WIDE digpeater that hears the home station to retransmit the packet a second time over a larger area. ]

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

[ NOTE: Most packet software shows a "used up" or "crossed off" hop in a path by prefixing it with an asterisk. ]

1. RELAY,WIDE,WIDE,WIDE ( as sent by the user )
2. RELAY*,WIDE,WIDE,WIDE ( after home station first digipeat )
3. RELAY*,WIDE*,WIDE,WIDE ( after first WIDE digipeat )
4. RELAY*,WIDE*,WIDE*,WIDE ( after second WIDE digipeat )
5. 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 any area supporting the "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 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-FLOOD", 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".
 

The first number in a N-N type path is the total number of digi hops desired. The second one is the number of hops remaining as the packet is transmitted from a given digipeater.

• 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.

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; the "SSID" 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 for the same net 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: 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. 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 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+, and TNC2 clones equipped with UI-DIGI firmware, can do this "standalone" without a computer attached). 

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 over a decade ago. With the increasing popularity of APRS in the last few years, channel congestion has 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 shared 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 aims to completely phase out "RELAY" and "WIDE", and move exclusively to 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 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 within earshot. 
   
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 place "WIDE1-1" into MYALIAS of the home station instead of "RELAY") The home station digi typically isn't smart enough to understand how to decrement WIDEn-N. It will simply "use it up"  and mark it as used in one hop, no matter what numbers are 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:
 WIDE1-1,WIDE2-2 (as the user transmitted it)
 WIDE1*,WIDE2-2 (as a home fill-in digi or the first high-level 
                 digi transmitted it. 
 WIDE1*,WIDE2-1 (as the next high-level digi transmitted it)
 WIDE1*,WIDE2* (as the final high-level digi transmitted it)

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 isn't sophisticated enough to decrement N-n. It will simply retransmit the packet as WIDE3-3* (marked as "used up"), thereby preventing any subsequent high-level digis from ever repeating 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.
 

Today's recommended universal path settings under the "New Paradigm" are:

1. WIDE1-1, WIDE2-2  Will produce three hops and will take advantage of home fill-in digis. Use in rural areas.
2. WIDE1-1, WIDE2-1  Will produce two hops and will take advantage of home fill-in digis. Use in busy urban and suburban areas.
3. WIDE2-2 Shortest path string. Produces two hops by directly using two high-level digis. Will work almost anywhere but especially recommended in the American west where high-level digipeaters are really high-level; i.e. on mountain tops thousands of feet above the users, and can easily be reached directly without the help of home stations.

Some other considerations

1. If you are in an area that still uses "RELAY" never put more than one "RELAY" in a path.
   
2. --NEVER-- put RELAY in a path after WIDE. [Or WIDE1-1 anywhere except the first position in "New Paradigm" paths] 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 WIDE3-3 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 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 to HF and 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 HF or 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 (aka APRServe aka 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 everytime someone hits Findu with a request for a map.

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 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. 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 useless.

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. 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). A few stations directly operate on this frequency but the frequency is mostly populated by unattended Igates and Gateways that retransmit HF activity to 2 meters where it can then find it's way to a 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 TS-820 or 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, 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.