What happens after you press Send on an APRS message
APRS messaging has a reputation for being unreliable. Most of it comes from not knowing what a message goes through after you send it, and from reading the marks beside it as either "worked" or "did not work". This post is for newcomers who have heard that reputation, and for APRS Connect users who want to read those marks correctly.
It covers the trip a message takes, the 67-byte limit, the six delivery states, the retry schedule, why an internet acknowledgement can beat your own radio echo, stopping a message, and the message detail screen. Everything here is free.
The trip a message takes
An APRS message is one packet. It carries your callsign, the callsign of the station you are writing to, the text, and usually a message number at the end. The receiving station answers with a short ack packet that quotes the number, and the ack takes the same kind of trip back. A message sent without a number cannot be acknowledged.
Over the radio, the packet goes out on the frequency and any digipeater named in its path repeats it. An igate that hears it forwards it to APRS-IS, the internet backbone that links igates and servers worldwide. From there it reaches a station connected directly to APRS-IS, or an igate near the recipient puts it back on the air. Over APRS-IS, the app sends the packet straight to a server. APRS Connect can use a radio, APRS-IS, or both at once.
The 67-byte limit
The text of an APRS message is limited to 67 bytes, and the compose box counts down against that limit as you type. Longer text is split into parts automatically. A multi-part message reports the state of its least-delivered part, so it does not claim delivery until every part has made it.
The six delivery states
Every message you send carries one of six states:
| State | What it means |
|---|---|
| Queued | Waiting for the channel |
| Sent | Handed to the radio or APRS-IS, not yet proof it was radiated |
| Digipeated | Your own packet came back through a repeater, proof it went out over the air |
| Delivered | The recipient acknowledged it |
| Rejected | The recipient explicitly refused it |
| Not delivered | Every attempt failed |
Two of these are often confused. Digipeated means the app heard its own packet come back through a digipeater. That is confirmed off the air, not guessed, and it proves the message was radiated, not that anyone received it. Delivered means the recipient's station sent an ack. A message can be repeated perfectly and still never reach a station that is switched off.
The retry schedule
The app waits 30 seconds for an ack, then sends again, doubling the wait each time up to a ceiling of five minutes, for six attempts in all. The last attempt waits the full five minutes before the message is marked Not delivered, and the message screen shows that countdown. Messages still in flight when the app is killed are resumed on relaunch.
A failed message shows a Retry button on the bubble, and the thread list flags the conversation. You can also retransmit any message: a pending one reuses the same wire ID, so a late ack still matches, while one that has already been answered goes out as a new message.
Radio, internet, or both
When a message goes out both ways, the ack usually arrives over the internet first, because APRS-IS is faster than a radio path. The app does not let that change the record of how the message was sent. Beside the delivery marks on each bubble is a glyph saying whether the message went by radio, by internet, or both. It reflects the send and stays the same through every later state, so a message sent both ways keeps showing both after the internet ack lands. The route the echo and the ack came back by is on the detail screen's timeline. A queued message shows no glyph.
Stopping a message
You can stop a message while it is retrying. Stopping is what you did; the delivery state is what the radio and the recipient did, and the two can disagree. So the app reports what happened: stopped in time, a copy already went out, a digipeater repeated it, or it was already delivered. On the bubble this reads as a bare Stopped when nothing got out, or as the state with Stopped added, such as Digipeated · Stopped. Retries stop, but the app keeps listening, so a message stopped too late can still come back Delivered.
What the app answers on its own
Incoming messages addressed to you are acknowledged automatically. Stations retransmit while waiting for an ack, so a duplicate of a message you already have is acknowledged again but does not notify you a second time. A blocked station's messages stop reaching your inbox and stop being acknowledged.
The message detail screen
Tapping a sent message opens its detail screen.
The message detail screen keeps the full history of one sent message, including every copy that went out and how it went.
The timeline lists every copy that went out, each with its time and whether it went by radio, by APRS-IS, or both. It is read back from the packet log, so copies the log has since pruned are counted rather than listed. The message's stamp shows the full date and time to the second, and a countdown appears during the final attempt. An icon in the header jumps to the packet in the packet log, where the Path taken graph marks the hops that repeated it and shows where APRS-IS routing took over from radios.
An incoming message gets a different detail screen: the path it took, whether it arrived by radio or the internet, whether an ack was requested, the stored frame, and a link into the packet inspector.
Where to read more
- Messaging covers the six states, retries, stopping and retransmitting, and the gateways.
- Packet log explains the packet inspector and the Path taken graph.
- FAQ has the short answer to "Why did my message say Digipeated but not Delivered?"
Everything in this post is free. The one related option that needs APRS Connect Pro is retry-when-heard, which lets a failed message wait for its station to be heard again.
