APRS Message Protocol — How Short Text Messages Travel Across the Network

Most people think of APRS as a position-reporting protocol, but it has carried short text messages between operators since the very first releases in the early 1990s. APRS messaging is not a chat system in the modern sense — there are no rooms, no presence, no read receipts beyond a basic ACK — but it is genuinely useful for short, time-critical exchanges between two stations, and it works end-to-end across the worldwide network. Send a message to a friend's callsign from an iGated phone in Spain and, if their handheld is on the air in Argentina, they can read it within seconds.

This guide explains the on-the-wire format, the addressing rules, the 67-character body limit, the acknowledgment (ACK) and reject (REJ) semantics, the retry behaviour, and the practical pitfalls. It assumes you already know what an APRS packet looks like in general terms.

The Message Packet Format

An APRS message is just a normal APRS packet whose information field starts with a colon. The general shape is:

:ADDRESSEE:message body{msgno

Breaking that apart:

A complete example transmitted on the air:

TA4OHN-7>APRS::TA4OHN-9 :on my way home{42

Reads as: "TA4OHN-7 is sending a message to TA4OHN-9 with body 'on my way home' and message number 42." The recipient (TA4OHN-9) should reply with an ACK referencing message 42.

The 67-Character Body Limit

The body of an APRS message is limited to 67 characters. This is the single biggest practical constraint. It is not 140 like a tweet, not 160 like an SMS — it is 67. Where the number comes from is genuinely unclear. The information field itself can hold 256 characters, and the spec openly wonders whether 67 was simply inherited from hardware: Kenwood's TH-D7 stopped at 45 characters and the TM-D700 at 67. Longer message text does turn up on the air, so a receiver should cope with it rather than assume 67 is a hard ceiling. Text may be any printable ASCII or UTF-8, with one forbidden character: {, which marks the start of the message number.

Practical consequences:

Software like the APRS World mobile app shows you a live character counter and grays out the send button at 67 chars to prevent truncation.

The Addressee Field

The addressee is exactly nine characters. If the recipient's callsign is shorter, pad with spaces. Examples:

The padding is critical — a malformed addressee field will cause many clients to silently drop the packet. Most operators never type the padding themselves; the client software adds it.

A few special addressees have reserved meanings:

Sending to a normal callsign-SSID is the standard person-to-person case and is what 99% of operators do.

ACKs and the Message Number

If your message includes a {msgno suffix, the recipient's client is expected to send back an ACK as soon as the message is decoded. The ACK format is itself a tiny message:

:SENDER   :ackNN

Where NN is the message number from the original {msgno. Concretely:

TA4OHN-9>APRS::TA4OHN-7 :ack42

Reads as "TA4OHN-9 is telling TA4OHN-7 that it received message number 42." The ACK is itself just a regular APRS packet; no special wire encoding.

When the sender's client sees the ACK, it marks the message as delivered, stops retrying, and typically updates the UI to show a checkmark.

If the recipient's client cannot understand the message at all — for example because the body is malformed or the addressee field is wrong — it can send a REJ instead:

TA4OHN-9>APRS::TA4OHN-7 :rej42

REJ is rare in practice. Most clients silently drop unreadable messages rather than emitting REJ, which is technically wrong but operationally common.

Retry Behaviour

What happens when the sender doesn't see an ACK? Every client implements its own retry strategy because the protocol spec is loose. The de-facto standard, originally documented by Bob Bruninga and observed in most modern clients:

  1. Send the message immediately.
  2. If no ACK received within ~30 seconds, retry.
  3. Retry approximately every 60 seconds for the first ~5 minutes.
  4. Back off to every 5 minutes for the next ~30 minutes.
  5. Give up after roughly an hour with no ACK.

The exact intervals vary — Yaesu radios are more aggressive than Kenwood, APRSdroid uses its own schedule, the APRS World mobile app uses a configurable backoff. The shared principle: send several times early when the recipient might just be missing a single packet to fading, then back off to avoid clogging the channel.

When designing a message-retry implementation, two things matter most:

How Messages Cross the Internet

A message transmitted on local RF reaches an iGate within seconds. The iGate uploads it to APRS-IS. APRS-IS replicates it to every Tier 2 server. The recipient's client — whether a mobile app, a web page, or a TX-capable iGate near the recipient's radio — sees the message in the firehose, recognises the addressee, and either displays it or transmits it back out to RF.

A few subtleties:

ACK Storms and Other Edge Cases

A few things to be aware of:

Practical Tips for Operators

Where to Read More

APRS messaging is humble — 67 characters, best-effort delivery, no rooms — but for the specific use case of getting a short note to a specific callsign over a wide-area amateur network, nothing else in the hobby comes close.