Global Position Reporting

Although the GPS was originally intended for use by the military, in peace time it has given rise to applications that were heretofore limited to science fiction.
APRS Servers

There is currently a nationwide effort to provide the information received by local APRS LANs to the Internet. This is done using APRS servers which provide live APRS traffic to the Internet. By using a simple TELNET client, one can connect to a server and see the information that is being collected throughout the United States. Several APRS servers are available for different operating systems. For Linux users, there are presently two APRS servers available: aprsmon and aprsd.

The aprsmon server can be found at; aprsd can be found at APRS servers allow users to connect and examine remote APRS networks located in several metropolitan areas. The nationwide network of servers is expanding with the ultimate goal of allowing one to locate mobile trackers anywhere in the U.S. To better understand the information provided by these servers, try a TELNET session to any of the addresses listed below. The numeric value after the host name is the port number and is required.

  • 14579 (Northern NJ)

  • 6261 (USA)

  • 14580 (Composite of above)

  • 14579 (Atlanta, GA)

  • 14579 (Southern CA)

  • 10151 (USA Composite)

  • 14579 (Southeast FL)

  • 14579 (San Francisco, CA)

The information returned from these TELNET sessions is real-time raw data that is broadcast by amateur radio operators at intervals from 1 to 30 minutes. The short duration broadcasts (e.g., one minute) are intended for mobile (tracker) applications where there is movement and therefore a need for frequent updates. The longer duration broadcasts (e.g., 30 minutes) are intended for fixed stations (homes) broadcasting their locations. These servers provide packets which include the position of the transmitting station's latitude, longitude and often a brief message about the station. Listing 1 is the output from a typical APRS TELNET session.

Each line of text in Listing 1 is a packet that contains the amateur radio call sign of the source station, the destination address and any repeaters used in the path. For example, in the first packet shown after the login message, W4DUF is broadcasting to all stations in the APRS network. Due to distance limitations (typically a few miles), other local stations along the route, called digipeaters (digital repeaters), are used to extend the distance by repeating the packet. In the example, stations N4TKT-2, WIDE and N4NEQ-2 are being used to repeat the packet. In this way, distances can be extended to a large metropolitan area (i.e., a 20 mile radius), as well as across the nation by using special high frequency (HF) digipeaters called GATEs. Due to limited RF bandwidth, broadcasting positions nationally is typically limited to special events such as tracking the Olympic torch as it traveled across the U.S.

Figure 3. APRS WWW Page

With the development of a nationwide APRS backbone using the Internet, transmitting local APRS traffic can bypass the constraints of limited HF bandwidth. An APRS TELNET session as shown in Listing 1 is interesting, but difficult to understand due to the raw format of the information. To better understand the data being presented, graphically formatted web pages are used. These web sites take the raw information and overlay the location of the stations on a map. Figure 3 is an example of a typical APRS web page. The list of web sites below shows real-time or near real-time (delayed 15 minutes) APRS traffic and requires a Java-enabled Net browser.

  • (Entire US)

  • (Southeastern US)

  • (Atlanta, GA)

  • (Southern Florida)

  • (San Francisco, CA)


As we have seen, APRS servers provide raw data, and web browsers can show the information in a graphically interesting and informative manner. However, both are passive applications that require a user.

For many applications, it would be nice to automate the system to perform a specified task automatically. For example, you might wish to be informed by e-mail that the lead float in the Rose Bowl Parade has reached a specific point in the route. Or perhaps you have a mobile tracker and wish to sound an alarm when the tracker reaches a specific location. For this application, you need a program that will examine the raw APRS data and execute a command based on user-specified criteria. This is exactly what PerlAPRS does, and Linux is the perfect platform for this type of application since it supports multitasking so well.

PerlAPRS examines incoming packets and executes a command when a call sign and location match the criteria specified by the user. Location criteria is specified using grid squares, a rectangular area measuring approximately 2.5 by 5 miles.

The best way to understand how PerlAPRS works is to look at an example. The line numbers shown in the left-hand column below are provided for illustrative purposes and are not part of the normal output. Line 1 shows an example packet. PerlAPRS parses the packet and extracts the call sign, latitude and longitude. Line 2 displays the call sign as KD6AZU, the latitude as 3243.700 (32 degrees, 43.700 minutes North) and the longitude as 11707.700 (117 degrees, 7.700 minutes West). Next, PerlAPRS searches a call sign file, previously customized by the user, looking for a match. The first two attempts at a match shown on lines 3 and 4 fail. The third comparison shown on lines 5 and 6 is successful. This match causes the command,, to be executed. The command may be any UNIX-style command; however, simple shell scripts are used for most applications.

1. Packet= KD6AZU>APRS,KD4DLT-7,N4NEQ-2,WIDE*:
2.  KD6AZU 3243.700 11707.700
3. - KI6MP-10 DM12JV
4. - KC6VVT-9 DM12IT
5. * KD6AZU DM12KR Sun Aug 10 15:56:13 1997 3
6.     Sun Aug 10 15:57:13 1997 1

This brief discussion of PerlAPRS is intended to provide a simple overview. The program provides several additional features intended for real time applications. PerlAPRS is distributed under the GNU licensing agreement. The source code and further information on the program can be found at


Geek Guide
The DevOps Toolbox

Tools and Technologies for Scale and Reliability
by Linux Journal Editor Bill Childers

Get your free copy today

Sponsored by IBM

Upcoming Webinar
8 Signs You're Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
11am CDT, April 29th
Moderated by Linux Journal Contributor Mike Diehl

Sign up now

Sponsored by Skybot