Understanding APRS: Packet Structure, Digipeating Paths, and SSID Conventions for Ham Radio Trackers

If you've built an APRS tracker for a high-altitude balloon or set up an iGate with a Raspberry Pi and an RTL-SDR, you've already used APRS without necessarily knowing what's actually inside the packets flying across 144.390 MHz. Understanding the packet structure makes every piece of that stack — path selection, SSID choice, why your digipeater path sometimes does nothing — make sense instead of being settings you copied from someone else's config.

APRS Sits on Top of AX.25

APRS (Automatic Packet Reporting System) isn't its own radio protocol — it's a data convention layered on AX.25 packet radio, almost always transmitted as 1200-baud AFSK on 144.390 MHz in North America (different frequencies are standard in other regions). Every APRS packet is an AX.25 frame with specific content in the information field, which is what lets ordinary packet radio hardware carry APRS traffic without needing an APRS-aware radio.

Anatomy of a Packet

FieldWhat it holds Destination addressUsually a fixed APRS software identifier, not a real callsign Source callsign-SSIDThe transmitting station's callsign and SSID (see below) Digipeater pathA list of callsign-SSID aliases the packet should be repeated through Data type identifierA single character marking what kind of APRS data follows (position, status, message, etc.) Position/data fieldLat/long in a fixed-width NMEA-like format, plus a symbol table and symbol code that pick the map icon Comment fieldFree text — altitude, speed, course, or a custom message, depending on convention

SSID Conventions

The SSID is the number after the dash in a callsign like KC1ABC-9 — technically just a sub-station identifier in AX.25, but the APRS community settled on informal conventions for what each number usually means, which helps a receiving station or app guess what kind of station it's looking at before reading a single comment field.

SSIDCommon convention -0 (none)Primary station, no specific designation -1Digipeater (fill-in) -2Digipeater (alternate) -3 to -8Varies by local convention, often other fixed stations -9Mobile station (vehicle) -10Internet gateway (IGate) -11Balloon -12APRStt (touch-tone gateway) -13Weather station -14Truck/heavy vehicle -15Generic additional station

These are conventions, not protocol rules — nothing stops a station from using any SSID for anything, but following the convention makes your station behave predictably on everyone else's map.

Digipeating and the New-N Paradigm

A digipeater retransmits a packet to extend its range. Older APRS networks used fixed alias lists (specific digipeaters listening for their own named alias), but the modern standard is the "new-N paradigm": a path like WIDE1-1,WIDE2-1 tells any digipeater that hears it to repeat the packet once and decrement the hop count, so a fill-in digipeater handles the WIDE1-1 hop locally and a wide-area digipeater handles WIDE2-1 for longer reach. Each digipeater that repeats the packet substitutes its own callsign into the path so you can trace exactly which stations relayed it. A fixed station that's already within range of a reliable IGate often transmits with no path at all, since adding hops it doesn't need just adds unnecessary congestion to a shared, bandwidth-limited channel.

Where This Shows Up in Your Own Builds

Every APRS-capable build on this site — a balloon payload tracker, an iGate and digipeater, a Meshtastic-adjacent off-grid setup — is ultimately assembling and parsing exactly this packet structure under the hood. Knowing the fields means you can read a raw capture from an SDR or TNC log and understand what you're looking at directly, pick a sane digipeater path instead of copying one blind, and choose an SSID that won't confuse every receiving station's map display.

This is reference material, not a build guide on its own — pair it with this site's balloon tracker and iGate projects to put the packet structure to actual use on the air.