THE AUTOMATIC PACKET REPORTING SYSTEM (APRS)

By Tom Weeden, WJ9H

#3 - Digipeaters and Messages


If you read the April issue of BSSS, you may have seen a short news article about how a Pennsylvania ham made an emergency call using APRS when other communications methods did not work. KC5JGV used a Mic-Encoder, which connects between the microphone and an FM rig to insert a short APRS position and status packet at the end of a voice transmission. KC5JGV's packet alerted several hams to the emergency, who were able to direct the Pennsylvania State Police to the site of the accident. The inner workings of the "Mic-E" is beyond the scope of this month's article, but I wanted to emphasize some of the interesting possibilities of APRS.

Last month, I told you the current version of APRS was v8.30. Bob Bruninga, WB4APR, has been through several revisions and is now up to version 8.38! The latest version is always available for download at the TAPR web site: www.tapr.org. This month we will discuss the use of digipeaters in more detail.

Packet radio in its infancy made broad use of digipeaters to link connected stations together. A digipeater would retransmit a packet if its callsign were part of the path of the originating station. Digis did no error checking, which meant that a corrupted packet could be propagated all the way to the far station, which would then send a request for retransmission. These retries tended to clutter up the frequency. Digipeaters were slowly replaced by networked nodes, which would forward a packet to its destination only after it acknowledged the packet it received. Nodes increased the throughput on the packet frequency to the point where if a station did use a digipeater to connect to someone, it was considered poor operating practice.

APRS is considered a broadcast protocol, where many stations are intended to receive the packet of the sending station. It is impractical to acknowledge all the receipts of a packet at each station, so only <UI> packets are sent.

In order to increase distances beyond simplex range, digipeaters are used. APRS uses generic aliases for digis, the most frequently used being RELAY and WIDE. By default, the APRS software gives each home station an alias of RELAY. A wide-area digipeater usually has an alias of WIDE. If you have begun using APRS, you will notice that the packets sent by your station have an UNPROTO path of VIA RELAY,WIDE. This will allow any nearby home stations to retransmit your packet to get it to a WIDE digipeater for wide-area coverage. (Some WIDEs also have a second alias of RELAY to catch all packets.) Generic aliases are useful for new stations and especially mobiles who are new to an area and have no prior knowledge of the area's available digipeaters.

After you have been receiving packets for awhile, you can press the D key to see the digipeater paths of stations. Using the U (unproto) command, you can modify your path to take advantage of nearby stations. For instance, in the Milwaukee area, there are several wide-area digipeaters on the air on 144.39 MHz. Since all of them have an alias of WIDE, any (and possibly ALL) of them will retransmit your packet with WIDE in its path. To avoid duplication of packets, you can use the U command to put the actual callsign of one of the digipeaters in your path to replace the generic WIDE alias.

You can experiment with multiple digipeaters, such as VIA WIDE,WIDE to get out two digipeaters in all directions. But don't overdo it. Three WIDEs in a row has the potential to generate 27 duplicate packets as each digipeater ping-pongs your message to each other. It is always better to specify the callsign in a path if you know it.

You can find more information on digipeaters in APRS by pressing F1 - F to get a list of help files, then entering DIGIS.TXT and pressing ENTER.

The other topic for this month is sending messages. APRS gives you the ability to send short, one-line messages to a specific station, or short text bulletins to all stations on the frequency. Simply press S (Send). You'll be prompted for the call of the station you want to send to. Next you'll be prompted for a line of text. After entering the text, you'll see the timer window in the upper right hand corner show a new countdown until your next message packet is sent. APRS will continue sending the packet at increasing intervals until the receiving station sends back an acknowledgment packet. (Note that you are still sending <UI> packets and are not actually connected to the other station. The acknowledgment is part of the APRS unconnected protocol. The receiving station must also be running APRS for the ACK to be generated.)

If you don't have a good path to the other station, you can erase the outbound message by pressing E (Erase) and the line number of the message if you sent more than one line of text. If incoming messages are received, you can use the K (Kill) command to erase them as needed.

To send bulletins, use BLN1 as the To: address for the first line, then BLN2, and so on. If your station hears a bulletin packet, a prompt will appear at the top of your screen to press B to see new bulletins. Bulletins are useful to announce meetings, or significant weather events, such as snowfall totals.

Finally, you can see a list of all messages sent, whether or not they were addressed to you, by pressing T (Traffic). You'll see the calls of the sending and receiving stations, plus their lines of text. Interspersed in the traffic are "time-ticks" to show the approximate time of receipt.

APRS is shareware, and it can be run indefinitely without paying the registration fee. However, as you begin to customize APRS for your personal tastes, like unproto paths and preferred map views, you will notice that you need to re-enter all your parameters each time you run the software. When you register your software with the author, WB4APR, you then get the ability to save your settings. For more information on registration, press V (Validate).

In future months, we'll discuss setting up home weather stations and mobile GPS trackers. For now, let me put out a request for area APRS users who have self-contained GPS trackers. Dane County ARES will be providing communications for the Madison Marathon on Sunday, May 30th, 1999. We will have an APRS display running in the communications tent, and are hoping to place 12 trackers in buses and in the vehicles preceding the lead male and female runners. If you'd like to help us out, please contact me at wj9h@arrl.net. If you're in southern Wisconsin, tune us in on 144.39 to see the action!
 

This page originally appeared in May 1999 Badger State Smoke Signals but was updated 2000 June 14.
Copyright 1999, 2000, Thomas C. Weeden, WJ9H