Page locked

This page is currently locked for editing by another user. You have to wait until this user finishes editing or the lock expires.
Currently locked by: 216.73.216.116,10.2.128.158
Lock expires at: 2025/06/26 06:12 (11 min)
This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
=====  Some APRS-IS UNPROTO Paths Explained =====


APRSS AX25 UNPROTO paths are kind of old fashioned for us Intenet experts. Source routing is so - 1990. But this is the way it is, AX25 is a widely accepted (non)standard, and, if everybody did it the same way, what fun would that be?

I liked to browse the routings on the raw APRS data that shows up on FINDU, but couldn't find a central source of information about what it all meant. Finally with the aid of some elmers like KE6AFE and xxxx, I was able to get it down. Here is some info, along with the sources if I scarfed it form somewhere else. If you see any errors, or have suggestions, please send email to me at .

My main question was, "Why is WIDE1-1,WIDE2-1 better than WIDE2-2?" The answer has to do with the use of neighborhood "fill-in" digis. These digis should be set only to accept WIDE1-1 packets. This prevents them from digipeating packets heard from wide area digis. If your tracker is set to WIDE2-2, your packets will not be picked up by a properly set up fill-in digi. With your path set to WIDE1-1,WIDE2-1, you will be picked up by the fill-ins, as well as the wide area digis, which also accept WIDE1-1 paths.

Here is a reasonably good explanation of more aspects of this "new paradigm": http://www.nwaprs.info/mobilesettings.htm . Here are some examples. You might be interested in seeing some typical paths from my three APRS callsigns.
Tracker position report

KF6IIU-1>APT311,W6CX-3*,WIDE2-1,qAR,KG6WTF-10:/041824z3753.33N/12206.49W1132/003/A=000347

Let's treat this as a canonical APRS packet. There are two parts, the path and the APRS data payload.

APRS Payload: This is everything beyond the ":" (/041824z3753.33N/12206.49W1132/003/A=000347). Without getting into the APRS spec, this is the postition report.

Path: This is everything before the ":" (KF6IIU-1>APT311,W6CX-3*,WIDE2-1,qAR,KG6WTF-10). Commas and the ">" character delimit this information. There are 6 fields here:

# KF6IIU-1 - This is the SSID where the packet originated. This field remains constant for the life of the packet, is always first, and is set by the operator using whatever software created the packet.

# APT311 - This is the "destination field". This field also originates in the software used to create the packet. [Is it ever changed when releated?] The "APT311" signifies that this packet originated in a TinyTrak 3+ (v 3.1.1) tracker. For APRS, this field will always start with "AP", unless the packet is Mic-E encoded. Digipeaters, Igates, and other software can be configured to filter packets based on the contents of this field, and APRS packets that don't have a destination field that start with "AP", or that are not Mic-E encoded, may be dropped. For packet to a specific station, this field will [may?] contain the callsign of a station, like ARISS for a packet that's trying to relay thorugh the ISS. [What are the different strings used by different devices in this field? TABLE] If the packet is encoded using Mic-E, the field contains the current postition, and will change as the sender's position changes. The APRS spec has the description of how Mic-E data is encoded.

# W6CX-3* - This field is the callsign of the first digi to pick up the packet, followed by a "*" to indicate that the packet was successfully digipeated. W6CX-3 is a big mountaintop digi, and is the one closest to my house and thus one of the sites most likely to pick up my packets.

# WIDE2-1 - This is the remainder of the orignal packet's path after being processed by W6CX-3. In this packet's case, the UIPROTO path was orignally the canonical "WIDE1-1,WIDE2-1". W6CX-3 chopped off the WIDE1-1 part, or more correctly, substituted its own callsign for that part, and then sent the packet on its way. This so-call "WIDEn-N paradigm" is the one most commonly in use in North America, and many digi's will only repeat packets using this paradigm. We'll look at some other paradigms later.

# qAR - This is the "Q-contruct" denoting that the packet was then successfully Igated to APRS-IS ("the internet"). This particular Q-construct is inserted in the packet by the Igate, in this case qAR means the packet was received directly via a verified connection from an IGate using the ,I construct.

# KG6WTF-10 - The SSID following the qAR is the SSID of the IGate.

For more information on the Q-construct see http://www.aprs-is.net/q.htm
Weather record

KF6IIU>APRS,TCPIP*,qAC,T2SOCAL:@131732z3753.34N/12206.50W_284/000g000t049r000p024h98b10199XRSW Again, analyzing the path from left to right:

# KF6IIU - This packet was sent from my weather computer using the SSID "KF6IIU".

# TCPIP* - This field is inserted by my weather computer [?] and shows that the packet is to be routed to APRS-IS ("The Internet") directly, not by RF but by a direct login. [Who put the * in - APRS-IS or me?]

# qAC - A Q-contruct signifying the packet cacket was received from the client directly via a verified connection (FROMCALL=login).

# T2SOCAL: The callSSID following the qAC is the server's callsign-SSID. I have an "account" on this server, socal2.aprs.net [?], with a username and password. We will ignore the originating SSID to the left of the ">" from now on. This is always the SSID of the originating station.
Home station

KF6IIU-2>APU25N,WARD,MTOSO-2,WIDE2*,qAo,K6TJS:>130511zDX: K6FGA-1 39.14.74N 120.57.91W 112.2 miles 33? 21:11

# APU25N - This destination field signifies tha the packet originated with the program UIView32. [What changes it from "APRS" to "APU25N"?] This packet happens to be an APRS status packet.

# WARD - My packet was picked up by the Ward Mtn digi way up near Squaw Valley near Lake Tahoe. Not bad for 6 W! I was using WIDE2-2 as my path, so WARD substituted its own callsign for my WIDE2-2 and replaced it with the decremented path WARD,WIDE2-1 when it rebroadcast it. [Or WARD,WIDE2-1*?]

# MTOSO-2 - My packet from WARD was then processed by the digi on Mt Oso south or Tracy. It's possible MTOSO-2 received my original packet, but there's no way to know for sure since an APRS client will usually filter out packets sent to itself [?] and APRS-IS will only keep one copy, randomly selected, of duplicate packets it receives. Occasionally, you will see the same packet twice on APRS-IS if a second digi delays its retransmission for a second or two.

# WIDE2* - MTOSO-2 decremented the WIDE2-1 it got from WARD and substituted WIDE2* to show that the path had been completed. It rebroadcast the packet one last time.

# qAo,K6TJS - This Q-construct says K6TJS down near Los Banos received my packet and Igated it via a client-only port [def?], the FROMCALL does not match the login, and the packet contains either a ,I or qAR construct where the indicated IGate matches the login. I.E The Igate is using a login, but it's different from the IGate's SSID.

KF6IIU-2>APU25N,WIDE2-2,qAR,K6TPK-7:=3753.33N/12206.49W2 {UIV32N}

# APU25N - Here's another packet from UIView32.

# WIDE2-2 - This packet never went through a digipeater. There is no "*",no digi callsign, and the path was never decremented.

# qAR,K6TPK-7 - Instead, my packet was received by K6TPK, a neighborhood "fill-in" Igate about 9 miles LOS from my QTH. Most of the time, it's K6TPK who gets my packets and beat everyone else Igating them. Even though W6CX-3 is closer, and in the other direction, it's not am Igate, and it's big, very busy mountaintop digi. This is an illustration of why big, busy mountaintop digis aren't a panacea, even when everyone behaves themselves. APPS would be so much more efficient if there were little neighborhood digis and Igates everywhere, and everyone used only a few watts of power.
More later!