Wednesday, February 18, 2009

APRS -- Brian Daly, WB7OML -- week 39

An Introduction to the Automatic Packet Reporting System (APRS) by Brian Daly, WB7OML


The Automatic Packet Reporting System (, or APRS, was developed by Bob Bruninga, WB4ARP, who is a senior research engineer at the U.S. Naval Academy. Everyone is probably aware that APRS can be used for position tracking of stations, but this is only one of the capabilities APRS has to offer. WB4ARP defines APRS as "a two-way tactical real-time digital communications system between all assets in a network sharing information about everything going on in the local area". APRS allows not only position reporting, but also provides the capability for short messaging, including the ability to send a message to another APRS user, or to provide weather information via APRS. Note that I called APRS the Automatic Packet Reporting System. When GPS started making its way into the mainstream, APRS was called by some the Automatic Position Reporting System - this misnomer really skewed the perception that APRS was about "position only" and did not emphasize that it can be used for other applications. The "correct" name according to WB4ARP is Automatic Packet Reporting System.

Now that I mentioned GPS, let me give a quick overview of how that works - GPS is one component which is used in an APRS system. GPS is a satellite-based navigation system that uses 24 Department of Defense satellites which are in orbit roughly 12,000 miles above earth. Each of these satellites orbit the earth twice a day at roughly 7,000 miles per hour - this orbit is very precise. These satellites transmit a signal down to earth. The GPS receiver uses this information to perform a triangulation to determine the location. The GPS receiver determines the time difference from when the signal is transmitted by the satellite to the time received, which is used to determine the distance to the satellite. If the GPS receiver has time measurements from a few more satellites, thus knowing the distance to each of those satellites, it can triangulate to give the location of the receiver.

The current GPS consists of three major segments - the space segment (SS), a control segment (CS), and a user segment (US). The space segment is the satellites. The control segment is the master control station in Colorado Springs which provides precise tracking information for the satellites. The user segment is the GPS receiver composed of an antenna, tuned to the frequencies transmitted by the satellites, receiver-processors, and a highly-stable clock.

There are several signals transmitted by the satellite - the L1 signal is at 1575.42MHz and is the signal used by civilian receivers. Since this signal is at 1575MHz, signal propagation is by line of site, and will pass through clouds, glass and plastic, but will not go through solid objects such as buildings. The signal has three pieces of information - the pseudorandom code, ephemeris data, and almanac data. The pseudorandom code is simply an I.D. code that identifies which satellite is transmitting information. You can view this number on most GPS unit's satellite page, as it identifies which satellites it is receiving. Ephemeris data tells the GPS receiver where each GPS satellite should be at any time throughout the day. Each satellite transmits ephemeris data showing the orbital information for that satellite and for every other satellite in the system. Almanac data, which is constantly transmitted by each satellite, contains important information about the status of the satellite (healthy or unhealthy), current date and time. This part of the signal is essential for determining a position.

It might seem three satellites are enough to solve for position, since space has three dimensions. However a very small clock error multiplied by the very large speed of light-the speed at which satellite signals propagate-results in a large positional error. The receiver uses a fourth satellite to solve for x, y, z, and t which is used to correct the receiver's clock. Although four satellites are required for normal operation, fewer apply in special cases. If one variable is already known (for example, a ship or plane may have known elevation), a receiver can determine its position using only three satellites. Some GPS receivers may use additional clues or assumptions (such as reusing the last known altitude, dead reckoning, inertial navigation, or including information from the vehicle computer) to give a degraded position when fewer than four satellites are visible.

So given this overview of GPS, how does that apply to APRS? Many GPS receivers have the ability to tap into the GPS data stream and extract position information. This data stream can be fed into a packet data stream over amateur radio, and used by the receiving end to decode and plot on a computer-generated map. If this is done periodically as the amateur radio is moving, a new position report can be sent and plotted on the map. This is thus the position tracking capability of APRS.

So, APRS needs packet radio? Yes! You cannot have APRS without packet. Without going too deep into packet radio operation (that is a subject all to itself!), let's just say APRS requires a Terminal Node Controller (TNC) which will create the AX.25 protocol packets transformed into audio signals for sending on your radio. This TNC can be free-standing, such as the Kantronics KPC-3+, or built into the radio, such as in the Kenwood D7A. In addition, for position reporting, APRS requires the ability to interface your GPS receiver to the TNC to extract the position information and put onto the APRS protocol. The interface is a standard interface defined by the National Marine Electronics Association, or NMEA. Most computer programs that provide real time position information understand and expect data to be in NMEA format. This data includes the complete PVT (position, velocity, time) solution computed by the GPS receiver. If you are looking to build an APRS station, make sure your GPS unit has an NMEA interface.

Virtually all APRS activity takes place at 144.39MHz using 1200 baud packet. To set up an APRS station, an ordinary 2-meter FM transceiver is the primary component. Since APRS uses packet mode, you will need an APRS-compatible TNC to decode APRS traffic on 144.39MHz - this TNC can either be a stand alone, a built-in TNC in your radio, or a sound-card TNC. With this configuration you can monitor APRS traffic. If you want to send APRS traffic, you don't necessarily have to connect a GPS unit to your TNC - you can "hardcode" your latitude/longitude for fixed applications (such as weather stations). However, if you want to do position tracking, then you will need a GPS receiver as well (you can get a basic GPS unit with an NMEA output extremely cheap, especially used).

We are not going to talk about connecting a TNC to your radio or basic packet operation - again, this is an entire lesson in itself!

A typical APRS station will use a Secondary Station ID, or SSID, to distinguish the APRS station from their "normal" station. For example, I have my Kenwood D7A call set to WB7OML-5. SSID is not a requirement but a useful indicator.

The other important APRS component is software. Software is important to display positions of APRS stations as well as getting any additional information that may be included in their transmission, such as weather information. You do not need this software to transmit APRS information. Popular packages are UI-View, FindU, WinAPRS, and MacAPRS, using map programs such as Streets, Street Atlas, or Precision Mapping.

In packet radio, you normally want to send packet data to another station via a digipeater (or multiple digipeaters). For example, I can command my TNC to "connect" my station to W7ACS "via" W7ACS-10 (which is a digipeater in this example), or "via WB7OML-10, W7ACS-10" to indicate multiple digipeaters. However, APRS does not establish "connections" with each other - the packets are sent to no one in particular, but sent to everyone. To allow APRS packets to be repeated by digipeaters, an "alias" convention was established such that APRS users would not have to know which digipeaters to send the APRS packets to. The most common APRS digipeater alias is WIDEn-n where "n" represents a number. The first "n" designates the type of WIDE digipeater that will relay your packets. For example, a WIDE1 digipeater is a limited coverage "fill in". A WIDE2 is for wide coverage. The second "n" is the SSID and is used to provide a means of limiting how often or how far a packet can be repeated; think of this as a count of the number of times your packet will be repeated. There needs to be a limit or else the packets will ping-pong throughout the network over and over, and cause congestion. Each time your packet hits another WIDEn-n digipeater, the digipeater will subtract 1 from the SSID before it retransmits it. If the SSID is zero, it will not be retransmitted.

The suggested setting for a home APRS station is WIDE2-2. If you are in an area where fill-in digipeaters are needed to cover areas that are shadowed from the main digipeater's receiver, a suggested path is WIDE1-1, WIDE2-1. This will provide you with two hops via the RF network. WIDE1-1 will activate the fill-in digipeaters, which will boost you to the main digipeaters. This path asks the fill-in digipeaters for help of the first hop, as well as the main digipeaters, but only the main digipeaters will respond to the second hop. A suggested standard path for a mobile APRS station is WIDE1-1, WIDE2-1. This will provide you with two hops via the RF network. WIDE1-1 will activate the fill-in digipeaters, which will boost you to the main digipeaters. This path asks the fill-in digipeaters for help of the first hop, as well as the main digipeaters, but only the main digipeaters will respond to the second hop.

The other question is how often do you need to transmit? Obviously you don't want to transmit too often or there will be packet collisions with other users on the network. However, for moving stations, you want to transmit often enough to get goods tracking data. Home stations should transmit a position report to WIDE2-2 every 30 minutes. This is usually a default setting when configuring APRS for home use. Home weather stations should transmit a position report to WIDE2-2 every 15 minutes. Mobile stations should transmit a position report depending on the configuration of equipment they are using, to WIDE1-1, WIDE2-1, perhaps 3-5 minutes periodicity should be considered. Typically a shorter path of WIDE1-1 with a periodicity of once every two minutes is acceptable.

As I mentioned earlier, APRS not only is used for sending position information. APRS can send telemetry, short two-way text messages, bulletins, weather data, etc. For two-way text messaging, you can send these to a specific station and also request an acknowledgement.

APRS is another packet application you should consider, especially in emcomm operations. Small self-contained trackers can be obtained at reasonable cost. Examples include the Tiny Trackers from Byonics APRS applications include*:

Immediate local digital and graphical information exchange between all participants in a local area or event. This includes:
  • Positions of all stations and objects
  • Status of all stations
  • Messages, Bulletins and Announcements
  • Weather data and telemetry
  • DF bearings and signal strengths for quick transmitter hunting
  • RF Connectivity plots of all stations
  • Local OBJECTS on a common map display for all users
  • Local Freqs, IRLP, ECHOlink, Winlink, Nets, Meetings
Typical applications are:
  • Routine local awareness of all ham radio events and assets around you
  • Marathons, races, events and public service
  • Search and rescue
  • Family communications and tracking and one-line emails
  • Mobile-to-mobile global text messaging
  • Weather data exchange and display
  • Efficient multi-user Satellite communications
* - from Bob Bruninga, WB4APR

Links for More Information:
WB4APR's APRS Website: http://aprs.org
GPS guide for Beginners: http://www8.garmin.com/manuals/GPSGuideforBeginners_Manual.pdf
UI-View: http://www.ui-view.org/
WinAPRS and MacAPRS: http://www.winaprs.com/
FindU: http://www.findu.com/
Northwest APRS: http://www.nwaprs.info/
Self contained APRS: http://www.byonics.com/, http://www.bigredbee.com/

2 comments:

Anonymous said...

The presentation really peaked my interest for getting this together for testing and use with our next ACS call-out or drill. I found a link to a map for the Pacific NW.

http://wa8lmf.net/APRSmaps/PacificNorthWest.htm

Thanks Brian!

Dale - KE7BSB

Franz said...

Bob Bruninga's correct call sign is WB4APR. It is consistently incorrect in the otherwise very nice article above.