Configuring APRS transmissions


If you're going to start transmitting APRS packets on 144.800, there are a few parameters which need to be set up correctly in order to get the best out of the your system, and avoid generating unecessary traffic which could slow down the rest of the network:

Unproto address
Beacon interval
Compressed beacon mode
UIView messages
Burst-after-voice

Unproto address

This parameter determines how your transmitted packets are routed through the network. The simplest address is APRS, but other fields can be used to control digipeating (digital repeating) through the network.

As of November 2008, the latest guidelines recommend that base stations use APRS,WIDE2-2 and mobiles use WIDE1-1,WIDE2-2.

The local examples shown below illustarte how digipeating works with the older RELAY,TRACE settings:

If G6WVL-2 is set up to repeat transmissions containing the TRACE address:
then if I send a packet headed:
G6GVI>APU25N,TRACE3-3 this will be relayed as:
G6GVI>APU25N,G6WVL-2*,TRACE3-2 (APU25N is the APRS ID for UIView32).
Note that one of the TRACE fields has been replaced by G6WVL-2* (the asterisk signifies a digipeated packet). TRACE3-3 (equivalent to TRACE,TRACE,TRACE) means that my message will use a maximum of three digipeaters.

For my mobile Tracker, I use the address:
G6GVI-9>APOT02,RELAY,TRACE2-2 (APOT02 is the OpenTracker's APRS ID). RELAY is a special tag used by mobiles: many home-base stations are set up to repeat these, thus enabling the weaker mobile signals to access the network more easily.
Now, if G8HIK had his station set up to repeat RELAY packets, then he would re-transmit my signal as:
G6GVI-9>APOT02,G8HIK*,TRACE2-2 which would then be picked up by G6WVL-2 and echoed as:
G6GVI-9>APOT02,G8HIK,G6WVL-2*,TRACE2-1.

In either case, any packets re-transmitted by G6WVL-2 may be received by the Liverpool Internet Gateway (IGate) MB7USA, and sent onto the network. My Tracker's packet would then be headed:
G6GVI-9>APOT02,G8HIK,G6WVL-2*,TRACE2-1,qAR,MB7USA (for an explanation of the q-construct, see this page).
This message sequence is illustrated on the map below:

A typical APRS relay

Beacon interval

The beacon interval sets how often your APRS packets are transmitted. Don't forget that a single beacon transmission may generate several on-air re-transmissions, and will probably reach the Internet via a Gateway, so use them sparingly.

For static base-stations, 20 or 30 minute intervals are adequate, but obviously mobile stations require more rapid updates. In pedestrian (hiking) mode, I have my Open Tracker set for 300 second intervals (5 minutes), but when operating mobile, I use the SmartBeaconing algorithm, which makes the updates more frequent as the vehicle speed increases, and as I make turns.

Compressed beacon mode

Each of your transmitted APRS packets will contain a string of characters giving your latitude, longitude, speed and direction, height, display symbol, etc, as well as any comment which you've added. The APRS protocol allows most of this information (except the comment) to be encoded into a compressed format, which reduces the time for transmission (and each subsequent digipeating).
If selected, this compressed format is automatically generated in UIView or in the Tracker. The compressed string is decoded by the APRS program at the receiving end, so that it can position your symbol on the map.
For example, the location string =5334.64N/00226.76W- is compressed to =/3FI;MpdQ-.

Using the compressed mode to minimise the duration of your transmissions has two advantages:
1. It increases the probability of reception, since with a shorter packet there is a smaller chance of fading, interference or noise causing an error at the receiver.
2. It reduces the traffic on the APRS network. Each packet you transmit may generate several relayed messages, all of which will be of shorter duration.

When sending frequent position updates from a mobile, also try to minimise the text field for the same reasons. The Trackers can be set so that the text field is only sent once in several transmissions.

A word of caution: some of the on-line APRS sited do not seem to decode this mode correctly, and could be reporting incorrect mobile speeds, for example!

UIView messages

UIView has the capability to use the UI field to send short messages to a specific station, using digipeaters (and IGates) as required. For example, I've been able to have dialogues with friends in the Bristol area, by relaying my messages through MB7USA and then via its IGate to MB7UWE in Bristol, and then onwaards via RF. However, it's important to remember the potential network traffic which each message will generate, so I use a specific digi address (e.g. G6WVL-2,MB7USA) rather than TRACEn-n to get them through.

Each successful message will also generate an acknowledgment (ack), which will be sent back via the same path. UIView may be configured to repeat the original message until it receives an "ack". Set your system to be sparing with retries: mine is set to make only three attempts, with 30 second pauses between them.

Burst-after-voice mode

This mode is perhaps more suited to use as an add-on for normal voice operation, rather than on a dedicated APRS channel. Instead of sending packets automatically at pre-defined intervals, the APRS signal is sent when the ptt is released, so it acts as a kind of pip-tone at the end of an over. For this application, it's important to keep the transmisson short, so use compressed mode, and keep any text comment brief.
This mode could be used in ordinary voice nets, where stations equipped with APRS receivers would also be able to decode the bursts, and see the transmitter's position moving around their map.

The Kenwood D-series sets have this function ("ptt mode") built-in, and it is also supported by the TinyTrak units, OpenTrackers with firmware dated July 2006 or later.

See this page for details of how to set up your Tracker to do this.