Aprs 101
Aprs 101
REPORTING SYSTEM
APRS PROTOCOL
REFERENCE
Published by
Tucson Amateur Packet Radio Corp
8987–309 East Tanque Verde Road, #337
Tucson
AZ 85749-9399
United States of America
[Link]
ISBN 0-9644707-6-4
This document may be copied for non-commercial purposes only, and must
include the above copyright statement and trademark statements in full.
FOREWORD
This APRS Protocol Reference document represents the coming-of-age of WB4APR’s baby.
Starting with a simple concept — a way to track the location of moving objects via packet radio
— programs using the APRS protocol have grown into perhaps the most popular packet radio
application in use today. It’s also become one of the most complex; from the simple idea grew,
and still grows, a tactical communications system of tremendous capability. Like many ham
projects, the APRS protocol was designed as it was being implemented, and many of its
intricacies have never been documented.
Until now. This specification defines the APRS on-air protocol with a precision and clarity that
make it a model for future efforts. The work done by members of the APRS Working Group, as
well as Technical Editor Ian Wade, G3NRW, should be recognized as a tremendous contribution
to the packet radio art. With this document available, there is now no excuse for any developer to
improperly implement the APRS protocol.
As an APRS Working Group member whose role was mainly that of observer, I was fascinated
with the interplay among the APRS authors and the Technical Editor as the specification took
form. Putting onto paper details that previously existed only in the minds of the authors exposed
ambiguities, unconsidered consequences, and even errors in what the authors thought they knew.
The discussion that followed each draft, and the questions Ian posed as he tried to wring out the
uncertainties, gave everyone a better understanding of the protocol. I am sure that this process has
already contributed to better interoperability among existing APRS applications.
Everyone who has watched the specification develop, from the initial mention in April 1999 until
release of this Version 1.0 document in August 2000, knows that the process took much longer
than was hoped. At the same time, they saw the draft transformed from a skeleton into a hefty
book of over 110 pages. With the specification now in hand, I think we can all say the wait was
worth it. Congratulations to the APRS Working Group and, in particular, to G3NRW, for a major
contribution to the literature of packet radio.
PREAMBLE ........................................................................................................................... 1
APRS Working Group ...............................................................................................................1
Acknowledgements ...................................................................................................................1
Document Version Number .......................................................................................................1
Release History.........................................................................................................................2
Document Conventions .............................................................................................................2
Feedback ..................................................................................................................................2
AUTHORS’ FOREWORD ...................................................................................................... 3
Disclaimer .................................................................................................................................3
THE STRUCTURE OF THIS SPECIFICATION ..................................................................... 5
1 INTRODUCTION TO APRS............................................................................................... 7
What is APRS? .........................................................................................................................7
APRS Features .........................................................................................................................8
2 THE APRS DESIGN PHILOSOPHY.................................................................................. 9
Net Cycle Time..........................................................................................................................9
Packet Timing .........................................................................................................................10
Generic Digipeating.................................................................................................................11
Communicating Map Views Unambiguously............................................................................11
3 APRS AND AX.25............................................................................................................ 12
Protocols .................................................................................................................................12
The AX.25 Frame....................................................................................................................12
4 APRS DATA IN THE AX.25 DESTINATION AND SOURCE ADDRESS FIELDS........... 13
The AX.25 Destination Address Field......................................................................................13
Generic APRS Destination Addresses ....................................................................................13
Generic APRS Address with Symbol.......................................................................................14
APRS Software Version Number.............................................................................................14
Mic-E Encoded Data ...............................................................................................................15
Maidenhead Grid Locator in Destination Address....................................................................15
Alternate Nets .........................................................................................................................15
Generic APRS Digipeater Path ...............................................................................................15
The AX.25 Source Address SSID to specify Symbols .............................................................16
5 APRS DATA IN THE AX.25 INFORMATION FIELD ....................................................... 17
Generic Data Format...............................................................................................................17
APRS Data Type Identifier ......................................................................................................17
APRS Data and Data Extension ..............................................................................................18
Comment Field........................................................................................................................20
Base-91 Notation ....................................................................................................................20
APRS Data Units.....................................................................................................................21
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
ii Table of Contents
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Table of Contents iii
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
iv Table of Contents
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Table of Contents v
APPENDICES
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
Preamble 1
PREAMBLE
APRS Working The APRS Working Group is an unincorporated association whose members
Group undertake to further the use and enhance the value of the APRS protocols by
(a) publishing and maintaining a formal APRS Protocol Specification; (b)
publishing validation tests and other tools to enable compliance with the
Specification; (c) supporting an APRS Certification program; and (d) generally
working to improve the capabilities of APRS within the amateur radio
community.
Although the Working Group may receive support from TAPR and other
organizations, it is an independent body and is not affiliated with any
organization. The Group has no budget, collects no dues, and owns no assets.
The current members of the APRS Working Group are:
John Ackermann, N8UR Administrative Chair & TAPR Representative
Bob Bruninga, WB4APR Technical Chair, founder of APRS
Brent Hildebrand, KH2Z Author of APRS+SA
Stan Horzepa, WA1LOU Secretary
Mike Musick, N0QBF Author of pocketAPRS
Keith Sproul, WU2Z Co-Author of WinAPRS/MacAPRS/X-APRS
Mark Sproul, KB2ICI Co-Author of WinAPRS/MacAPRS/X-APRS
Acknowledgements This document is the result of contributions from many people. It includes
much of the material produced by individual members of the Working
Group.
In addition, the paper on the Mic-E data format by Alan Crosswell, N2YGK,
and Ron Parsons, W5RKN was a useful starting point for explaining the
complications of this format.
Document Except for the very first public draft release of the APRS Protocol Reference,
Version Number the document version number is a 3-part number “P.p.D” (for an approved
document release) or a 4-part number “[Link]” (for a draft release):
APRS Protocol
Version Document Draft
Release
Major Minor
Release Release
P. p. D d
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
2 Preamble
Release History The release history for this document is listed in Appendix 7.
Feedback Please address your feedback or other comments regarding this document to
the TAPR aprsspec mail list.
To join the list, start at [Link] and then follow the path Special
Interest Groups Ü APRS Specification Ü Join APRS Spec Discussion List.
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Authors’ Foreword 3
AUTHORS’ FOREWORD
Disclaimer Like any navigation system, APRS is not infallible. No one should rely
blindly on APRS for navigation, or in life-and-death situations. Similarly,
this specification is not infallible.
The members of the APRS Working Group have done their best to define the
APRS protocol, but this protocol description may contain errors, or there
may be omissions. It is very likely that not all APRS implementations will
fully or correctly implement this specification, either today or in the future.
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
4 Authors’ Foreword
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
The Structure of this Specification 5
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
6 The Structure of this Specification
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 1: Introduction to APRS 7
1 INTRODUCTION TO APRS
What is APRS? APRS is short for Automatic Position Reporting System, which was designed
by Bob Bruninga, WB4APR, and introduced by him at the 1992 TAPR/
ARRL Digital Communications Conference.
Fundamentally, APRS is a packet communications protocol for
disseminating live data to everyone on a network in real time. Its most visual
feature is the combination of packet radio with the Global Positioning
System (GPS) satellite network, enabling radio amateurs to automatically
display the positions of radio stations and other objects on maps on a PC.
Other features not directly related to position reporting are supported, such as
weather station reporting, direction finding and messaging.
APRS is different from regular packet in several ways:
• It provides maps and other data displays, for vehicle/personnel location
and weather reporting in real time.
• It performs all communications using a one-to-many protocol, so that
everyone is updated immediately.
• It uses generic digipeating, with well-known callsign aliases, so that prior
knowledge of network topology is not required.
• It supports intelligent digipeating, with callsign substitution to reduce
network flooding.
• Using AX.25 UI-frames, it supports two-way messaging and distribution
of bulletins and announcements, leading to fast dissemination of text
information.
• It supports communications with the Kenwood TH-D7 and TM-D700
radios, which have built-in TNC and APRS firmware.
Conventional packet radio is really only useful for passing bulk message
traffic from point to point, and has traditionally been difficult to apply to
real-time events where information has a very short lifetime. APRS turns
packet radio into a real-time tactical communications and display system for
emergencies and public service applications.
APRS provides universal connectivity to all stations, but avoids the
complexity, time delays and limitations of a connected network. It permits
any number of stations to exchange data just like voice users would on a
voice net. Any station that has information to contribute simply sends it, and
all stations receive it and log it.
APRS recognizes that one of the greatest real-time needs at any special event
or emergency is the tracking of key assets. Where is the marathon leader?
Where are the emergency vehicles? What’s the weather at various points in
the county? Where are the power lines down? Where is the head of the
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
8 Chapter 1: Introduction to APRS
APRS APRS runs on most platforms, including DOS, Windows 3.x, Windows
Features 95/98, MacOS, Linux and Palm. Most implementations on these platforms
support the main features of APRS:
• Maps — APRS station positions can be plotted in real-time on maps,
with coverage from a few hundred yards to worldwide. Stations reporting
a course and speed are dead-reckoned to their present position. Overlay
databases of the locations of APRS digipeaters, US National Weather
Service sites and even amateur radio stores are available. It is possible to
zoom in to any point on the globe.
• Weather Station Reporting — APRS supports the automatic display of
remote weather station information on the screen.
• DX Cluster Reporting — APRS an ideal tool for the DX cluster user.
Small numbers of APRS stations connected to DX clusters can relay DX
station information to many other stations in the local area, reducing
overall packet load on the clusters.
• Internet Access — The Internet can be used transparently to cross-link
local radio nets anywhere on the globe. It is possible to telnet into
Internet APRS servers and see hundreds of stations from all over the
world live. Everyone connected can feed their locally heard packets into
the APRS server system and everyone everywhere can see them.
• Messages — Messages are two-way messages with acknowledgement.
All incoming messages alert the user on arrival and are held on the
message screen until killed.
• Bulletins and Announcements —Bulletins and announcements are
addressed to everyone. Bulletins are sent a few times an hour for a few
hours, and announcements less frequently but possibly over a few days.
• Fixed Station Tracking — In addition to automatically tracking mobile
GPS/LORAN-equipped stations, APRS also tracks from manual reports
or grid squares.
• Objects — Any user can place an APRS Object on his own map, and
within seconds that object appears on all other station displays. This is
particularly useful for tracking assets or people that are not equipped
with trackers. Only one packet operator needs to know where things are
(e.g. by monitoring voice traffic), and as he maintains the positions and
movements of assets on his screen, all other stations running APRS will
display the same information.
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 2: APRS Design Philosophy 9
Net Cycle Time It is important to note that APRS is primarily a real-time, tactical
communications tool, to help the flow of information for things like special
events, emergencies, Skywarn, the Emergency Operations Center and just
plain in-the-field use under stress. But like the real world, for 99% of the
time it is operating routinely, waiting for the unlikely serious event to
happen.
Anything which is done to enhance APRS must not undermine its ability to
operate in local areas under stress. Here are the details of that philosophy:
1. APRS uses the concept of a “net cycle time”. This is the time within
which a user should be able to hear (at least once) all APRS stations
within range, to obtain a more or less complete picture of APRS activity.
The net cycle time will vary according to local conditions and with the
number of digipeaters through which APRS data travels.
2. The objective is to have a net cycle time of 10 minutes for local use. This
means that within 10 minutes of arrival on the scene, it is possible to
captured the entire tactical picture.
3. All stations, even fixed stations, should beacon their position at the net
cycle time rate. In a stress situation, stations are coming and going all the
time. The position reports show not only where stations are without
asking, but also that they are still active.
4. It is not reasonable to assume that all APRS users responding to a stress
event understand the ramifications of APRS and the statistics of the
channel — user settings cannot be relied on to avoid killing a stressed
net. Thus, to try to anticipate when the channel is under stress, APRS
automatically adjusts its net cycle time according to the number of
digipeaters in the UNPROTO path:
• Direct operation (no digipeaters): 10 minutes (probably an
event).
• Via one digipeater hop: 10 minutes (probably an event).
• Via two digipeater hops: 20 minutes.
• Via three or more digipeater hops: 30 minutes.
5. Since almost all home stations set their paths to three or more
digipeaters, the default net cycle time for routine daily operation is 30
minutes. This should be a universal standard that everyone can bank on
— if you routinely turn on your radio and APRS and do nothing else,
then in 30 minutes you should have virtually the total picture of all
APRS stations within range.
6. Since knowing where the digipeaters are located is fundamental to APRS
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
10 Chapter 2: APRS Design Philosophy
Packet Timing Since APRS packets are error-free, but are not guaranteed delivery, APRS
transmits information redundantly. To assure rapid delivery of new or
changing data, and to preserve channel capacity by reducing interference
from old data, APRS should transmit new information more frequently than
old information.
There are several algorithms in use to achieve this:
• Decay Algorithm — Transmit a new packet once and n seconds later.
Double the value of n for each new transmission. When n reaches the net
cycle time, continue at that rate. Other factors besides “doubling” may be
appropriate, such as for new message lines.
• Fixed Rate — Transmit a new packet once and n seconds later. Transmit
it x times and stop.
• Message-on-Heard — Transmit a new packet according to either
algorithm above. If the packet is still valid, and has not been
acknowledged, and the net cycle time has been reached, then the
recipient is probably not available. However, if a packet is then
subsequently heard from the recipient, try once again to transmit the
packet.
• Time-Out — This term is used to describe a time period beyond which it
is reasonable to assume that a station no longer exists or is off the air if
no packets have been heard from it. A period of 2 hours is suggested as
the nominal default timeout. This time-out is not used in any transmitting
algorithms, but is useful in some programs to decide when to cease
displaying stations as “active”. Note that on HF, signals come and go, so
decisions about activity may need to be more flexible.
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 2: APRS Design Philosophy 11
Generic Digipeating The power of APRS in the field derives from the use of generic digipeating,
in that packets are propagated without a priori knowledge of the network.
There are six powerful techniques which have evolved since APRS was
introduced in 1992:
1. RELAY — Every VHF APRS TNC is assumed to have an alias of
RELAY, so that anyone can use it as a digipeater at any time.
2. ECHO — HF stations use the alias of ECHO as an alternative to
RELAY. (However, bearing in mind the nature of HF propagation, this
has the potential of causing interference over a wide area, and should
only be used sparingly by mobile stations).
3. WIDE — Every high-site digipeater is assumed to have an alias of WIDE
for longer distance communications.
4. TRACE — Every high-site digipeater that is using callsign substitution
is assumed to have the alias of TRACE. These digipeaters self-identify
packets they digipeat by inserting their own call in place of RELAY,
WIDE or TRACE.
5. WIDEn-N — A digipeater that supports WIDEn-N digipeating will
digipeat any WIDEn-N packet that is “new” and will subtract 1 from the
SSID until the SSID reaches –0. The digipeater keeps a copy or a
checksum of the packet and will not digipeat that packet again within
(typically) 28 seconds. This considerably reduces the number of
superfluous digipeats in areas with many digipeaters in radio range of
each other.
6. GATE — This generic callsign is used by HF-to-VHF Gateway
digipeaters. Any packet heard on HF via GATE will be digipeated locally
on VHF. This permits local networks to keep an eye on the national and
international picture.
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
12 Chapter 3: APRS and AX.25
Protocols At the link level, APRS uses the AX.25 protocol, as defined in Amateur
Packet-Radio Link-Layer Protocol (see Appendix 6 for details), utilizing
Unnumbered Information (UI) frames exclusively. This means that APRS
runs in connectionless mode, whereby AX.25 frames are transmitted without
expecting any response, and reception at the other end is not guaranteed.
At a higher level, APRS supports a messaging protocol that allows users to
send short messages (one line of text) to nominated stations, and expects to
receive acknowledgements from those stations.
The AX.25 Frame All APRS transmissions use AX.25 UI-frames, with 9 fields of data:
AX.25 UI-FRAME FORMAT
• Flag — The flag field at each end of the frame is the bit sequence 0x7e
that separates each frame.
• Destination Address — This field can contain an APRS destination
callsign or APRS data. APRS data is encoded to ensure that the field
conforms to the standard AX.25 callsign format (i.e. 6 alphanumeric
characters plus SSID). If the SSID is non-zero, it specifies a generic
APRS digipeater path.
• Source Address — This field contains the callsign and SSID of the
transmitting station. In some cases, if the SSID is non-zero, the SSID
may specify an APRS display Symbol Code.
• Digipeater Addresses — From zero to 8 digipeater callsigns may be
included in this field. Note: These digipeater addresses may be
overridden by a generic APRS digipeater path (specified in the
Destination Address SSID).
• Control Field — This field is set to 0x03 (UI-frame).
• Protocol ID — This field is set to 0xf0 (no layer 3 protocol).
• Information Field — This field contains more APRS data. The first
character of this field is the APRS Data Type Identifier that specifies the
nature of the data that follows.
• Frame Check Sequence — The FCS is a sequence of 16 bits used for
checking the integrity of a received frame.
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 4: APRS Data in the AX.25 Destination and Source Address Fields 13
The AX.25 The AX.25 Destination Address field can contain 6 different types of APRS
Destination information:
Address Field
• A generic APRS address.
• A generic APRS address with a symbol.
• An APRS software version number.
• Mic-E encoded data.
• A Maidenhead Grid Locator (obsolete).
• An Alternate Net (ALTNET) address.
In all of these cases, the Destination Address SSID may specify a generic
APRS digipeater path.
Generic APRS APRS uses the following generic beacon-style destination addresses:
Destination
AIR* † ALL* AP* BEACON CQ* GPS* DF*
Addresses
DGPS* DRILL* DX* ID* JAVA* MAIL* MICE*
QST* QTH* RTCM* SKY* SPACE* SPC* SYM*
TEL* TEST* TLM* WX* ZIP* †
The asterisk is a wildcard, allowing the address to be extended (up to a total
of 6 alphanumeric characters). Thus, for example, WX1, WX12 and WX12CD
are all valid APRS destination addresses.
† The AIR* and ZIP* addresses are being phased out, but are needed at
present for backward compatibility.
All of these addresses have an SSID of –0. Non-zero SSIDs are reserved for
generic APRS digipeating.
These addresses are copied by everyone. All APRS software must accept
packets with these destination addresses.
The address GPS (i.e. the 3-letter address GPS, not GPS*) is specifically
intended for use by trackers sending lat/long positions via digipeaters which
have the capability of converting positions to compressed data format.
The addresses DGPS and RTCM are used by differential GPS correction
stations. Most software will not make use of packets using this address, other
than to pass them on to an attached GPS unit.
The address SKY is used for Skywarn stations.
Packets addressed to SPCL are intended for special events. APRS software
can display such packets to the exclusion of all others, to minimize clutter on
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
14 Chapter 4: APRS Data in the AX.25 Destination and Source Address Fields
the screen from other stations not involved in the special event.
The addresses TEL and TLM is used for telemetry stations.
Generic APRS APRS uses several of the above-listed generic addresses in a special way, to
Address with specify not only an address but also a display symbol. These special
Symbol addresses are GPSxyz, GPSCnn, GPSEnn, SPCxyz and SYMxyz, and are
intended for use where it is not possible to include the symbol in the AX.25
Information field.
The GPS addresses above are for general use.
The SPC addresses are intended for special events.
The SYM addresses are reserved for future use.
The characters xy and nn refer to entries in the APRS Symbol Tables. The
character z specifies a symbol overlay. See Chapter 20: APRS Symbols and
Appendix 2 for more information.
APRS Software The AX.25 Destination Address field can contain the version number of the
Version Number APRS software that is running at the station. Knowledge of the version
number can be useful when debugging.
The following software version types are reserved (xx and xxx indicate a
version number):
APCxxx APRS/CE, Windows CE
APDxxx Linux aprsd server
APExxx PIC-Encoder
APIxxx Icom radios (future)
APICxx ICQ messaging
APKxxx Kenwood radios
APMxxx MacAPRS
APPxxx pocketAPRS
APRxxx APRSdos
APRS older versions of APRSdos
APRSM older versions of MacAPRS
APRSW older versions of WinAPRS
APSxxx APRS+SA
APWxxx WinAPRS
APXxxx X-APRS
APYxxx Yaesu radios (future)
APZxxx Experimental
This table will be added to by the APRS Working Group.
For example, a station using version 3.2.6 of MacAPRS could use the
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 4: APRS Data in the AX.25 Destination and Source Address Fields 15
Mic-E Encoded Another alternative use of the AX.25 Destination Address field is to contain
Data Mic-E encoded data. This data includes:
• The latitude of the station.
• A West/East Indicator and a Longitude Offset Indicator (used in
longitude computations).
• A Message Code.
• The APRS digipeater path.
This data is used with associated data in the AX.25 Information field to
provide a complete Position Report and other information about the station
(see Chapter 10: Mic-E Data Format).
Maidenhead Grid The AX.25 Destination Address field may contain a 6-character Maidenhead
Locator in Grid Locator. For example: IO91SX. This format is typically used by meteor
Destination scatter and satellite operators who need to keep packets as short as possible.
Address
This format is now obsolete.
Alternate Nets Any other destination address not included in the specific generic list or the
other categories mentioned above may be used in Alternate Nets (ALTNETs)
by groups of individuals for special purposes. Thus they can use the APRS
infrastructure for a variety of experiments without cluttering up the maps and
lists of other APRS stations. Only stations using the same ALTNET address
should see their data.
Generic APRS The SSID in the Destination Address field of all packets is coded to specify
Digipeater Path the APRS digipeater path.
If the Destination Address SSID is –0, the packet follows the standard AX.25
digipeater (“VIA”) path contained in the Digipeater Addresses field of the
AX.25 frame.
If the Destination Address SSID is non-zero, the packet follows one of 15
generic APRS digipeater paths.
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
16 Chapter 4: APRS Data in the AX.25 Destination and Source Address Fields
The SSID field in the Destination Address (i.e. in the 7th address byte) is
encoded as follows:
APRS Digipeater Paths in Destination Address SSID
SSID Path SSID Path
-0 Use VIA path -8 North path
-1 WIDE1-1 -9 South path
-2 WIDE2-2 -10 East path
-3 WIDE3-3 -11 West path
-4 WIDE4-4 -12 North path + WIDE
-5 WIDE5-5 -13 South path + WIDE
-6 WIDE6-6 -14 East path + WIDE
-7 WIDE7-7 -15 West path + WIDE
The AX.25 Source The AX.25 Source Address field contains the callsign and SSID of the
Address SSID to originating station. If the SSID is –0, APRS does not treat it in any special
specify Symbols way.
If, however, the Source Address SSID is non-zero, APRS interprets it as a
display icon. This is intended for use only with stand-alone trackers where
there is no other method of specifying a display symbol or a destination
address (e.g. MIM trackers or NMEA trackers).
For more information, see Chapter 20: APRS Symbols.
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 5: APRS Data in the AX.25 Information Field 17
Generic Data In general, the AX.25 Information field can contain some or all of the
Format following information:
• APRS Data Type Identifier
• APRS Data
• APRS Data Extension
• Comment
Generic APRS Information Field
Data APRS Data APRS Data Comment
Type ID Extension
Bytes: 1 n 7 n
APRS Data Type Every APRS packet contains an APRS Data Type Identifier (DTI). This
Identifier determines the format of the remainder of the data in the Information field, as
follows:
APRS Data Type Identifiers
Ident Data Type Ident Data Type
0x1c Current Mic-E Data (Rev 0 beta) < Station Capabilities
0x1d Old Mic-E Data (Rev 0 beta) = Position without timestamp (with APRS
messaging)
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
18 Chapter 5: APRS Data in the AX.25 Information Field
Note: There is one exception to the requirement for the Data Type Identifier
to be the first character in the Information field — this is the Position without
Timestamp (indicated by the ! DTI). The ! character may occur anywhere
up to and including the 40th character position in the Information field. This
variability is required to support X1J TNC digipeaters which have a string of
unmodifiable text at the beginning of the field.
Note: The Kenwood TM-D700 radio uses the ' DTI for current Mic-E data.
The radio does not use the ‘ DTI.
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 5: APRS Data in the AX.25 Information Field 19
Addressee
Messages, Message Text
Message Identifier
Bulletins and
Message Acknowledgement
Announcements Bulletin ID, Announcement ID
Group Bulletin ID
Query Type
Queries Query Target Footprint
Addressee (Directed Query)
Position Course and Speed
Object/Item Power, Effective Antenna Height/Gain/Directivity
Weather Pre-Calculated Radio Range
Status Omni DF Signal Strength
Message Area Object
Responses
Digipeater Trace Wind Direction and Speed
Stations Heard
Heard Statistics
Station Capabilities
Time (DHM zulu)
Status text
Meteor Scatter Beam Heading/Power
Status
Maidenhead Locator (Grid Square)
Altitude (Mic-E)
E-mail message
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
20 Chapter 5: APRS Data in the AX.25 Information Field
Comment Field In general, any APRS packet can contain a plain text comment (such as a
beacon message) in the Information field, immediately following the APRS
Data or APRS Data Extension.
There is no separator between the APRS data and the comment unless
otherwise stated.
The comment may contain any printable ASCII characters (except | and ~,
which are reserved for TNC channel switching).
The maximum length of the comment field depends on the report — details
are included in the description of each report.
In special cases, the Comment field can also contain further APRS data:
• Altitude in comment text (see Chapter 6: Time and Position Formats), or
in Mic-E status text (see Chapter 10: Mic-E Data Format).
• Maidenhead Locator (grid square), in a Mic-E status text field (see
Chapter 10: Mic-E Data Format) or in a Status Report (see Chapter 16:
Status Reports).
• Bearing and Number/Range/Quality parameters (/BRG/NRQ), in DF
reports (see Chapter 7: APRS Data Extensions).
• Area Object Line Widths (see Chapter 11: Object and Item Reports).
• Signpost Objects (see Chapter 11: Object and Item Reports).
• Weather and Storm Data (see Chapter 12: Weather Reports).
• Beam Heading and Power, in Status Reports (see Chapter 16: Status
Reports).
Base-91 Notation Two APRS data formats use base-91 notation: lat/long coordinates in
compressed format (see Chapter 9) and the altitude in Mic-E format (see
Chapter 10).
Base-91 data is compressed into a short string of characters. All the
characters are printable ASCII, with character codes in the range 33–124
decimal (i.e. ! through |).
To compute the base-91 ASCII character string for a given data value, the
value is divided by progressively reducing powers of 91 until the remainder
is less than 91. At each step, 33 is added to the modulus of the division
process to obtain the corresponding ASCII character code.
For example, for a data value of 12345678:
12345678 / 913 = modulus 16, remainder 288542
288542 / 912 = modulus 34, remainder 6988
6988 / 911 = modulus 76, remainder 72
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 5: APRS Data in the AX.25 Information Field 21
The four ASCII character codes are thus 49 (i.e. 16+33), 67 (i.e. 34+33), 109
(i.e. 76+33) and 105 (i.e. 72+33), corresponding to the ASCII string 1Cmi.
APRS Data Units For historical reasons there is some lack of consistency between units of data
in APRS packets — some speeds are in knots, others in miles per hour; some
altitudes are in feet, others in meters, and so on. It is emphasized that this
specification describes the units of data as they are transmitted on-air. It is
the responsibility of APRS applications to convert the on-air units to more
suitable units if required.
The default GPS earth datum is World Geodetic System (WGS) 1984.
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
22 Chapter 6: Time and Position Formats
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 6: Time and Position Formats 23
Use of Timestamps When a station transmits a report without a timestamp, an APRS receiving
station can make an internal record of the time it was received, if required.
This record is the receiving station’s notion of the time the report was
created.
On the other hand, when a station transmits a report with a timestamp, that
timestamp represents the transmitting station’s notion of the time the report
was created.
In other words, reports sent without a timestamp can be regarded as real-time,
“current” reports (and the receiving station has to record the time they were
received), whereas reports sent with a timestamp may or may not be real-
time, and may possibly be (very) “old”.
Four APRS Data Type Identifiers specify whether or not a report contains a
timestamp, depending on whether the station has APRS messaging capability
or not:
Latitude Format Latitude is expressed as a fixed 8-character field, in degrees and decimal
minutes (to two decimal places), followed by the letter N for north or S for
south.
Latitude degrees are in the range 00 to 90. Latitude minutes are expressed as
whole minutes and hundredths of a minute, separated by a decimal point.
For example:
4903.50N is 49 degrees 3 minutes 30 seconds north.
In generic format examples, the latitude is shown as the 8-character string
[Link] (i.e. degrees, minutes and hundredths of a minute north).
Longitude Format Longitude is expressed as a fixed 9-character field, in degrees and decimal
minutes (to two decimal places), followed by the letter E for east or W for
west.
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
24 Chapter 6: Time and Position Formats
Longitude degrees are in the range 000 to 180. Longitude minutes are
expressed as whole minutes and hundredths of a minute, separated by a
decimal point.
For example:
07201.75W is 72 degrees 1 minute 45 seconds west.
In generic format examples, the longitude is shown as the 9-character string
[Link] (i.e. degrees, minutes and hundredths of a minute west).
Position Ambiguity In some instances — for example, where the exact position is not known —
the sending station may wish to reduce the number of digits of precision in
the latitude and longitude. In this case, the mm and hh digits in the latitude
may be progressively replaced by a V (space) character as the amount of
imprecision increases. For example:
4903.5VN represents latitude to nearest 1/10th of a minute.
[Link] represents latitude to nearest minute.
[Link] represents latitude to nearest 10 minutes.
[Link] represents latitude to nearest degree.
The level of ambiguity specified in the latitude will automatically apply to
the longitude as well — it is not necessary to include any V characters in the
longitude.
For example, the coordinates:
[Link]/07201.75W-
represent the position to the nearest minute. That is, the hundredths of
minutes of latitude and longitude may take any value in the range 00–99.
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 6: Time and Position Formats 25
Thus the station may be located anywhere inside a bounding box having the
following corner coordinates:
North West corner: 49 deg 3.99 mins N, 72 deg 1.99 mins W
North East corner: 49 deg 3.99 mins N, 72 deg 1.00 mins W
South East corner: 49 deg 3.00 mins N, 72 deg 1.00 mins W
South West corner: 49 deg 3.00 mins N, 72 deg 1.99 mins W
Default Null Where a station does not have any specific position information to transmit
Position (for example, a Mic-E unit without a GPS receiver connected to it), the
station must transmit a default null position in the location field.
The null position corresponds to 0° 0' 0" north, 0° 0' 0" west.
The null position should be include the \. symbol (unknown/indeterminate
position). For example, a Position Report for a station with unknown position
will contain the coordinates …0000.00N\00000.00W.…
NMEA Data APRS recognizes raw ASCII data strings conforming to the NMEA 0183
Version 2.0 specification, originating from navigation equipment such as
GPS and LORAN receivers. It is recommended that APRS stations interpret
at least the following NMEA Received Sentence types:
GGA Global Positioning System Fix Data
GLL Geographic Position, Latitude/Longitude Data
RMC Recommended Minimum Specific GPS/Transit Data
VTG Velocity and Track Data
WPT Way Point Location
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
26 Chapter 6: Time and Position Formats
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 7: APRS Data Extensions 27
A fixed-length 7-byte field may follow APRS position data. This field is an
APRS Data Extension. The extension may be one of the following:
• CSE/SPD Course and Speed (this may be followed by a further 8 bytes
containing DF bearing and Number/Range/Quality
parameters)
• DIR/SPD Wind Direction and Wind Speed
• PHGphgd Station Power and Effective Antenna Height/Gain/
Directivity
• RNGrrrr Pre-Calculated Radio Range
• DFSshgd DF Signal Strength and Effective Antenna Height/Gain
• Tyy/Cxx Area Object Descriptor
Course and Speed The 7-byte CSE/SPD Data Extension can be used to represent the course and
speed of a vehicle or APRS Object.
The course is expressed in degrees (001-360), clockwise from due north. The
speed is expressed in knots. A slash / character separates the two.
For example:
088/036 represents a course 88 degrees, traveling at 36 knots.
If the course and speed are unknown or not relevant, they can be set to
000/000 or .../... or VVV/VVV
VVV VVV .
Note: In the special case of DF reports, a course of 000 means that the DF
station is fixed. If the course is non-zero, the station is mobile.
Wind Direction The 7-byte DIR/SPD Data Extension can be used to represent the wind
and Wind Speed direction and sustained one-minute wind speed in a Weather Report.
The wind direction is expressed in degrees (001-360), clockwise from due
north. The speed is expressed in knots. A slash / character separates the two.
For example:
220/004 represents a wind direction of 220 degrees and a speed of
4 knots.
If the wind direction and speed are unknown or not relevant, they can be set
to 000/000 or .../... or VVV/VVV
VVV VVV .
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
28 Chapter 7: APRS Data Extensions
Power, The 7-byte PHGphgd Data Extension specifies the transmitter power,
Effective Antenna effective antenna height-above-average-terrain, antenna gain and antenna
Height/Gain/ directivity. APRS uses this information to plot radio range circles around
Directivity stations.
The 7 characters of this Data Extension are encoded as follows:
Characters 1–3: PHG (fixed)
Character 4: p Power code
Character 5: h Height code
Character 6: g Antenna gain code
Character 7: d Directivity code
The PHG codes are listed in the table below:
PHG Codes
phgd Code: 0 1 2 3 4 5 6 7 8 9 Units
Power 0 1 4 9 16 25 36 49 64 81 watts
Height 10 20 40 80 160 320 640 1280 2560 5120 feet
Gain 0 1 2 3 4 5 6 7 8 9 dB
Directivity omni 45 90 135 180 225 270 315 360 deg
NE E SE S SW W NW N
The height code represents the effective height of the antenna above average
local terrain, not above ground or sea level — this is to provide a rough
indication of the antenna’s effectiveness in the local area .
The height code may in fact be any ASCII character 0–9 and above. This is
so that larger heights for balloons, aircraft or satellites may be specified.
For example:
: is the height code for 10240 feet (approximately 1.9 miles).
; is the height code for 20480 feet (approximately 3.9 miles), and so on.
The Directivity code offsets the PHG circle by one third in the indicated
direction. This means a front-to-back ratio of 2 to 1. Most often this is used
to indicate a favored direction or a null, even if an omni antenna is at the site.
An example of the PHG Data Extension:
PHG5132 means a power of 25 watts,
an antenna height of 20 feet above the average local terrain,
an antenna gain of 3 dB,
and maximum gain due east.
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 7: APRS Data Extensions 29
Range Circle Plot On receipt, APRS uses the p, h, g and d codes to calculate the usable radio
range (in miles), for plotting a range circle representing the local radio
horizon around the station. The radio range is calculated as follows:
power = p2
Height-above-average-terrain (haat) = 10 x 2h
gain = 10(g/10)
range = –( 2 x haat x –( (power/10) x (gain/2) ) )
Thus, for PHG5132:
power = 52 = 25 watts
haat = 10 x 21 = 20 feet
Pre-Calculated The 7-byte RNGrrrr Data Extension allows users to transmit a pre-
Radio Range calculated omni-directional radio range, where rrrr is the range in miles
(with leading zeros).
For example, RNG0050 indicates a radio range of 50 miles.
APRS can use this value to plot a range circle around the station.
Omni-DF Signal The 7-byte DFSshgd Data Extension lets APRS localize jammers by plotting
Strength the overlapping signal strength contours of all stations hearing the signal.
This Omni-DF format replaces the PHG format to indicate DF signal
strength, in that the transmitter power field is replaced with the relative
signal strength (s) from 0 to 9.
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
30 Chapter 7: APRS Data Extensions
DFS Codes
shgd Code: 0 1 2 3 4 5 6 7 8 9 Units
Strength 0 1 2 3 4 5 6 7 8 9 S-points
Height 10 20 40 80 160 320 640 1280 2560 5120 feet
Gain 0 1 2 3 4 5 6 7 8 9 dB
Directivity omni 45 90 135 180 225 270 315 360 deg
NE E SE S SW W NW N
For example, DFS2360 represents a weak signal (around strength S2) heard
on an omni antenna with 6 dB gain at 80 feet.
A signal strength of zero (0) is particularly significant, because APRS uses
these 0 signal reports to draw (usually black) circles where the jammer is not
heard. These black circles are extremely valuable since there will be a lot
more reports from stations that do not hear the jammer than from those that
do. This quickly eliminates a lot of territory.
Bearing and DF reports contain an 8-byte field /BRG/NRQ that follows the CSE/SPD Data
Number/Range/ Extension, specifying the course, speed, bearing and NRQ (Number/Range/
Quality Quality) value of the report. NRQ indicates the Number of hits, the
approximate Range and the Quality of the report.
For example, in:
…088/036/270/729… course = 88 degrees, speed = 36 knots,
bearing = 270 degrees, N = 7, R = 2, Q = 9
If N is 0, then the NRQ value is meaningless. Values of N from 1 to 8 give an
indication of the number of hits per period relative to the length of the time
period — thus a value of 8 means 100% of all samples possible got a hit. A
value of 9 for N indicates to other users that the report is manual.
The N value is not processed, but is just another indicator from the automatic
DF units.
The range limits the length of the line to the original map’s scale of the
sending station. The range is 2R so, for R=4, the range will be 16 miles.
Q is a single digit in the range 0–9, and provides an indication of bearing
accuracy:
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 7: APRS Data Extensions 31
If the course and speed parameters are not appropriate, they should have the
value 000/000 or .../... or VVV/VVV
VVV VVV .
Area Object The 7-byte Tyy/Cxx Data Extension is an Area Object Descriptor. The T
Descriptor parameter specifies the type of object (square, circle, triangle, etc) and the
/C parameter specifies its fill color.
Area Objects are described in Chapter 11: Object and Item Reports.
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
32 Chapter 8: Position and DF Report Data Formats
Position Reports Lat/Long Position Reports are contained in the Information field of an APRS
AX.25 frame.
The following diagrams show the permissible formats of these reports,
together with some examples. The gray areas indicate optional fields, and the
shaded (yellow) characters are literal ASCII characters. In all cases there is a
maximum of 43 characters after the Symbol Code.
Sym Symbol
! or Lat Table Long Comment
= Code
ID (max 43 chars)
Bytes: 1 8 1 9 1 0-43
Examples
!4903.50N/07201.75W-Test 001234 no timestamp, no APRS messaging, with comment.
!4903.50N/07201.75W-Test /A=001234 no timestamp, no APRS messaging, altitude = 1234 ft.
![Link]/[Link]- no timestamp, no APRS messaging, location to
nearest degree.
V X-1J4VV
TheNetV VV(BFLD)!4903.50N/07201.75Wn no timestamp, no APRS messaging,
with X1J node header string.
Bytes: 1 7 8 1 9 1 0-43
Examples
/092345z4903.50N/07201.75W>Test1234 with timestamp, no APRS messaging, zulu time, with
comment.
@092345/4903.50N/07201.75W>Test1234 with timestamp, with APRS messaging, local time,
with comment.
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 8: Position and DF Report Data Formats 33
DF Signal Strength
Bytes: 1 8 1 9 1 7 0-36
Example
=4903.50N/07201.75W#PHG5132 no timestamp, with APRS messaging, with PHG.
=4903.50N/07201.75W_225/000g000t050r000p001…h00b10138dU2k weather report.
DF Signal Strength
Bytes: 1 7 8 1 9 1 7 0-36
Examples
@092345/4903.50N/07201.75W>088/036 with timestamp, with APRS messaging, local time,
course/speed.
@234517h4903.50N/07201.75W>PHG5132 with timestamp, APRS messaging, hours/mins/secs
time, PHG.
@092345z4903.50N/07201.75W>RNG0050 with timestamp, APRS messaging, zulu time, radio
range.
/234517h4903.50N/07201.75W>DFS2360 with timestamp, hours/mins/secs time, DF,
no APRS messaging.
@092345z4903.50N/07201.75W_090/000g000t066r000p000…dUII weather report.
Bytes: 1 4 or 6 1 n
Examples
[IO91SX] 35 miles NNW of London
[IO91]
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
34 Chapter 8: Position and DF Report Data Formats
$ …,…,…,…,…,…,…
Bytes: 1 25-209
Examples
$GPGGA,102705,5157.9762,N,00029.3256,W,1,04,2.0,75.7,M,47.6,M,,*62
$GPGLL,2554.459,N,08020.187,W,154027.281,A
$GPRMC,063909,A,3349.4302,N,11700.3721,W,43.022,89.3,291099,13.6,E*52
$GPVTG,318.7,T,,M,35.1,N,65.0,K*69
DF Reports DF Reports are contained in the Information field of an APRS AX.25 frame.
The Bearing and Number/Range/Quality (BRG/NRQ) parameters follow the
Data Extension field.
Note: The BRG/NRQ parameters are only meaningful when the report
contains the DF symbol (i.e. the Symbol Table ID is / and the Symbol Code
is \).
Note: If the DF station is fixed, the Course value is zero. If the station is
moving, the Course value is non-zero.
Examples
=4903.50N/07201.75W\088/036/270/729 no timestamp, course/speed/
bearing/NRQ, with APRS messaging.
DF station moving (CSE is non-zero).
=4903.50N/07201.75W\000/036/270/729 Same report, DF station fixed
(CSE=000).
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 8: Position and DF Report Data Formats 35
Examples
@092345z4903.50N/07201.75W\088/036/270/729 with timestamp, course/speed/
bearing/NRQ, with APRS messaging.
/092345z4903.50N/07201.75W\000/000/270/729 with timestamp, bearing/NRQ, no
course/speed, no APRS messaging.
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
36 Chapter 9: Compressed Position Report Data Formats
The Advantages of Compressed data format may be used in place of the numeric lat/long
Data Compression coordinates already described, such as in the !, /, @ and = formats.
Data compression has several important benefits:
• Fully backwards compatible with all existing formats.
• Fully supports any comment string.
• Speed is accurate to +/-1 mph up to about 40 mph and within 3% at 600
mph.
• Altitude in feet is accurate to +/- 0.4% from 1 foot to 3000 miles.
• Consistent one-algorithm processing of compressed latitude and
longitude.
• Improved position to 1 foot worldwide.
• Pre-calculated radio range, compressed to one byte.
• Potential 50% compression of every position format on the air.
• Potential 40% reduction of raw GPS NMEA data length.
• Additional 7-byte reduction for NEMA GGA altitudes.
• Support for TNC compression at the NMEA source (from the GPS
receiver).
• Digipeater compression of old NMEA trackers on the fly.
• Usage is optional in all cases.
The only minor disadvantages are that the course only resolves to +/- 2
degrees, and this format does not support PHG.
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 9: Compressed Position Report Data Formats 37
Symbol The presence of the leading Symbol Table Identifier instead of a digit
indicates that this is a compressed Position Report and not a normal lat/long
report.
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
38 Chapter 9: Compressed Position Report Data Formats
Lat/Long Encoding The values of YYYY and XXXX are computed as follows:
YYYY is 380926 x (90 – latitude) [base 91]
latitude is positive for north, negative for south, in degrees.
XXXX is 190463 x (180 + longitude) [base 91]
longitude is positive for east, negative for west, in degrees.
For example, for a longitude of 72° 45' 00" west (i.e. -72.75 degrees), the
math is 190463 x (180 – 72.75) = 20427156. Because this is to base 91, it is
then necessary to progressively divide this value by reducing powers of 91,
to obtain the numerical values of X:
20427156 / 913 = 27, remainder 80739
80739 / 912 = 9, remainder 6210
6210 / 911 = 68, remainder 22
To obtain the corresponding ASCII characters, 33 is added to each of these
values, yielding 60 (i.e. 27+33), 42, 101 and 55. From the ASCII Code Table
(in Appendix 3), this corresponds to <*e7 for XXXX.
Lat/Long Decoding To decode a compressed lat/long, the reverse process is needed. That is, if
YYYY is represented as y1y2y3y4 and XXXX as x1x2x3x4, then:
3 2
Lat = 90 - ((y1-33) x 91 + (y2-33) x 91 + (y3-33) x 91 + y4-33) / 380926
3 2
Long = -180 + ((x1-33) x 91 + (x2-33) x 91 + (x3-33) x 91 + x4-33) / 190463
For example, if the compressed value of the longitude is <*e7 (as computed
above), the calculation becomes:
3 2
Long = -180 + (27 x 91 + 9 x 91 + 68 x 91 + 22) / 190463
= -180 + (20346417 + 74529 + 6188 + 22) / 190463
= -180 + 107.25
= -72.75 degrees
Course/Speed, The two cs bytes following the Symbol Code character can contain either
Pre-Calculated the compressed course and speed or the compressed pre-calculated radio
Radio Range and range or the station’s altitude. These two bytes are in base 91 format.
Altitude
In the special case of c = V (space), there is no course, speed or range
data, in which case the csT bytes are ignored.
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 9: Compressed Position Report Data Formats 39
course = c x 4
speed = 1.08s – 1
For example, if the cs characters are 7P, the corresponding values of c and
s (after subtracting 33 from the ASCII character code) are 22 and 47
respectively. Substituting these values in the above equations:
course = 22 x 4 = 88 degrees
The Compression The T byte follows the cs bytes. The T byte contains several bit fields
Type (T) Byte showing the GPS fix status, the NMEA source of the position data and the
origin of the compression.
The T byte is not meaningful if the c byte is V (space).
Not used Not used GPS Fix NMEA Source Compression Origin
Value: 0 0 0 = old (last) 0 0 = other 0 0 0 = Compressed
1 = current 0 1 = GLL 0 0 1 = TNC BText
1 0 = GGA 0 1 0 = Software (DOS/Mac/Win/+SA)
1 1 = RMC 0 1 1 = [tbd]
1 0 0 = KPC3
1 0 1 = Pico
1 1 0 = Other tracker [tbd]
1 1 1 = Digipeater conversion
For example, if the compressed position was derived from an RMC sentence,
the fix is current, and the compression was performed by APRSdos software,
then the value of T in binary is 0 0 1 11 010, which equates to 58 decimal.
Adding 33 to this value gives the ASCII code for the T byte (i.e. 91), which
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
40 Chapter 9: Compressed Position Report Data Formats
Altitude If the T byte indicates that the raw data originates from a GGA sentence (i.e.
bits 4 and 3 of the T byte are 10), then the sentence contains an altitude
value, in feet. After compression, the compressed altitude data is placed in
the cs bytes, such that:
New Trackers Tracker firmware may compress GPS data directly to APRS compressed
format. They would use the ! Data Type Indicator, showing that the position
is real-time and that the tracker is not APRS-capable.
If the Position Report is not real-time, then the / Data Type Indicator can be
used instead, so that the latest fix time may be included.
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 9: Compressed Position Report Data Formats 41
Old Trackers Some digipeaters have the ability to convert raw NMEA strings from existing
trackers to compressed data format for further forwarding.
These digipeaters will compress the data if the tracker Destination Address is
GPS. (Note: This is the 3-letter address GPS, not GPS*).
Trackers desiring for their packets to not be modified by the APRS network
will use any other valid generic APRS Destination Address.
Compressed Report Compressed data is contained in the AX.25 Information field, in these
Formats formats:
Examples
=/5L!!<*e7>V sTComment with APRS messaging. Note the V space character following the >
Symbol Code, indicating that there is no course/speed, radio range or
altitude. The sT characters are fillers and have no significance here.
=/5L!!<*e7>7P[ with APRS messaging, RMC sentence, with course/speed.
=/5L!!<*e7>{?! with APRS messaging, with radio range.
=/5L!!<*e7OS]S with APRS messaging, GGA sentence, altitude.
Example
@092345z/5L!!<*e7>{?! with APRS messaging, timestamp, radio range.
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
42 Chapter 10: Mic-E Data Format
Mic-E Data Format In Mic-E data format, the station’s position, course, speed and display
symbol, together with an APRS digipeater path and Mic-E Message Code,
are packed into the AX.25 Destination Address and Information fields.
The Information field can also optionally contain either Mic-E telemetry data
or Mic-E status. The Mic-E Status can contain the station’s Maidenhead
locator and altitude.
Mic-E packets can be very short. At the minimum, with no callsigns in the
Digipeater Addresses field and no optional telemetry data or Mic-E status
text, a complete Mic-E packet is just 25 bytes long (excluding FCS and
flags).
Mic-E data format is not only used in the Microphone Encoder unit; it is also
used in the PIC Encoder and in the Kenwood TH-D7 and TM-D700 radios.
Mic-E Data Payload The Mic-E data format allows a large amount of data to be carried in a very
short packet. The data is split between the Destination Address field and the
Information field of a standard AX.25 UI-frame.
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 10: Mic-E Data Format 43
Mic-E Destination The standard AX.25 Destination Address field consists of 7 bytes, containing
Address Field 6 callsign characters and the SSID (plus a number of other bits that are not of
interest here). When used to carry Mic-E data, however, this field has a quite
different format:
Destination The table on the next page shows the encoding of the first 6 bytes of the
Address Field Destination Address field, for all combinations of latitude digit, the 3-bit
Encoding Mic-E message identifier (A/B/C), the latitude/longitude indicators and the
longitude offset.
The encoding supports position ambiguity.
The ASCII characters shown in the table are left-shifted one bit position prior
to transmission.
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
44 Chapter 10: Mic-E Data Format
Note: the ASCII characters A–K are not used in address bytes 4–6.
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 10: Mic-E Data Format 45
Mic-E Messages The first three bytes of the Destination Address field contain three message
identifier bits: A, B and C. These bits allow one of 15 message types to be
specified:
• 7 Standard messages
• 7 Custom messages
• 1 Emergency message
For the 7 Standard messages, one or more of the message identifier bits is a
1, shown in the Mic-E Destination Address Field Encoding table as 1 (Std).
For the 7 Custom messages, one or more of the message identifier bits is a 1,
shown in the Mic-E Destination Address Field Encoding table as 1 (Custom).
For the Emergency message, all three message identifier bits are 0.
The following table shows the encoding of Mic-E message types, for all
combinations of the A/B/C message identifier bits:
The Standard messages and the Emergency message have the same meaning
for all APRS stations. The Custom messages may be assigned any arbitrary
meaning.
Note: Support for Custom messages is optional. Original Mic-E units do not
support Custom messages.
Note: If the A/B/C message identifier bits contain a mixture of Standard 1s
and Custom 1s, the message type is “unknown”.
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
46 Chapter 10: Mic-E Data Format
Destination The SSID in the Destination Address field of a Mic-E packet is coded to
Address specify either a conventional digipeater VIA path (contained in the
SSID Field Digipeater Addresses field of the AX.25 frame), or one of 15 generic APRS
digipeater paths. See Chapter 4: APRS Data in the AX.25 Destination and
Source Address Fields.
Mic-E Information The Information field is used to complete the Position Report that was begun
Field in the Destination Address field. The encoding used is different from the
destination address since the content is not constrained to be printable,
shifted 7-bit ASCII, as it is in the address. However, full 8-bit binary is not
used — all values are offset by 28 and further operations (described below)
are performed on some of the values to make almost all of the data printable
ASCII.
The format of the Information field is as follows:
Mic-E Data — INFORMATION FIELD Format
Data Longitude Speed and Course Symbol Sym Mic-E Telemetry Data
Type Code Table
ID d+28 m+28 h+28 SP+28 DC+28 SE+28 ID Mic-E Status Text
Bytes: 1 1 1 1 1 1 1 1 1 n
Information Field The first 9 bytes of the Information field contain the APRS Data Type
Data Identifier, longitude, speed, course and symbol data.
The APRS Data Type Identifier is one of:
‘ Current GPS data
(but not used in Kenwood TM-D700 radios) .
' Old GPS data
(or Current GPS data in Kenwood TM-D700 radios).
0x1c Current GPS data (Rev. 0 beta units only).
0x1d Old GPS data (Rev. 0 beta units only).
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 10: Mic-E Data Format 47
Longitude Degrees The d+28 byte in the Information field contains the encoded value of the
Encoding longitude degrees, in the range 0–179 degrees.
(Note that for longitude values in the range 0–9 degrees, the longitude offset
is +100 degrees):
Mic-E Longitude Degrees Encoding
Long ASCII d+28 Long Long ASCII d+28 Long
Deg Char Offset Deg Char Offset
0 v 118 +100 100 l 108 +100
1 w 119 +100 101 m 109 +100
2 x 120 +100 102 n 110 +100
3 y 121 +100 103 o 111 +100
4 z 122 +100 104 p 112 +100
5 { 123 +100 105 q 113 +100
6 | 124 +100 106 r 114 +100
7 } 125 +100 107 s 115 +100
8 ~ 126 +100 108 t 116 +100
9 DEL 127 +100 109 u 117 +100
10 & 38 +0 110 & 38 +100
11 ' 39 +0 111 ' 39 +100
12 ( 40 +0 112 ( 40 +100
… …
97 } 125 +0 177 i 105 +100
98 ~ 126 +0 178 j 106 +100
99 DEL 127 +0 179 k 107 +100
Note from the table that the encoding is split into four separate pieces:
• 0–9 degrees: d+28 is in the range 118–127 decimal, corresponding to
the ASCII characters v to DEL.
Important Note: The longitude offset is set to +100 degrees when
the longitude is in the range 0–9 degrees.
• 10–99 degrees: d+28 is in the range 38–127 decimal (corresponding
to the ASCII characters & to DEL), and the longitude offset is +0
degrees.
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
48 Chapter 10: Mic-E Data Format
Longitude Minutes The m+28 byte in the Information field contains the encoded value of the
Encoding longitude minutes, in the range 0–59 minutes:
Mic-E Longitude Minutes Encoding
Long ASCII m+28 Long ASCII m+28
Mins Char Mins Char
0 X 88 10 & 38
1 Y 89 11 ' 39
2 Z 90 12 ( 40
3 [ 91 13 ) 41
4 \ 92 14 * 42
5 ] 93 …
6 ^ 94 56 T 84
7 _ 95 57 U 85
8 ‘ 96 58 V 86
9 a 97 59 W 87
Note from the table that the encoding is split into two separate pieces:
• 0–9 minutes: m+28 is in the range 88–97 decimal, corresponding to
the ASCII characters X to a.
• 10–59 minutes: m+28 is in the range 38–87 decimal (corresponding
to the ASCII characters & to W).
Thus the overall range of valid m+28 values is 38–97 decimal (corresponding
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 10: Mic-E Data Format 49
to ASCII characters & to a). All of these characters are printable ASCII
characters.
To decode the longitude minutes value:
1. subtract 28 from the m+28 value to obtain m.
2. subtract 60 if m ™ 60.
(i.e. the longitude minutes is in the range 0–9).
Longitude The h+28 byte in the Information field contains the encoded value of the
Hundredths of longitude hundredths of minutes, in the range 0–99 minutes. This byte takes
Minutes Encoding a value in the range 28 decimal (corresponding to 0 hundredths of a minute)
through 127 decimal (corresponding to 99 hundredths of a minute).
To decode the longitude hundredths of minutes value, subtract 28 from the
h+28 value.
All of the possible values are printable ASCII characters (except 0–3 and 99
hundredths of a minute).
Speed and Course The speed and course of a station are encoded in 3 bytes, designated SP+28,
Encoding DC+28 and SE+28.
The speed is in the range 0–799 knots, and the course is in the range 0–360
degrees (0 degrees represents an unknown or indefinite course, and 360
degrees represents due north).
The encoded speed and course are spread over the three bytes, as follows:
Speed Course
Encoded Speed (units) and
Encoded Speed Encoded Course
Encoded Course
(hundreds/tens of knots) (tens/units)
(hundreds of degrees)
SP+28 DC+28 SE+28
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
50 Chapter 10: Mic-E Data Format
SP+28 Encoding The SP+28 byte contains the encoded speed, in hundreds/tens of knots,
according to this table:
Note: The ASCII characters shown in white on a black background are non-
printing characters.
Note: For speeds in the range 0–199 knots, there are two encoding schemes
in existence. Hence there are two columns for the ASCII character, and two
columns for the corresponding SP+28 byte values.
For example, for a speed of 73 knots (i.e. in the range 70–79), the SP+28 byte
may contain either s or #, depending on the encoding method used. Both are
equally valid.
The decoding algorithm described later handles either of these encoding
schemes.
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 10: Mic-E Data Format 51
DC+28 Encoding The DC+28 byte contains the encoded units of speed, plus the encoded course
in hundreds of degrees:
Note: The ASCII characters shown in white on a black background are non-
printing characters.
Note: There are two encoding schemes in existence for the DC+28 byte.
Hence there are two columns for the ASCII character, and two columns for
the corresponding DC+28 byte values.
For example, for a speed of 73 knots (i.e. units=3) and a bearing of 294
degrees (i.e. in the range 200–299), the DC+28 byte may contain either @ or
<, depending on the encoding method used. Both are equally valid.
The decoding algorithm described later handles either of these encoding
schemes.
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
52 Chapter 10: Mic-E Data Format
SE+28 Encoding The SE+28 byte contains the encoded tens and units of degrees of the course:
SE+28 Course Encoding (tens/units of degrees)
Course ASCII m+28 Long ASCII m+28
(deg) Char Mins Char
0 0x1c 28 15 + 43
1 0x1d 29 16 , 44
2 0x1e 30 17 - 45
3 0x1f 31 18 . 46
4 V 32 19 / 47
5 ! 33 …
6 " 34 91 w 119
7 # 35 92 x 120
8 $ 36 93 y 121
9 % 37 94 z 122
10 & 38 95 { 123
11 ' 39 96 | 124
12 ( 40 97 } 125
13 ) 41 98 ~ 126
14 * 42 99 DEL 127
Example of Mic-E For a speed of 86 knots and a course of 194 degrees, the encoding is:
Speed and Course
Encoding SP+28: The speed is in the range 80–89 knots. From the SP+28 encoding
table, the SP+28 byte may be either t or $.
DC+28: The units of speed are 6, and the course is in the range 100–199
degrees. From the DC+28 encoding table, the DC+28 byte may be
either ] or Y.
SE+28: The course in tens and units of degrees is 94. From the SE+28
encoding table, the SE+28 byte will be z.
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 10: Mic-E Data Format 53
Example of If the first 9 bytes of the Information field contain ‘(_f n "Oj/, and the
Decoding the destination address specifies that the station is in the western hemisphere
Information Field with a longitude offset of +100 degrees, then the data is decoded as follows:
Data
• ‘ is the APRS Data Type Identifier for a Mic-E packet containing current
GPS data.
• ( is the d+28 byte. The ( character has the value 40 decimal. Subtracting
28 gives 12. The longitude offset (in the destination address) is +100
degrees, so the longitude is 100 + 12 = 112 degrees.
• _ is the m+28 byte. The _ character has the value 95 decimal. Subtracting
28 gives 67. This is ™ 60, so subtracting 60 gives a value of 7 minutes
longitude.
• f is the h+28 byte. The f character has the value 102 decimal.
Subtracting 28 gives 74 hundredths of a minute.
Thus the longitude is 112 degrees 7.74 minutes west.
The speed and course are calculated as follows:
• n is the SP+28 byte. The n character has the value 110 decimal. After
subtracting 28, the result is 82. As this is ™ 80, a further 80 is subtracted,
leaving a result of 2 tens of knots.
• " is the DC+28 byte. The " character has the value 34 decimal.
Subtracting 28 gives 6. Dividing this by 10 gives a quotient of 0 (units of
speed). Adding the first part of the speed, multiplied by 10 (i.e. 20) to the
quotient (0) gives a final computed speed of 20 knots.
The remainder from the division is 6. Subtracting 4 gives the course in
hundreds of degrees; i.e. 2.
• O (upper-case letter “O”) is the SE+28 byte. The O character has the value
79 decimal. Subtracting 28 gives 51. Adding this to the remainder
calculated above, multiplied by 100 (i.e. 200), gives the final value of
251 degrees for the course.
The last two characters (j/) represent the jeep symbol from the Primary
Symbol Table.
Mic-E Position As mentioned in Chapter 6 (Time and Position Formats), a station may
Ambiguity reduce the precision of its position by introducing position ambiguity. This is
also possible in Mic-E data format.
The position ambiguity is specified for the latitude (in the destination
address). The same degree of ambiguity will then also apply to the longitude.
For example, if the destination address is T4SQZZ, the last two digits of the
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
54 Chapter 10: Mic-E Data Format
latitude are ambiguous (represented by ZZ). Then, if the longitude data in the
Information field is (_f , as in the above example, the last two digits of the
computed longitude will be ignored — that is, the longitude will be 112
degrees 7 minutes.
Mic-E Telemetry The Information field may optionally contain either Mic-E telemetry data
Data values or Mic-E status text.
If the byte following the Symbol Table Identifier is one of the Telemetry
Flag characters (‘,' or 0x1d), then telemetry data follows:
Mic-E Status Text As an alternative to telemetry data, the packet may include Mic-E status text.
The status text may be any length that fits in the rest of the Information field.
The Mic-E status text must not start with ‘,' or 0x1d, otherwise it will be
confused with telemetry data.
It is possible to include a standard APRS-formatted position in the Mic-E
status text field. A suitable position will cause the APRS display software to
override any position data the Mic-E has encoded. This is useful if using a
Mic-E without a GPS receiver.
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 10: Mic-E Data Format 55
Note: The Kenwood radios automatically insert a special type code at the
front of the status text string (i.e. in the 10th character of the Information
field):
Kenwood TH-D7: >
Kenwood TM-D700: ]
These characters should not be confused with the APRS Data Type Identifier
that appears at the start of reports.
It is envisaged that other Mic-E-compatible devices will be allocated their
own type codes in future.
Note: When Kenwood radios receive the status, they can only display a small
number of text characters:
Kenwood TH-D7: 20 characters
Kenwood TM-D700: 28 characters
Note: The Kenwood TM-D700 radio uses the ' (apostrophe) instead of the ‘
(grave) APRS Data Type Identifier to represent current GPS data. A
suggested way of detecting this situation is to examine the first and 10th
characters of the Information field; if they are ' and ] respectively, then the
packet is almost certainly from a TM-D700.
Maidenhead The Mic-E status text field can contain a Maidenhead locator.
Locator in the Mic-E
Status Text Field If the locator is followed by a plain text comment, the first character of the
text must be a space. For example:
V HelloV world
IO91SX/GV (from a Mic-E or PIC-E)
V HelloV world
>IO91SX/GV (from a Kenwood TH-D7)
V HelloV world
]IO91SX/GV (from a Kenwood TM-D700)
Altitude in the The Mic-E status text field can contain the station’s altitude. The altitude is
Mic-E Status Text expressed in the form xxx}, where xxx is in meters relative to 10km below
Field mean sea level (the deepest ocean), to base 91.
For example, to compute the xxx characters for an altitude of 200 feet:
200 feet = 61 meters = 10061 meters relative to the datum
10061 / 912 = 1, remainder 1780
1780 / 91 = 19, remainder 51
Adding 33 to each of the highlighted values gives 34, 52 and 84 for the
ASCII codes of xxx.
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
56 Chapter 10: Mic-E Data Format
Mic-E Data in Some parts of the Mic-E AX.25 Information field may contain binary data
Non-APRS (i.e. non-printable ASCII characters). If such a packet is constrained to the
Networks APRS network, this should not cause any difficulties.
If, however, the packet is to be forwarded via a network that does not reliably
preserve binary data (e.g. the Internet), then it is necessary to convert the data
to a format that will preserve it.
Further, if the packet subsequently re-emerges back onto the APRS network,
it will then be necessary to re-convert the data back to its original format.
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 11: Object and Item Reports 57
Objects and Items Any APRS station can manually report the position of an APRS entity (e.g.
another station or a weather phenomenon). This is intended for situations
where the entity is not capable of reporting its own position.
APRS provides two types of report to support this:
• Object Reports
• Item Reports
Object Reports specify an Object’s position, can have an optional timestamp,
and can include course/speed information or other Extended Data. Object
Reports are intended primarily for plotting the positions of moving objects
(e.g. spacecraft, storms, marathon runners without trackers).
Item Reports specify an Item’s position, but cannot have a timestamp. While
Item reports may also include course/speed or other Extended Data, they are
really intended for inanimate things that are occasionally posted on a map
(e.g. marathon checkpoints or first-aid posts). Otherwise they are handled in
the same way as Object Reports.
Objects are distinguished from each other by having different Object names.
Similarly, Items are distinguished from each other by having different Item
names.
Implementation Recommendation: When an APRS Object/Item is displayed
on the screen, the callsign of the station sending the report should be
associated with the Object/Item.
Replacing an A fundamental precept of APRS is that any station may take over the
Object / Item reporting responsibility for an APRS Object or Item, by simply transmitting a
new report with the same Object/Item name.
The replacement report may specify the existing location or a new location.
The original station will cease transmitting an Object/Item Report when it
sees an incoming report with the same name from another station.
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
58 Chapter 11: Object and Item Reports
Object Report An Object Report has a fixed 9-character Object name, which may consist of
Format any printable ASCII characters.
Object names are case-sensitive.
The ; is the APRS Data Type Identifier for an Object Report, and a * or _
separates the Object name from the rest of the report:
* indicates a live Object.
_ indicates a killed Object.
The position may be in lat/long or compressed lat/long format, and the report
may also contain Extended Data.
An Object always has a timestamp.
The Comment field may contain any appropriate APRS data (see the
Comment Field section in Chapter 5: APRS Data in the AX.25 Information
Field).
Object Report Format — with Lat/Long position
Course/Speed
Object Time Sym Symbol
DHM / Lat Table Long Power/Height/Gain/Dir Comment
; Name * Code (max 36 chars with
HMS ID Radio Range
or Data Extension, or
_ DF Signal Strength 43 without)
Area Object
Bytes: 1 9 1 7 8 1 9 1 7 0-36/43
Examples
;LEADERVVV*092345z4903.50N/07201.75W>088/036 A live Object. At 2345 hours zulu
on the 9th of the month, the
“Leader” was in the car at
49°3'30"N/72°1'45"W, heading 88
deg at 36 knots.
;LEADERVVV_092345z4903.50N/07201.75W>088/036 The same Object, now killed.
Bytes: 1 9 1 7 13 43
Example
;LEADERVVV*092345z/5L!!<*e7>7P[ The “Leader” was in the car at 49°30'00"N/
72°45'00"W, heading 88 deg at 36.2 knots.
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 11: Object and Item Reports 59
Item Report An Item Report has a variable-length Item name, 3–9 characters long. The
Format name may consist of any printable ASCII characters except ! or _.
Item names are case-sensitive.
The ) is the APRS Data Type Identifier for an Item Report, and a ! or _
separates the Item name from the rest of the report:
! indicates a live Item.
_ is the Item “kill” character.
The position may be in lat/long or compressed lat/long format. There is no
provision for a timestamp. The report may also contain Extended Data.
The Comment field may contain any appropriate APRS data (see the
Comment Field section in Chapter 5: APRS Data in the AX.25 Information
Field).
Examples
)AIDV#2!4903.50N/07201.75WA First Aid Station #2 is at 49°3'30"N/72°1'45"W.
(/A is the symbol for Aid Station).
)G/WB4APR![Link]\[Link] A rare DX station “somewhere in England”.
(\d is the symbol for DX Spot).
)AIDV#2_4903.50N/07201.75WA The First Aid Station has closed down.
Bytes: 1 3-9 1 13 43
Example
)MOBIL!\5L!!<*e79VsT Mobil Gas Station is at 49°30'00"N/72°45'00"W.
(\9 is the symbol for Gas Station).
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
60 Chapter 11: Object and Item Reports
Area Objects Using the \l symbol (i.e. the lower-case letter “L” symbol from the Alternate
Symbol Table) it is possible to define circle, line, ellipse, triangle and box
objects in all colors, either open or filled in, any size from 60 feet to 100
miles.
These Objects are useful for real-time events such as for a search-and-rescue,
or adding a special road or route for a special event.
The Object format is specified as a 7-character APRS Data Extension
Tyy/Cxx immediately following the l Symbol Code. For example:
;OBJECTVVV*[Link]\[Link] l Tyy/Cxx
where:
T is the type of object shape.
/C is the color of the object.
yy is the square root of the latitude offset in 1/100ths of a degree.
xx is the square root of the longitude offset in 1/100ths of a degree.
The latitude/longitude position is the upper left corner of the object, and the
offsets are relative to this position — the yy offset is down from this position
and the xx offset is to the right of this position. (An exception is the special
case of a Type 6 line which is drawn down and to the left).
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 11: Object and Item Reports 61
Here are some examples of Object Position Reports. The latitude and
longitude offsets are each one degree (i.e. 100/100ths of a degree), so
yy = xx = –100 = 10.
;SEARCHVVV*092345z4903.50N\07201.75W l 710/310
A high intensity cyan filled ellipse, yy=10, xx=10
;SEARCHVVV*092345z4903.50N\07201.75W l 8101310
A low intensity violet filled triangle, yy=10, xx=10
Further, with the line option (Type 1 and Type 6) it is possible to specify a
“corridor” either side of the central line. The width of the corridor (in miles)
either side of the line is specified in the comment text, enclosed by {}.
For example:
;FLIGHTPTH*4903.50N\07201.75W l 610/310{100}
A high intensity cyan line, with a 100-mile corridor
either side
Note: The color fill option should be used with care, since a color-filled
object will obscure information displayed underneath it.
Signpost Signpost Objects/Items (with the symbol \m) display as a yellow box with a
Objects/Items 1–3-character overlay on them. The overlay is specified by enclosing the 1–3
characters in braces in the comment field. Thus a signpost with {55} would
appear as a sign with 55 on it.
For example:
)I91V3N!4903.50N\07201.75Wm{55}
This was originally designed for posting the speed of traffic past speed
measuring devices, but can be used for any purpose.
Implementation Recommendation: Signposts should not display any callsign
or name, and to avoid clutter should only be displayed at close range.
Obsolete Object Some stations transmit Object reports without the ; APRS Data Type
Format Identifier. This format is obsolete. Some software may still decode such data
as an Object, but it should now be interpreted as a Status Report.
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
62 Chapter 12: Weather Reports
12 WEATHER REPORTS
Weather Report APRS is an ideal tool for reporting weather conditions via packet. APRS
Types supports serial data transmissions from the Peet Brothers, Ultimeter and
Davis home weather stations. It is even possible to mount an Ultimeter
remotely with only a TNC and radio to report and plot conditions. APRS is
also ideally suited for the Skywarn weather observer initiative.
APRS supports three types of Weather Report:
• Raw Weather Report
• Positionless Weather Report
• Complete Weather Report
Data Type The following APRS Data Type Identifiers are used in Weather Reports
Identifiers containing raw data:
! Ultimeter 2000
# Peet Bros U-II
$ Ultimeter 2000
* Peet Bros U-II
_ Positionless weather data
In addition, where the raw data has been post-processed (for example, by the
insertion of station location information), the four position Data Type
Identifiers !, =, / and @ may be used instead. In this case, the Weather
Report is identified with the weather symbol /_ or \_ in the APRS Data.
Raw Weather Raw weather data from a stand-alone weather station is contained in the
Reports Information Field of an APRS AX.25 frame:
Examples
!!006B005803500000----03E9--------002105140000005D Ultimeter 2000
#50B7500820082 Peet Bros U-II
$ULTW0031003702CE0069----000086A00001----011901CC00000005 Ultimeter 2000
*7007600000000 Peet Bros U-II
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 12: Weather Reports 63
Positionless Generic raw weather data from a stand-alone weather station is contained in
Weather Reports the Information Field of an APRS AX.25 frame:
Example
_10090556c220s004g005t077r000p000P000h50b09900wRSW
report derived from Radio Shack WX station data.
APRS Software A Weather Report may contain a single-character code S for the type of
Type APRS software that is running at the weather station:
d = APRSdos
M = MacAPRS
P = pocketAPRS
S = APRS+SA
W = WinAPRS
X = X-APRS (Linux)
Weather Unit A Weather Report may contain a 2–4 character code uuuu for the type of
Type weather station unit. The following codes have been allocated:
Dvs = Davis
HKT = Heathkit
PIC = PIC device
RSW = Radio Shack
U-II = Original Ultimeter U-II (auto mode)
U2R = Original Ultimeter U-II (remote mode)
U2k = Ultimeter 500/2000
U2kr = Remote Ultimeter logger
U5 = Ultimeter 500
Upkm = Remote Ultimeter packet mode
Users may specify any other 2–4 character code for devices not in this list.
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
64 Chapter 12: Weather Reports
Positionless The format of weather data within a Positionless Weather Report differs
Weather Data according to the type of weather station unit, but generically consists of some
or all of the following elements:
For example, Jim’s rain gauge may produce a report like this:
_10090556c...s...g...t...P012Jim
(The date/timestamp, wind direction/speed/gust and temperature parameters
must be included, even though they are not meaningful).
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 12: Weather Reports 65
Location of a Raw APRS cannot display weather data on a map until it knows the location of the
and Positionless sending station. In the case of a station transmitting Raw or Positionless
Weather Stations Weather Reports, the station has to occasionally send an additional packet
containing its position (using any of the legal lat/long and compressed
lat/long position formats described earlier).
Symbols with Raw Because Raw and Positionless Weather Reports do not contain a display
and Positionless symbol in the AX.25 Information field, it is possible to specify the symbol in
Weather Stations a generic APRS destination address (e.g. GPSHW or GPSE63) instead.
Alternatively, if the weather station is on a balloon, the SSID –11 may be
used in the source address (e.g. N0QBF-11).
See Chapter 20: APRS Symbols for more detail on the usage of symbols.
Complete Weather An APRS Complete Weather Report can contain a timestamp and location
Reports with information, using any of the legal lat/long and compressed lat/long position
Timestamp and formats described earlier. An APRS Object may also have weather
Position information associated with it.
Examples of report formats are shown below. Note that the Symbol Code in
every case is the _ (underscore). Also, the 7-byte Wind Direction and Wind
Speed Data Extension replace the cccc and ssss fields of a Positionless
Weather Report.
Bytes: 1 8 1 9 1 7 n 1 2-4
Examples
!4903.50N/07201.75W_220/004g005t077r000p000P000h50b09900wRSW
!4903.50N/07201.75W_220/004g005t077r000p000P000h50b.....wRSW
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
66 Chapter 12: Weather Reports
Bytes: 1 7 8 1 9 1 7 n 1 2-4
Example
@092345z4903.50N/07201.75W_220/004g005t-07r000p000P000h50b09900wRSW
Bytes: 1 1 4 4 1 2 1 n 1 2-4
Example
=/5L!!<*e7> _7P[g005t077r000p000P000h50b09900wRSW
Complete Weather Report Format — with Compressed Lat/Long position, with Timestamp
Bytes: 1 7 1 4 4 1 2 1 n 1 2-4
Example
@092345z/5L!!<*e7 _7P[g005t077r000p000P000h50b09900wRSW
Bytes: 1 9 1 7 8 1 9 1 7 n 1 2-4
Examples
;BRENDAVVV*4903.50N/07201.75W_220/004g005t077r000p000P000h50b09900wRSW
;BRENDAVVV*092345z4903.50N/07201.75W_220/004g005b0990
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 12: Weather Reports 67
Storm Data APRS reports can contain data relating to tropical storms, hurricanes and
tropical depressions. The format of the data is as follows:
Storm Data
;BRENDAVVV*092345z4903.50N\07202.75W@088/036/HC/150^200/0980>090&030%040
;BRENDAVVV*100045z4905.50N/07201.75W@101/047/HC/104^123/0980>065&020%040
National Weather APRS supports the dissemination of National Weather Service bulletins. See
Service Bulletins Chapter 14: Messages, Bulletins and Announcements.
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
68 Chapter 13: Telemetry Data
13 TELEMETRY DATA
Telemetry Report The AX.25 Information field can contain telemetry data. The APRS Data
Format Type Identifier is T.
The report Sequence Number is a 3-character value — typically a 3-digit
number, or the three letters MIC. In the case of MIC, there may or may not be
a comma preceding the first analog data value.
There are five 8-bit unsigned analog data values (expressed as 3-digit
decimal numbers in the range 000–255), followed by a single 8-bit digital
data value (expressed as 8 bytes, each containing 1 or 0).
The Kantronics KPC-3+ TNC and APRS Micro Interface Module (MIM) use
this format.
Bytes: 1 5 4 4 4 4 4 8 n
Examples
T#005,199,000,255,073,123,01101001
T#MIC199,000,255,073,123,01101001
On-Air Definition of In principle, received telemetry data may be interpreted in any appropriate
Telemetry way. In practice, however, an APRS user can define the telemetry parameters
Parameters (such as quadratic coefficients for the analog values, or the meaning of the
binary data) at any time, and then send these definitions as APRS messages.
Other stations receiving these messages will then know how to interpret the
data.
This is achieved by sending four messages:
• A Parameter Name message.
• A Unit/Label message.
• An Equation Coefficients message.
• A Bit Sense/Project Name message.
The messages addressee is the callsign of the station transmitting the
telemetry data. For example, if N0QBF launches a balloon with the callsign
N0QBF-11, then the four messages are addressed to N0QBF-11.
See Chapter 14: Messages, Bulletins and Announcements for full details of
message formats.
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 13: Telemetry Data 69
Parameter Name The Parameter Name message contains the names (N) associated with the
Message five analog channels and the 8 digital channels. Its format is as follows:
A1 A2 A3 A4 A5 B1 B2 B3 B4 B5 B6 B7 B8
PARM. N… ,N… ,N… ,N… ,N… ,N… ,N… ,N… ,N… ,N… ,N… ,N… ,N…
Bytes: 5 1-7 1-7 1-6 1-6 1-5 1-6 1-5 1-4 1-4 1-4 1-3 1-3 1-3
Example
:N0QBF-11V:[Link],Btemp,ATemp,Pres,Alt,Camra,Chut,Sun,10m,ATV
Note: The field widths are not all the same (this is a legacy arising from
earlier limitations in display screen width). Note also that the byte counts
include the comma separators where shown.
The list can terminate after any field.
Unit/Label Message The Unit/Label message specifies the units (U) for the analog values, and the
labels (L) associated with the digital channels:
A1 A2 A3 A4 A5 B1 B2 B3 B4 B5 B6 B7 B8
UNIT. U… ,U… ,U… ,U… ,U… ,L… ,L… ,L… ,L… ,L… ,L… ,L… ,L…
Bytes: 5 1-7 1-7 1-6 1-6 1-5 1-6 1-5 1-4 1-4 1-4 1-3 1-3 1-3
Example
:N0QBF-11V:UNIT.v/100,deg.F,deg.F,Mbar,Kft,Click,OPEN,on,on,hi
Note: Again, the field widths are not all the same, and the byte counts
include the comma separators where shown.
The list can terminate after any field.
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
70 Chapter 13: Telemetry Data
Equation The Equation Coefficients message contains three coefficients (a, b and c)
Coefficients for each of the five analog channels.
Message
Example
:N0QBF-11V:EQNS.0,5.2,0,0,.53,-32,3,4.39,49,-32,3,18,1,2,3
Bit Sense/ The Bit Sense/Project Name message contains two types of information:
Project Name
Message • An 8-bit pattern of ones and zeros, specifying the sense of each digital
channel that matches the corresponding label.
• The name of the project associated with the telemetry station.
B1 B2 B3 B4 B5 B6 B7 B8
x x x x x x x x Project Title
BITS.
Bytes: 5 1 1 1 1 1 1 1 1 0-23
Example
:N0QBF-11V:BITS.10110000,N0QBF’s Big Balloon
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 14: Messages, Bulletins and Announcements 71
Messages An APRS message is a text string with a specified addressee. The addressee
is a fixed 9-character field (padded with spaces if necessary) following the :
Data Type Identifier. The addressee field is followed by another :, then the
text of the message.
The message text may be up to 67 characters long, and may contain any
printable ASCII characters except |, ~ or {.
A message may also have an optional message identifier, which is appended
to the message text. The message identifier consists of the character {
followed by a message number (up to 5 alphanumeric characters, no spaces)
to identify the message.
Messages without a message identifier are not to be acknowledged.
Messages with a message identifier are intended to be acknowledged by the
addressee. The sending station will repeatedly send the message until it
receives an acknowledgement, or it is canceled, or it times out.
Message Format
Message ID
Addressee Message Text
(max 67 chars) Message No
: : { xxxxx
Bytes: 1 9 1 0-67 1 1-5
Examples
:WU2ZVVVVV:Testing A message for WU2Z, containing the text “Testing”,
no acknowledgement expected.
(Note the filler spaces in the 9-character addressee field).
:WU2ZVVVVV:Testing{003 The same message, Message No=003, acknowledgement expected.
:EMAILVVVV:msproul@[Link] Test email An e-mail message (Note: This is an example
of how such a message could be constructed.
APRS itself does not support e-mail delivery)
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
72 Chapter 14: Messages, Bulletins and Announcements
Message
Addressee No
: : ack xxxxx
Bytes: 1 9 1 3 1–5
Example
:KB2ICI-14:ack003
Message Rejection If a station is unable to accept a message, it can send a rej message instead
of an ack message:
Message
Addressee No
: : rej xxxxx
Bytes: 1 9 1 3 1–5
Example
:KB2ICI-14:rej003
Multiple If a station receives a particular message more than once, it will respond with
Acknowledgements an acknowledgement for each instance of the message.
If a station receives a message over a long path, it may respond with a
reasonable number of multiple copies of the acknowledgement, to improve
the chances of the originating station receiving at least one of the copies.
In either of these two situations, multiple message acknowledgements should
be separated by at least 30 seconds (this is because some network
components such as digipeaters will suppress duplicated messages within a
30-second period).
Message Groups An APRS receiving station can specify special Message Groups, containing
lists of callsigns that the station will read messages from (in addition to
messages addressed to itself). Such Message Groups are defined internally
by the user at the receiving station, and are used to filter received message
traffic.
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 14: Messages, Bulletins and Announcements 73
The receiving station will read all messages with the Addressee field set to
ALL, QST or CQ.
The receiving station will only acknowledge messages addressed to itself,
and not any messages received which were addressed to any group callsign.
Note: The receiving station will acknowledge all messages addressed to
itself, even if it is operating in an Alternate Net (see Chapter 4: APRS Data
in the AX.25 Destination and Source Address Fields).
General Bulletins General bulletins are messages where the addressee consists of the letters
BLN followed by a single-digit bulletin identifier, followed by 5 filler spaces.
General bulletins are generally transmitted a few times an hour for a few
hours, and typically contain time sensitive information (such as weather
status).
Bulletin text may be up to 67 characters long, and may contain any printable
ASCII characters except | or ~.
Bulletin
ID Bulletin Text
: BLN n VVVVV : (max 67 characters)
Bytes: 1 3 1 5 1 0-67
Example
:BLN3VVVVV:Snow expected in Tampa RSN
Announcements Announcements are similar to general bulletins, except that the letters BLN
are followed by a single upper-case letter announcement identifier.
Announcements are transmitted much less frequently than bulletins (but
perhaps for several days), and although possibly timely in nature they are
usually not time critical.
Announcements are typically made for situations leading up to an event, in
contrast to bulletins which are typically used within the event.
Users should be alerted on arrival of a new bulletin or announcement.
Announcement Format
Announcement
Identifier Announcement Text
: BLN x VVVVV : (max 67 characters)
Bytes: 1 3 1 5 1 0-67
Example
:BLNQVVVVV:Mt St Helen digi will be QRT this weekend
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
74 Chapter 14: Messages, Bulletins and Announcements
Group Bulletins Bulletins may be sent to bulletin groups. A bulletin group address consists of
the letters BLN, followed by a single-digit group bulletin identifier, followed
in turn by the name of the group (up to 5 characters long, with filler spaces to
pad the name to 5 characters).
Group Bulletin
ID Group Group Bulletin Text
: BLN n Name : (max 67 characters)
Bytes: 1 3 1 5 1 0-67
Example
:BLN4WXVVV:Stand by your snowplows Group bulletin number 4 to the WX group.
(Note the filler spaces in the group name).
A receiving station can specify a list of bulletin groups of interest. The list is
defined internally by the user at the receiving station. If a group is selected
from the list, the station will only copy bulletins for that group, plus any
general bulletins. If the list is empty, all bulletins are received and generate
alerts.
National Weather Standard APRS message formats can be used for a variety of other
Service Bulletins applications. For example, in the United States, special formatted messages
addressed to the generic callsign NWS-xxxxx are used to highlight map areas
involved in weather warnings, using the following format:
Bytes: 1 9 1 n
Example
:NWS-WARNV:092010z,THUNDER_STORM,AR_ASHLEY,{S9JbA
(Note: The “message identifier” {S9JbA at the end is for reference
only, as receiving stations do not acknowledge bulletins).
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 14: Messages, Bulletins and Announcements 75
NTS Radiograms APRS can be used to transport NTS radiograms. This uses the existing
APRS message format for backwards compatibility, by adding a 3-character
NTS format identifier Nx\ at the start of the APRS Message Text, as
follows:
N#\number\precedence\handling\originator\check\place\time\date
NA\address_line1\address_line2\address_line3\address_line4
NP\phone number
N1\line 1 of NTS message text
N2\line 2 of NTS message text
N3\line 3 of NTS message text
N4\line 4 of NTS message text
N5\line 5 of NTS message text
N6\line 6 of NTS message text
NS\Signature block
NR\Received from\date_time\sent_to\date_time
All of these fields comes from the ARRL NTS Radiogram form and are
described in the NTS handbook.
Each message line is addressed to the same station.
The N#\, NA\ and NR\ lines are multiple fields combined for APRS
transmission efficiency. The backslash separator is used so that conventional
forward slashes may be embedded in messages. (The backslash does not exist
in the RTTY or CW alphabets, so it therefore cannot appear in an NTS
radiogram).
Each line may be up 67 characters long, including the 3-character NTS
format identifier. Lines in excess of 67 characters will be truncated.
There is a maximum of 6 lines of NTS message text.
Note: The N#\, NA\, NS\ and NR\ fields are required. The others are
optional.
Serialization of each line is handled by the normal APRS Message ID
{xxxxx.
An APRS application is not required to understand or generate these
messages. The information can be read and understood in the normal
message display.
Obsolete Bulletin Some stations transmit bulletins and announcements without the : APRS
and Announcement Data Type Identifier. This format is obsolete. Some software may still
Format decode such data as a bulletin or announcement, but it should now be
interpreted as a Status Report.
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
76 Chapter 14: Messages, Bulletins and Announcements
Bulletin and Bulletins and announcements are seen as a way for all participants in an
Announcement event/emergency/net to see all common information posted to the group. In
Implementation this sense they are visualized as a mountain-top billboard or a bulletin board
Recommendations on the wall of an Emergency Operations Control Center.
Information that everyone must see is to be posted there. Information is
added and removed. Space is limited. Only so much information can be
posted before it becomes too busy for anyone to see everything. Thus things
are supposed to be posted, updated, and cleared to keep the big billboard
uncluttered and current with what everyone needs to know at the present
time. It should not be cluttered with obsolete information.
This can be implemented in an APRS display system as a “Bulletin Screen”.
Everyone has this screen, and anyone can post or update lines on this screen.
At any instant, everyone in the network sees exactly the same screen.
Everything is arranged and displayed in exactly the same way. Thus,
everyone, everywhere is looking at the same mountain-top billboard or
bulletin board. There is no ambiguity as to who sees what information, in
what order at what time.
To make this work, a number of issues should be considered:
• Sorting: Bulletins/Announcements are almost always multi-line, and
may arrive out of sequence. They must be sorted before presentation on
the Bulletin Screen, and re-sorted if necessary when each new line
arrives. This includes sorting by originating callsign and Bulletin/
Announcement ID.
• Replacement: Stations sending bulletins/announcements can send new
lines to replace lines sent earlier, re-using the original Bulletin/
Announcement IDs. (Note: It is only necessary to re-send replacement
lines. It is not necessary to re-send the whole bulletin/announcement).
Receipt of a new line with the same Bulletin/Announcement ID as one
already received from the same station should result in the existing line
being overwritten (replaced).
• Clearing: A user should be able to clear any or all of the bulletins/
announcements from the Bulletin Screen once he has read them. Any
bulletins/announcements that are still valid will re-appear in due course
because of the way they are redundantly re-transmitted.
• Alerts: On receipt of any new or replacement line for the Bulletin
Screen, an alarm should be sounded and re-sounded periodically until the
user acknowledges it. Thus, this vital information is “pushed” to the
operator. There is no excuse for not being aware of the current bulletin/
announcement state — this is important in the hurried and crisis-laden
scenario of an APRS event.
• Logging: Old bulletins/announcements should be logged in sequential
APRS log files in case they are subsequently needed.
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 15: Station Capabilities, Queries and Responses 77
Station Capabilities A station may define a set of one or more attributes of the station, known as
Station Capabilities. The station transmits its capabilities in response to an
IGATE query (see below), using the < Data Type Identifier.
Each capability is a TOKEN or a TOKEN=VALUE pair. More than one
capability may be on a line, with each capability separated by a comma.
Currently defined capabilities include:
IGATE,MSG_CNT=n,LOC_CNT=n
where IGATE defines the station as an IGate, MSG_CNT is the number of
messages transmitted, and LOC_CNT is the number of “local” stations (those
to which the IGate will pass messages in the local RF network).
Queries and There are two types of APRS queries. One is general to all stations and the
Responses other is in a message format directed to a single individual station.
Queries always begin with a ?, are one-time transmissions, do not have a
message identifier and should not be acknowledged. Similarly the responses
to queries are one-time transmissions that also do not have a message
identifier, so that they too are not acknowledged.
Each query contains a Query Type (in upper-case). The following Query
Types and expected responses are supported:
Query Type Query Response
APRS General — All stations query Station’s position and status
APRSD Directed — Query an individual station for List of stations heard direct
stations heard direct
APRSH Directed — Query if an individual station has Position of heard station as an APRS Object, plus
heard a particular station heard statistics for the last 8 hours
Directed — Query an individual station for All outstanding messages for the querying station
APRSM outstanding unacknowledged or undelivered
messages
APRSO Directed — Query an individual station for its Station’s Objects
Objects
APRSP Directed — Query an individual station for its Station’s position
position
APRSS Directed — Query an individual station for its Station’s status
status
APRST or Directed — Query an individual station for a Route trace
PING? trace (i.e. path by which the packet was heard)
IGATE General — Query all Internet Gateways IGate station capabilities
WX General — Query all weather stations Weather report (and the station’s position if it is
not included in the Weather Report)
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
78 Chapter 15: Station Capabilities, Queries and Responses
Bytes: 1 n 1 n 1 n 1 4
Examples
Query Typical Response
?APRS? /092345z4903.50N/07201.75W>
General query, with standard posit and status reply. >092345zNet Control Center
?APRS?V V34.02,-117.15,0200 /3402.78N11714.02W-
General query for stations within a target footprint >Digi on low power
of radius 200 miles centered on 34.02 degrees
north, 117.15 degrees west, with standard posit
and status reply. (Note the leading space in the
latitude, as its value is positive, see below).
?IGATE? <IGATE,MSG_CNT=43,LOC_CNT=14
General query for IGate stations, with a Station
Capabilities reply.
?WX? _10090556c220s004g005t077…
Query for weather stations, with a standard /090556z4903.50N/07201.75W>
Weather Report reply (without a position),
followed by a standard posit.
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 15: Station Capabilities, Queries and Responses 79
Directed Station Queries addressed to individual stations are in APRS message format (except
Queries that they never include a message identifier). The addressee is the callsign of
the station being queried.
The message text is the Query Type. This is followed optionally by another
callsign — this callsign does not need filler spaces as it is at the end of the
data.
Examples
Query Typical Response
:KH2ZVVVVV:?APRSD :N8URVVVVV:Directs=VWA1LOUVWD5IVD…
A query asking KH2Z what stations he
has heard direct.
:KH2ZVVVVV:?APRSHVN0QBFVVVV VVVV :N8URVVVVV:N0QBFVHEARD:V1V3V2V.V.V4V5V6
A query asking for the number of times
N0QBF was heard in each of the last
8 hours. (Note the trailing spaces in the
callsign following APRSH, padding the
callsign to 9 characters).
:KH2ZVVVVV:?APRSM :N8URVVVVV:Testing{003
A query asking KH2Z for any
unacknowledged or undelivered
messages for him. KH2Z responds
with all such messages.
:KH2ZVVVVV:?APRSO ;LEADERVVV*092345z4903.50N/07201.75W>
A query asking for KH2Z’s APRS Objects.
:KH2ZVVVVV:?APRSP /092345z4903.50N/07201.75W>
A query asking for KH2Z’s position.
:KH2ZVVVVV:?APRSS >092345zNet Control Center
A query asking for KH2Z’s status.
:KH2ZVVVVV:?APRST :N8URVVVVV:KH2Z>APRS,DIGI1,WIDE*:
A query asking KH2Z for a trace of the
route taken to reach him.
:KH2ZVVVVV:?PING? :N8URVVVVV:KH2Z>APRS,DIGI1,WIDE*:
The same query, using PING instead
of APRST.
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
80 Chapter 16: Status Reports
16 STATUS REPORTS
A Status Report announces the station’s current mission or any other single
line status to everyone. The report is contained in the AX.25 Information
field, and starts with the > APRS Data Type Identifier.
The report may optionally contain a timestamp.
Note: The timestamp can only be in DHM zulu format.
The status text occupies the rest of the Information field, and may be up to 62
characters long (if there is no timestamp in the report) or 55 characters (if
there is a timestamp). The text may contain any printable ASCII characters
except | or ~.
Examples
>Net Control Center without timestamp.
>092345zNet Control Center with timestamp.
Although the status will usually be plain language text, there are two cases
where the report can contain special information which can be decoded:
• Beam Heading and Power
• Maidenhead grid locator
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 16: Status Reports 81
Status Report with It is useful to include beam heading and ERP in packets in meteor scatter
Beam Heading and work. To keep packets as short as possible, these parameters are encoded into
Effective Radiated two characters, as follows:
Power
H = beam heading / 10
(H=0–9 for 0–90 degrees, and A–Z for 100–350 degrees).
P = ERP code.
40 2 1210 ; 4000 D
The HP value appears as the last two characters of the status text, preceded
by the ^ character — for example, ^B7 means a beam heading of 110
degrees and an ERP of 490 watts.
The HP value may be combined with the Maidenhead grid locator (as
described below), or with any other plain language status text.
Status Report with The Maidenhead grid locator may be 4 or 6 characters long, and must
Maidenhead Grid immediately follow the > Data Type Identifier.
Locator
All letters must be transmitted in upper case. Letters may be received in
upper case or lower case.
The Symbol Table Identifier and Symbol Code follow the locator.
If the report also contains status text, the first character of the text must be a
space.
A Status Report with Maidenhead locator can not have a timestamp.
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
82 Chapter 16: Status Reports
Bytes: 1 2 2 2 1 1 1-54
Examples
>IO91SX/G
>IO91/G
>IO91SX/-VVMy house (Note the space V at the start of the status text).
>IO91SX/-V ^B7 Meteor Scatter beam heading = 110 degrees, ERP = 490 watts.
Transmitting Status Each station should only transmit a Status Report once every net cycle time
Reports (i.e. once every 10, 20 or 30 minutes), or in response to a query.
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 17: Network Tunneling and Third-Party Digipeating 83
Third-Party APRS provides a mechanism for formatting packets that are to be transported
Networks through third-party (i.e. non AX.25) networks, such as the Internet, an
Ethernet LAN or a direct wire connection.
These networks do not understand APRS source, destination and digipeater
addresses, so it is necessary to send them as data, along with the original data
being transmitted.
Source Path Header Prior to sending an APRS packet into the third-party network, the APRS
address path is prepended to the Data Type Identifier and the rest of the
original data.
The prepended address path is known as the Source Path Header. It consists
of the source, destination and digipeater callsigns, with associated SSIDs.
The main purpose of introducing the Source Path Header is to allow
receiving stations on the far side of the third-party network to identify the
sender — this is needed when acknowledging receipt of a message, for
example. Knowledge of the source path is also useful in diagnosing network
problems.
Source Data
Path Type Rest of the original data
Header ID
Bytes: n 1 n
The Source Path Header may be in either of two formats, known as the
“TNC-2” format and the “AEA” format (so called because when TNC-2 or
AEA-compatible TNCs are operating in terminal MONitor mode they
automatically produce headers in these formats).
The APRS Working Group has agreed to move towards standardization on
the “TNC-2” format in future implementations.
In most cases, AEA TNCs will produce Source Path Headers in “TNC-2”
format when BBSMSGS is set to ON.
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
84 Chapter 17: Network Tunneling and Third-Party Digipeating
Example
WB4APR-14>APRS,RELAY*,WIDE:
(WIDE digipeater “unused”)
Example
WB4APR-14>RELAY*>WIDE>APRS:
(WIDE digipeater “unused”)
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 17: Network Tunneling and Third-Party Digipeating 85
Third-Party Header After a packet emerges from a third-party network, the receiving gateway
station modifies it (by inserting a } Third-Party Data Type Identifier and
modifying the Source Path Header) before transmitting it on the local APRS
network.
The modified Source Path Header is called the Third-Party Header.
Third-party Format
Third-Party
} Header Rest of the original data
Bytes: 1 n n
In a similar way to the Source Path Header, The Third-Party Header can be
in either of two formats: “TNC-2” or “AEA” format.
Example
WB4APR-14>APRS,RELAY,TCPIP,G9RXG*:
Example
WB4APR-14>RELAY>TCPIP>G9RXG*>APRS:
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
86 Chapter 17: Network Tunneling and Third-Party Digipeating
Action on When another station receives a third-party packet, it can extract the callsign
Receiving a Third- of the original sending station from the Third-Party Header, if it is needed to
Party packet acknowledge receipt of a message.
The other addresses in the Third-Party Header may be useful for network
diagnostic purposes.
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 18: User-Defined Data Format 87
The APRS protocol defines many different data formats, but it cannot
anticipate every possible data type that programmers may wish to send. The
User-Defined data format is designed to fill these gaps. Under this system,
program authors are free to send data in any format they choose.
The data in the AX.25 Information field consists of a three-character header:
{ APRS Data Type Identifier.
U A one-character User ID.
X A one-character user-defined packet type.
The APRS Working Group will issue User IDs to program authors who
express a need.
[Keep in mind there is a limited number of available User IDs, so please do
not request one unless you have a true need. The Working Group may require
an explanation of your need prior to issuing a character. If only one or two
data formats are needed, those may be issued from a User ID pool].
For experimentation, or prior to being issued a User ID, anyone may utilize
the User ID character of { without prior notification or approval (i.e. packets
beginning with {{ are experimental, and may be sent by anyone).
Important Note: Although there is no restriction on the nature of user-
defined data, it is highly recommended that it is represented in printable 7-bit
ASCII character form.
User User-Defined
ID Packet Type User-defined data (printable ASCII recommended)
{ U X
Bytes: 1 1 1 n
Examples
{Q1qwerty User ID = Q, User-defined packet type = 1.
{{zasdfg User ID undefined (experimental), User-defined packet type = z.
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
88 Chapter 18: User-Defined data Format
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 19: Other Packets 89
19 OTHER PACKETS
Invalid Data or To indicate that a packet contains invalid data, or test data that does not
Test Data conform to any standard APRS format, the , Data Type Identifier is used.
Packets
For example, the Mic-E unit will generate such a packet if it detects that a
received GPS sentence is not valid.
Bytes: 1 n
Example
,191146,V,4214.2466,N,07303.5181,W,417.238,114.5,091099,14.7,W/GPS FIX
Invalid GPS data from a Mic-E unit. The unit has interpreted the V character in the
received sentence to mean the data is invalid, and has stripped out the $GPRMC header.
All Other Packets Packets that do not meet any of the formats described in this document are
assumed to be non-APRS beacons. Programs can decide to handle these, or
ignore them, but they must be able to process them without ill effects.
APRS programs may treat such packets as APRS Status Reports. This allows
APRS to accept any UI packet addressed to the typical beacon address to be
captured as a status message. Typical TNC ID packets fall into this category.
Once a proper Status Report (with the APRS Data Type Identifier >) has
been received from a station it will not be overwritten by other non-APRS
packets from that station.
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
90 Chapter 20: APRS Symbols
20 APRS SYMBOLS
Three Methods There are three methods of specifying an APRS symbol (display icon):
• In the AX.25 Information field.
• In the AX.25 Destination Address.
• In the SSID of the AX.25 Source Address.
The preferred method is to include the symbol in the Information field.
However, where this is not possible (for example, in stand-alone trackers
with no means of introducing the symbol into the Information field), either of
the other two methods may be used instead.
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 20: APRS Symbols 91
@092345z4903.50N/07201.75W>088/036…
the forward slash / is the Symbol Table Identifier and the > character is the
Symbol Code (in this case representing a “car” icon) from the selected table.
The Symbol Table Identifier character selects one of the two Symbol Tables,
or it may be used as single-character (alpha or numeric) overlay, as follows:
In the generic case, a symbol from the Primary Symbol Table is represented
as the character-pair /$, and a symbol from the Alternate Symbol Table as
\$.
Overlays with Where the Symbol Table Identifier is 0-9 or A-Z (or a-j with compressed
Symbols in the position data only), the symbol comes from the Alternate Symbol Table, and
AX.25 Information is overlaid with the identifier (as a single digit or a capital letter).
Field
For example, in the uncompressed Position Report:
@092345z4903.50N307201.75W>…
the digit 3 following the latitude will cause the number “3” to be overlaid on
top of the “car” icon (Note: Because the symbol is overlaid, the > Symbol
Code here comes from the Alternate Symbol Table).
Similarly, to overlay a “car” icon with the letter “B” in a compressed
Position Report, the report will look something like:
=BL!!<*e7 >7P[
However, in a compressed Position Report, it is not permissible to use a
numeric Symbol Table Identifier (0-9) — compressed positions never start
with a digit. If a numeric overlay is required, the report must use a lower-case
letter instead (in the range a-j) as the Symbol Table Identifier. The lower-
case letter is then mapped to the digits 0-9 (i.e. a=0, b=1, c=2, d=3 etc).
Thus, in the compressed Position Report:
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
92 Chapter 20: APRS Symbols
=d5L!!<*e7 >7P[
the letter d maps to overlay character “3”.
As noted above, not all symbols from the Alternate Symbol Table may be
overlaid in this way — those that can be overlaid are marked as [with overlay]
in Appendix 2. This means that they are capable of taking an overlay, but
they do not necessarily need to have one. Thus, for example, the following
report uses the car symbol from the Alternate Symbol Table, but does not
display an overlay:
@092345z4903.50N\07201.75W>…
Symbols in the Where it is not possible to include a symbol in the Information field, the
AX.25 Destination symbol may be specified in the AX.25 Destination Address instead, using the
Address following generic destination addresses: GPSxyz, GPSCnn, GPSEnn,
SPCxyz and SYMxyz.
The characters xy and nn refer to entries in the APRS Symbol Tables. For
example, from the Primary Symbol Table, a tracker could use the Destination
Address GPSMVV or GPS30 to specify a “car” icon.
The character z specifies the overlay character (where permitted), or is a V
(space) — the space is a filler character, as all AX.25 addresses must be
exactly 6 characters long.
The GPS/SPC/SYMxyV and GPSCnn/GPSEnn addresses can be used
interchangeably. Thus, for example, GPSBMV , SPCBMV , SYMBMV and
GPSC12 all specify a “Boy Scouts” icon (from the Primary Symbol Table),
and GPSOMV , SPCOMV , SYMOMV and GPSE12 all specify a “Girl Scouts”
icon (from the Alternate Symbol Table).
Overlays with If the z character in a GPSxyz, SPCxyz or SYMxyz address is not a space,
Symbols in the it specifies an alphanumeric overlay character, in the range 0-9 or A-Z.
AX.25 Destination
Address Overlays can only be used with symbols from the Alternate Symbol Table
marked with the legend [with overlay].
For example, if the “car” icon is to be overlaid with a digit “3”, the
Destination Address will be GPSNV3.
However, even if the address is overlay-capable, it is not actually necessary
to specify an overlay; e.g. GPSNVV.
GPSCnn and GPSEnn symbols can not have overlays.
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Chapter 20: APRS Symbols 93
Symbol in the Where it is not possible to include a symbol in the Information field or in the
Source Address Destination Address, the symbol may be specified in the SSID of the Source
SSID Address instead:
SSID-Specified Icons in the AX.25 Source Address Field
SSID Icon SSID Icon
-0 [no icon] -8 Ship (power boat)
-1 Ambulance -9 Car
-2 Bus -10 Motorcycle
-3 Fire Truck -11 Balloon
-4 Bicycle -12 Jeep
-5 Yacht -13 Recreational Vehicle
-6 Helicopter -14 Truck
-7 Small Aircraft -15 Van
Symbol Precedence APRS packets should not contain more than one symbol. However, it is
conceivably possible to (erroneously) construct a packet containing up to
three different symbols.
For example:
In such a situation:
• The symbol in the Information field takes precedence over any other
symbol.
• If there is no symbol in the Information field, the symbol in the
Destination Address takes precedence over the symbol in the Source
Address SSID.
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
94 Appendix 1: APRS Data Formats
Bytes: 1 n 7 n
Sym Symbol
! or Lat Table Long Comment
= Code
ID (max 43 chars)
Bytes: 1 8 1 9 1 0-43
Bytes: 1 7 8 1 9 1 0-43
DF Signal Strength
Bytes: 1 8 1 9 1 7 0-36
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Appendix 1: APRS Data Formats 95
DF Signal Strength
Bytes: 1 7 8 1 9 1 7 0-36
Bytes: 1 4 or 6 1 n
$ …,…,…,…,…,…,…,…,…,…
Bytes: 1 25-209
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
96 Appendix 1: APRS Data Formats
Not used Not used GPS Fix NMEA Source Compression Origin
Value: 0 0 0 = old (last) 0 0 = other 0 0 0 = Compressed
1 = current 0 1 = GLL 0 0 1 = TNC BText
1 0 = GGA 0 1 0 = Software (DOS/Mac/Win/+SA)
1 1 = RMC 0 1 1 = [tbd]
1 0 0 = KPC3
1 0 1 = Pico
1 1 0 = Other tracker [tbd]
1 1 1 = Digipeater conversion
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Appendix 1: APRS Data Formats 97
Bytes: 1 9 1 7 13 43
Bytes: 1 3-9 1 13 43
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
98 Appendix 1: APRS Data Formats
Bytes: 1 8 1 9 1 7 n 1 2-4
Bytes: 1 7 8 1 9 1 7 n 1 2-4
Bytes: 1 1 4 4 1 2 1 n 1 2-4
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Appendix 1: APRS Data Formats 99
Complete Weather Report Format — with Compressed Lat/Long position, with Timestamp
Bytes: 1 7 1 4 4 1 2 1 n 1 2-4
Bytes: 1 9 1 7 8 1 9 1 7 n 1 2-4
Storm Data
Bytes: 1 5 4 4 4 4 4 8 n
A1 A2 A3 A4 A5 B1 B2 B3 B4 B5 B6 B7 B8
PARM. N… ,N… ,N… ,N… ,N… ,N… ,N… ,N… ,N… ,N… ,N… ,N… ,N…
Bytes: 5 1-7 1-7 1-6 1-6 1-5 1-6 1-5 1-4 1-4 1-4 1-3 1-3 1-3
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
100 Appendix 1: APRS Data Formats
A1 A2 A3 A4 A5 B1 B2 B3 B4 B5 B6 B7 B8
UNIT. U… ,U… ,U… ,U… ,U… ,L… ,L… ,L… ,L… ,L… ,L… ,L… ,L…
Bytes: 5 1-7 1-7 1-6 1-6 1-5 1-6 1-5 1-4 1-4 1-4 1-3 1-3 1-3
B1 B2 B3 B4 B5 B6 B7 B8
x x x x x x x x Project Title
BITS.
Bytes: 5 1 1 1 1 1 1 1 1 0-23
Message Format
Message ID
Addressee Message Text
(max 67 chars) Message No
: : { xxxxx
Bytes: 1 9 1 0-67 1 1-5
Message
Addressee No
: : ack xxxxx
Bytes: 1 9 1 3 1–5
Message
Addressee No
: : rej xxxxx
Bytes: 1 9 1 3 1–5
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Appendix 1: APRS Data Formats 101
Bulletin
ID Bulletin Text
: BLN n VVVVV : (max 67 characters)
Bytes: 1 3 1 5 1 0-67
Announcement Format
Announcement
Identifier Announcement Text
: BLN x VVVVV : (max 67 characters)
Bytes: 1 3 1 5 1 0-67
Group Bulletin
ID Group Group Bulletin Text
: BLN n Name : (max 67 characters)
Bytes: 1 3 1 5 1 0-67
Bytes: 1 9 1 n
Bytes: 1 n 1 n 1 n 1 4
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
102 Appendix 1: APRS Data Formats
Bytes: 1 2 2 2 1 1 1-54
Source Data
Path Type Rest of the original data
Header ID
Bytes: n 1 n
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Appendix 1: APRS Data Formats 103
Third-party Format
Third-Party
} Header Rest of the original data
Bytes: 1 n n
User User-Defined
ID Packet Type User-defined data (printable ASCII recommended)
{ U X
Bytes: 1 1 1 n
Bytes: 1 n
Agrelo Format
% Bearing
nnn /
Quality
n
Bytes: 1 3 1 1
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
104 Appendix 2: APRS Symbol Tables
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Appendix 2: APRS Symbol Tables 105
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
106 Appendix 2: APRS Symbol Tables
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Appendix 3: 7-Bit ASCII Code Table 107
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
108 Appendix 3: 7-Bit ASCII Code Table
Part 2: Codes 32–127 decimal (20–7f hexadecimal), including hex codes for shifted 0–9/A–Z
Dec Hex Char Shifted Dec Hex Char Shifted
32 20 V 40/41 (space) 80 50 P a0/a1
33 21 ! 81 51 Q a2/a3
34 22 " (inv commas) 82 52 R a4/a5
35 23 # 83 53 S a6/a7
36 24 $ 84 54 T a8/a9
37 25 % 85 55 U aa/ab
38 26 & 86 56 V ac/ad
39 27 ' (apostrophe) 87 57 W ae/af
40 28 ( 88 58 X b0/b1
41 29 ) 89 59 Y b2/b3
42 2a * 90 5a Z b4/b5
43 2b + 91 5b [
44 2c , (comma) 92 5c \
45 2d - (minus) 93 5d ]
46 2e . (dot) 94 5e ^
47 2f / 95 5f _ (underscore)
48 30 0 60/61 96 60 ‘ (grave accent)
49 31 1 62/63 97 61 a
50 32 2 64/65 98 62 b
51 33 3 66/67 99 63 c
52 34 4 68/69 100 64 d
53 35 5 6a/6b 101 65 e
54 36 6 6c/6d 102 66 f
55 37 7 6e/6f 103 67 g
56 38 8 70/71 104 68 h
57 39 9 72/73 105 69 i
58 3a : 106 6a j
59 3b ; 107 6b k
60 3c < 108 6c l
61 3d = 109 6d m
62 3e > 110 6e n
63 3f ? 111 6f o
64 40 @ 112 70 p
65 41 A 82/83 113 71 q
66 42 B 84/85 114 72 r
67 43 C 86/87 115 73 s
68 44 D 88/89 116 74 t
69 45 E 8a/8b 117 75 u
70 46 F 8c/8d 118 76 v
71 47 G 8e/8f 119 77 w
72 48 H 90/91 120 78 x
73 49 I 92/93 121 79 y
74 4a J 94/95 122 7a z
75 4b K 96/97 123 7b {
76 4c L 98/99 124 7c |
77 4d M 9a/9b 125 7d }
78 4e N 9c/9d 126 7e ~
79 4f O 9e/9f 127 7f DEL
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Appendix 4: Decimal-to-Hex Conversion Table 109
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
110 Appendix 5: Glossary
APPENDIX 5: GLOSSARY
Altitude 1. In Mic-E format, the altitude in meters relative to 10km below mean sea level.
2. In Comment text, the altitude in feet above mean sea level.
Announcement An APRS message that is repeated a few times an hour, perhaps for several days.
Announcement Identifier A single letter A-Z that identifies a particular announcement.
Antenna Height In NMEA sentences, the height of the antenna in meters relative to mean sea level.
(The antenna height in GPS NMEA sentences fluctuates wildly because of Selective
Availability, and should only be used if DGPS correction is applied).
APRS Automatic Position Reporting System.
APRS Data The data that follows the APRS Data Type Identifier in the AX.25 Information field and
precedes the APRS Data Extension.
APRS Data Extension A 7-byte extension to APRS Data. The Data Extension includes one of Course/Speed,
Wind Direction/Wind Speed, Station Power/Antenna Effective Height/Gain/Directivity,
Pre-Calculated Radio Range, DF Signal Strength/Effective Antenna Height/Gain, Area
Object Descriptor.
APRS Digipeater Path A digipeater path via repeaters with RELAY, WIDE and related aliases. Used in Mic-E
compressed location format.
APRS Data Type Identifier The single-byte identifier that specifies what kind of APRS information is contained in
the AX.25 Information field.
Area Object A user-defined graphic object (circle, ellipse, triangle, box and line).
ASCII American Standard Code for Information Interchange. A 7-bit character code
conforming to ANSI X3.4 (1968) — see Appendix 3 for character definitions.
AX.25 Amateur Packet-Radio Link-Layer Protocol.
Base 91 Number base used to ensure that numeric values are transmitted as printable ASCII
characters. To obtain the character string corresponding to a numeric value, divide the
value progressively by decreasing powers of 91, and add 33 decimal to the result at
each step. Printable characters are in the range !..{. Used in compressed lat/long and
altitude computation.
Bulletin An APRS message that is repeated several times an hour, for a small number of
hours. A General Bulletin is addressed to no-one in particular. A Group Bulletin is
addressed to a named group (e.g. WX).
Bulletin Identifier A single digit 0-9 that identifies a particular bulletin.
Destination Address field The AX.25 Destination Address field, which can contain an APRS destination callsign
or Mic-E encoded data.
DF Report A report containing DF bearing and range.
DGPS Differential GPS. Used to overcome the errors arising from Selective Availability.
DHM 7-character timestamp: day-of-the-month, hour, minute, zulu or local time.
DHMz 7-character timestamp: day-of-the-month, hour, minute, zulu only.
Digipeater A station that relays AX.25 packets. A chain of up to 8 digipeaters may be specified.
Digipeater Addresses field The AX.25 field containing 0–8 digipeater callsigns (or aliases).
Directivity The favored direction of an antenna. Used in the PHG Data Extension.
DX Cluster A network host that collects and disseminates user reports of DX activity.
ECHO A generic APRS digipeater callsign alias, for an HF digipeater.
Effective Antenna Height The height of an antenna above the local terrain (not above sea level). A first-order
indicator of the antenna’s effectiveness in the local area. Used in the PHG Data
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Appendix 5: Glossary 111
Extension.
ERP Effective Radiated Power. Used in Status Reports containing Beam Heading and
Power data (typically for meteor scatter use).
FCS Frame Check Sequence. A sequence of 16 bits that follows the AX.25 Information
field, used to verify the integrity of the packet.
GATE A gateway between HF and VHF APRS networks. Used primarily to relay long-
distance HF APRS traffic onto local VHF networks.
GGA Sentence A standard NMEA sentence, containing the receiving station’s lat/long position and
antenna height relative to mean sea level, and other data.
GLL Sentence A standard NMEA sentence, containing the receiving station’s lat/long position and
other data.
GMT Greenwich Mean Time (=UTC=zulu).
GPS Global Positioning System. A global network of 24 satellites that provide lat/long and
antenna height of a receiving station.
GPSxyz An APRS destination callsign that specifies a display symbol from either the Primary
Symbol Table or the Alternate Symbol Table. Some symbols from the Alternate
Symbol Table can be overlaid with a digit or a letter. Used by trackers that cannot
specify the symbol in the AX.25 Information field.
GPSCnn An APRS destination callsign that specifies a display symbol from the Primary Symbol
Table. The symbol can not be overlaid. Used by trackers that cannot specify the
symbol in the AX.25 Information field.
GPSEnn An APRS destination callsign that specifies a display symbol from the Alternate
Symbol Table. The symbol can not be overlaid. Used by trackers that cannot specify
the symbol in the AX.25 Information field.
HMS 1. In NMEA sentences, a 6-character timestamp: hour, minute, second UTC.
2. In APRS Data, a 7-character timestamp: hour, minute, second, zulu or local.
ICQ International CQ chat.
IGate A gateway between a VHF and/or HF APRS network and the Internet.
Information field The AX.25 Information field containing APRS information.
Item A type of display object.
Item Report A report containing the location of an APRS Item.
Killed Object An Object that an APRS user has assumed control of.
knots International nautical miles per hour.
KPC-3 A Terminal Node Controller from Kantronics Co Inc.
Longitude Offset An offset of +100 degrees longitude (used in Mic-E longitude computation).
LORAN Long Range Navigation System (a terrestrial precursor to GPS).
Maidenhead Locator A 4- or 6-character grid locator specifying a station’s position.
MDHM 8-byte timestamp: month, day, hour, minute (used in positionless weather station
reports).
Message A one-line text message addressed to a particular station.
Message Acknowledgement An optional acknowledgement of receipt of a message.
Message Group A user-defined group to receive messages.
Message Identifier A 1–5 character message identifier (typically a line number).
Mic-E Originally Microphone Encoder, a unit that encodes location, course and speed
information into a very short packet, for transmission when releasing the microphone
PTT button. The Mic-E encoding algorithm is now used in other devices (e.g. in the
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
112 Appendix 5: Glossary
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Appendix 5: Glossary 113
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
114 Appendix 5: Glossary
passes through, and will not digipeat the packet again if it has digipeated it already
within the last 28 seconds.
WPT Sentence A standard NMEA sentence, containing waypoints.
WX Weather.
Ziplan A cheap twisted-pair LAN connecting PCs via their serial I/O ports. Designed for use in
emergency situations.
Zulu UTC/GMT.
F = ( C x 1.8 ) + 32
C = ( F – 32 ) x 5
9
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Appendix 6: References 115
APPENDIX 6: REFERENCES
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
116 Appendix 7: Document Release History
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0
Appendix 7: Document Release History 117
APRS Protocol Reference — APRS Protocol Version 1.0 Document Version 1.0.1: 29 August 2000
118 Appendix 7: Document Release History
END OF DOCUMENT
Document Version 1.0.1: 29 August 2000 APRS Protocol Reference — APRS Protocol Version 1.0