The Automated Packet Reporting Service is a digital real time communications system to share tactical information and messages. The most common activity in APRS is to plot the location of moving objects using GPS information, but APRS can also be used for short messaging, weather station telemetry, announcements, and displaying objects on a map. The power of APRS is its ability to geocode objects and display that information in a meaningful way using mapping technology. So it’s an excellent technology to use for tracking assets: like checkpoints or runners in a marathon, or storm spotters for a SKYWARN activation.
I’m gonna do a few different videos on APRS, this is a big concept and trying to squish everything into one will be quite overwhelming. So to begin with, I’m going to first give you an overview of the system, which includes a brief history, how it works, and equipment for getting started. The purpose is really to get you introduced to APRS, so what I’m going to say will not be overly technical. That will come in a future video.
Brief History of APRS
I’ve been personally involved in APRS since 2000, so much of what I’m going to say is colored by my early experience. Bob Bruninga, WB4APR, is credited as the father and creator of APRS. His early work back in the 1980’s creating object positioning systems developed into a unconnected object mapping system in the early 90’s. Soon GPS technology became available to the consumer market and an automated system was developed. By the mid 90’s a somewhat robust APRS framework had developed. I call it a framework as it took the next decade for APRS to mature. But for APRS to be viable a few things needed to happen, so by the early 2000’s a dedicated APRS VHF frequency had been established. A full time internet gateway developed, and digipeat and path protocols formalized. The sign that APRS was ready for prime time was when radio manufacturers Kenwood and Yaesu released products with APRS functionality. Those wild west days of APRS may be gone, but the Automated Packet Reporting System has become an established, functional, and quite useful mode for amateur radio operators- especially those interested in Emergency Communications.
How APRS Works
So APRS works by transmitting unconnected packets containing a callsign, path, location, and other information. APRS is built on packet radio technology so the transmissions are in AX.25 format at 1200 baud. So you’ll need a device called a TNC or terminal node controller to take digital data and turn it into audio tones that an FM transceiver can transmit. In today’s world this sounds incredibly outdated, but the genius of the system is it’s robust nature.
When I say unconnected, I mean that an APRS packet is transmitted without the expectation that it will be received by another station. Back in the olden days of packet radio you would use your TNC to connect to another station, much like a computer and modem would connect to another computer over the phone lines. So with an unconnected packets of APRS any number of receiving stations can potentially pick up the message and retransmit or digipeat it. This has the potential of conflict and these retransmitted packets can collide over the air, so a method of filtering and packet deprecation built into the digipeater firmware eliminatea duplicate packets. The way an APRS packet’s distance is controlled is by the path information.
APRS Path Protocols
If you ever looked at an APRS packet you probably saw things like WIDE, WIDE1-1, etc. These are the path protocols. The purpose of a digipeater is to listen for a packet and retransmit it. Since digipeaters cover a wide area, they will automatically retransmit a packet with the WIDE designator. So when the digipeater receives the packet marked WIDE, it will take the packet, substitute it’s callsign for WIDE, and retransmit it. Since the generic WIDE term is no longer in the packet and another digipeater won’t retransmit it. The packet now expires. Of course multiple digipeaters could receive the packet and retransmit them but the callsign substitution feature of the protocol prevents that ping pong effect from happening.
Paths like WIDE1-1, or WIDE2-2 work in the same way, except that the 2-2 acts as a counter, extending the packet to multiple digipeaters. WIDE1-1 will go out 1 hop in all directions and WIDE2-2 will go out 2 hops in all directions. You never want to extend your packets out more than 3 hops as each hope introduces more chances for collision. Plus the goal of APRS is not to see how many maps you can light up, but instead travel just far enough for your packet to be picked up by an igate.
An igate listens to the over the air traffic and injects the packets into the APRS internet stream. Igates can also take packets from the stream and retransmit them over the air. This has the benefit of being able to send and receive messages to just about any station heard by the internet stream. With radio and internet technology you can send short messages to just about any APRS station around the world. Also thanks to igates, you can view the local APRS traffic of just about any location.
So how do we view the APRS information? The easiest way to get started is with an website called APRS.fi. APRS.fi transposes APRS packets onto a google map, making it very easy to view and query the APRS datastream. Some features, like messaging, are unavailable, but you can track stations and view their history, which are very useful features.
So you want to get involved in APRS. I think the easiest method is with a handheld radio, Btech APRS-K1 cable, and a smartphone. The APRS cable attaches to the 2-pin connector on the radio and plugs into the audio port on your phone. On your phone you’ll run an app like APRSDroid or APRS Pro Deluxe. The GPS in your phone will provide the location information and the app will emulate a terminal node controller. This setup lets you view and transmit to the local APRS channel and also view the APRS internet stream. Plus as you move the phone will cause the radio to beacon your location. You can purchase the BTech APRS-K1 Cable here.
When I first got started with APRS, I built trackers using mobile radios, gps bricks, and TNCs. The downfall of APRS is the number of cables and connections needed to make the whole thing work. Something always was getting disconnected or stopped working. When I started biking more I wanted to take APRS with me, so I invested in a Yaesu VX-8R handheld. This little radio has both the GPS, TNC, and transceiver all integrated into one package, so there are no cables to worry about. Kenwood also created APRS integrated radios, and it was these devices that actually made APRS a useful protocol.
But the common thread of APRS is the need of a TNC or terminal node controller. Whether you are using a tracker device like a Tinytrack or the Argent Data System, apps like APRSdroid, or a radio like the Kenwood D-710, all are using TNCs of some sort. APRS home stations often rely on a hardware TNC like the Kantronics KPC-3+, or older TNCs like the PK-12 or MFJ 1270. New KPC3+ TNCs have become outrageously expensive, and that value has trickled down to the used market. But there are still deals and you can pick up something like a PK-12, MFj 1270, PK-232 on the used market at a reasonable rate. Usually the key is scoping out hamfests with a keen eye to pick one up before someone else in the know spots it. But once you have your TNC you will be able to use some one of the standalone APRS applications, like the new PinpointAPRS on your shack computer. That will be the topic of our next video.
Did I pique your interest? Do you have questions about APRS or the Automated Packet Reporting System. Please leave them in the comments below. I’ll address them in a future video as I continue this series.