/K5DVT/Projects/APRS
APRS
APRS stands for the "Automatic Packet Reporting System". NOT the "Automatic Position Reporting System". This misnomer comes from the belief that it is for tracking and GPS related position reporting solutions. Yet it is more.
APRS was developed by Bob Bruninga, WB4APR, in the late 1980s. It utilizes TNCs to send and recieve data packets of various information. Many modern radios have built in TNCs and trackers although even "sound card" TNCs can be used with just a computer and a radio. I will attempt to explain at first APRS for someone unfamiliar with it, but this project is more so for the technical side. If you are confused please reach out to be via the contact page.
What is it? Why would I want to use it/contribute?
APRS is a packet mode that
Getting on APRS
I will not cover the numerous different ways one can get on APRS. The point of this post is merely to show what I use it for. If one is intrested in getting on APRS, I suggest using YAAC - Yet Another APRS Client. The old try and true APRSISCE/32 is also a option for Windows users, but since it is no longer getting updates it is approaching obsolescence. YAAC is a Java based client that runs on Windows, Linux, and MacOS. It is also open source and free to use. It's very powerful and allows the novice and expert alike to get on APRS. Here is a video from KM4ACK showing how to set up YAAC with a sound card TNC.
"Paths"
First a little history.
APRS is a band-aid/hack of the older TNC packet digipeater system. First there was keyboard to keyboard packet radio. It was then discovered that a station, say on a hill etc, could store the packets and forward them on.
Keyboard to keyboard was much like FT8 although you could send free form text. In the mid 1980s THE TNC to have was the TNC-2, and later the MFJ clone call the MFJ-1270B/1274 TNC. The manual is well
detailed on early packet operation and you can read it here.
Every packet must have a source and a destination address. If you wanted to do Keyboard to Keyboard with no repeaters, you would put your TNC in "converse" mode. Litterally the command "CONVERS" (sic).
In this mode you would type:
This is a test packet.
To which you would see pop up in the console:
K5DVT>CQ: This is a test packet.
The "CQ" is the destination address, and K5DVT is the sender's callsign. K5DVT is sending a message to CQ. Other TNCs in the converse would see the packet and if they were in "monitor" mode they would see the same message. If they were in "converse" mode they would see the message and could reply to it. But this was simply a "CQ". To call another station, one would type "CONNECT W5NSN". The counsole would like this:
CMD: CONNECT W5NSN
*** CONNECTED to W5NSN
This would then allow to have a packet conversation with W5NSN. A Packet would then look like:
K5DVT>W5NSN: This is a test packet.
So the TNC at W5NSN would see the packet in the air and know it was for it to process. Meanwhile another station, say N5BVA would "see" the packet but ignore it since it was not direct to them. This routing control is important for the next step, digipeating. So let's say two stations want to have a packet conversation but there is a hill in the way. A station on top of the hill can relay the traffic, much like simplex stations relaying a message back and forth. This would look like the following in the consolue:
CMD: CONNECT N5BVA VIA W5NSN
*** CONNECTED N5BVA VIA W5NSN
CMD: Hello BVRC!
N5BVA>K5DVT VIA W5NSN: Hello Jon! ...
This could be "via" multiple hops or station. So you could have a hop of "K5DVT>N5BVA VIA W5NSN,W5YM" which meant that the packet from K5DVT traveled to W5NSN then to W5YM, then finally to N5BVA. As time progressed you can imagine how confusing this could get. One might not know the path to the station or possibly forgot their callsign. The AX.25 protocol allowed for what's called an "Alias" callsign. Think of it as a tatically callsign. "DODD" might be the alias for the Dodd Mountain digipeater. A digipeater at this point is still nothing more than a TNC dedicated to relaying packets more so than the home user utilizing it. So instead of "K5DVT>N5BVA VIA W5NSN,W5YM" you could have "K5DVT>N5BVA VIA DODD". This is much easier to remember and use. The problem with this is that you had to be aware of the path needed to take.
APRS solved this by implementing the "WIDEn-N" Paradigm. This is the band-aid. Bob new that by rethinking the AX.25 packet protocol's use of Alias callsign he could create a universal relay system. APRS would send packets to the Alias of WIDEn-N, that is to say WIDE2-2. If you look closely, the "WIDE2" portion acutally looks like a callsign. For example, this could be K5DVT-2. Digipeaters are none the wiser. The APRS firmware, however, would see the beacon for WIDE2-2 and would know that it can pick it up. How does it know this? More on that later. The digipeater would then add it's callsign to the path and decriment the N portion. For example:
K5DVT>WIDE2-2 .....
Would become
K5DVT>DODD,WIDE2-1
Other digipeaters would hear the WIDE2-1 and know that they too need to digipeat it since a hop (retransmission through a digipeater) is still available. Such a packet might be:
K5DVT>DODD,WHTNHY,WIDE2*
The Asterisk at the end of the callsign (which represents a callsign with no SSID or -(number) portion) indicates to digipeating enabled stations that this packet need not be digipeated. The Firmware also has provisions in place for detecting it's own callsign. This keeps the packet from bouncing back and forth between digipeaters. For example K5DVT portable to Dodd Mt. to Whinty and then digipeated again by Dodd. Since the stations in range of Dodd from the first to the second time it would have digipeated it is so low, the implimented this callsign check so that it would be "one and done". This WIDEn-N paradigm is a simple solution for packet routing management in a decentralized network. Ever heard of Meshtastics? Yeah, welcome to 1987 baby! The callsign need not be WIDE either. In fact the APRS standard specifies the SSn-N service where SS is the two letter identifier for the state that the digipeater is in. For example, ARn-N (more on that below). Although not a standard but special events could have custom paths such as "WALKn-N" for a walkaton.
Here in Arkansas and most the country now, we have a high abundance of digipeaters and I-Gates. Some I-Gates even digipeat. The goal of your packet is to not just make it to the nearest I-Gate and get routed to the internet. You want to have sufficent hops to cover a area of cooperating stations as in theory, some stations at an event may or may not have internet. That being said, the old APRS standard would be 3 hops (so WIDE3-3) but I and a large number of others would recommend WIDE2-2 instead. 2 hops from the digipeaters in Arkansas, high on mountains can get you a signficant ways.
In closing of this section I want to mention RELAY. This still exists in the standard but it's use has been deprecated. Do not use this. Many home stations may not be set as a digipeater, but they might be a RELAY. The idea being if you are mobile in a hole of a large area digi, but can hit a local's house, the RELAY feature would digipeat your packet once This would then be RELAY*. Although what ended up happening is that many people have ended up setting the radio at their house up as a digipeaters, which is improper. WIDEn-N paradigm use should be reserved for dedicated "high profile" digipeaters.