APRS is the packet radio application most hams have actually seen running: a map of nearby stations, mobiles moving along highways, weather stations, and short text messages between radios. It is also the busiest use of AX.25 on the air today.

This is the third post in the packet radio series. The first, Packet Radio: What It Is and What It Isn’t, covered AX.25 frames, modems and how stations share a channel. This one builds on that: what APRS puts in its frames, how those frames travel, why one channel can only carry so much, and what IGates add.

Frame type AX.25 UI (unconnected)
North American channel 144.39 MHz
Path rule WIDEn-N, N of 2 or less

01 · What APRS Is

APRS was designed by Bob Bruninga, WB4APR, and introduced at the 1992 TAPR/ARRL Digital Communications Conference [1]. The APRS Protocol Reference (Protocol Version 1.0, document v1.0.1) expands the name as Automatic Position Reporting System, and describes it as “a packet communications protocol for disseminating live data to everyone on a network in real time” [1]. APRS’s own website now uses Automatic Packet Reporting System [8], which better fits what it carries.

The positions on the map are only part of it. The same protocol carries:

  • Position reports from fixed, portable and mobile stations.
  • Objects and items: map markers placed by one station on behalf of something else, such as a net control point, an aid station or a road closure.
  • Weather reports from automated weather stations.
  • Telemetry from sensors.
  • Messages, bulletins and announcements addressed to a station, a group or everyone.
  • Status reports and replies to queries.

The design goal is a shared live picture. Every station transmits to everyone in range, so anyone listening builds the same picture without asking for it.

02 · Built on UI Frames

APRS uses AX.25 UI (unnumbered information) frames exclusively [1]. There’s no connection, no link-layer acknowledgement and no link-layer retry. A station sends a frame once, and every station in range either hears it or doesn’t.

That choice is deliberate. A connected session involves two stations; APRS wants every station to hear every report. The cost is that delivery is never guaranteed. APRS handles loss by repetition: positions and objects are re-sent on a schedule, so a missed report is replaced by the next one.

Messages are the exception. An APRS message can carry a message number, and the addressee answers with an acknowledgement that names it [1]:

:WU2Z :Testing{003 message to WU2Z, number 003, acknowledgement wanted
:KB2ICI-14:ack003 acknowledgement of message 003

The addressee field is always nine characters, padded with spaces, and message text is limited to 67 characters [1]. The sender repeats a numbered message until it’s acknowledged, cancelled or times out. Those acknowledgements are an APRS application feature carried in UI frames, not an AX.25 connection.

03 · What’s in an APRS Frame

The first character of the information field, the data type identifier, says what kind of report follows. A plain position report from the specification looks like this [1]:

!4903.50N/07201.75W-Test 001234

That’s latitude 49° 03.50′ N, longitude 72° 01.75′ W, a symbol table and symbol code (/ and -, a house), and a free-text comment. Optional extensions add course and speed, altitude, or PHG: power, antenna height, gain and directivity, which software can use to draw a station’s expected range [1].

Mic-E: Splitting a Report Across the Header

Mic-E is a compressed format, used by many APRS radios and trackers, that fits a full position report into a very short frame. It does this by using the AX.25 destination address as data [1]:

WhereWhat Mic-E puts there
Destination address (7 octets)The six latitude digits, a 3-bit message code, the north/south and east/west indicators, a longitude offset indicator, and the digipeater path code
Information fieldThe encoded longitude, course and speed, the symbol, and an optional telemetry or status field

The destination address still decodes as a valid AX.25 address, just not one that looks like a call sign. That’s why Mic-E packets look like gibberish in a raw packet monitor and need APRS-aware software to read.

04 · Getting Frames Further: WIDEn-N

On a single simplex channel, a mobile station with a low antenna only reaches nearby stations. Digipeaters extend that. As the first post explained, the sender lists in the frame’s path which relays it’s asking for, and each digipeater that relays the frame records that it has done so.

APRS paths use generic aliases instead of specific digipeater call signs. Under the New-N Paradigm, standardized around 2004, the alias is WIDEn-N: n is the number of hops requested, and N counts how many remain [2]. Each digipeater that relays the frame reduces the remaining count, so the frame stops after the requested number of hops.

The New-N page recommends one kind of path, WIDEn-N, with N no greater than 2 except in rare low-density areas that might handle 3 [2]. Its recommended paths:

StationPath [2]
General mobilesWIDE2-2
Local mobiles, where there are fill-in digipeatersWIDE1-1,WIDE2-1
Home stationsWIDE2-2 (or WIDE3-3 in distant rural areas of the eastern U.S.)

WIDE1-1,WIDE2-1 is still two hops. The WIDE1-1 step is answered by fill-in digipeaters, which are set to respond only to WIDE1-1 and are installed only where they’re needed, so a weak mobile can reach the main network [2]. The same page describes proportional pathing, in which a mobile sends many of its beacons with no path at all and uses longer paths less often [2].

Two separate mechanisms keep relayed frames under control. The hop count limits how far a frame can travel. Separately, a digipeater remembers frames it has recently relayed and ignores fresh copies of them, so the same frame arriving from two neighbours isn’t sent twice. Neither stops every duplicate, and exactly how a digipeater marks and rewrites the path depends on its software and configuration.

These rules replaced the older RELAY, WIDE and TRACE paths, which multiplied duplicate copies of every packet [2][3].

05 · The ALOHA Circle

Every relay of every packet uses the same 1200 bit/s channel. That makes APRS capacity a neighbourhood resource, and the APRS documentation is direct about the limit: a 144.39 MHz channel “can only support an average user load of about 60 to 100 or so average APRS stations or objects in an RF domain”, based on typical transmission rates and numbers of digipeaters and hops [3].

That figure counts stations and objects, not packets per minute, and it depends on the assumptions behind it. The area containing that many stations is your ALOHA circle. The guidance follows from it: your packets should reach the stations inside your ALOHA circle and go no further [3].

  • In dense areas the circle is small. The ALOHA page describes Southern California, where one hop may reach everyone, and notes that high-density areas “can only support WIDE2-2 and no more” [3].
  • In sparse areas the circle is large and more hops may be needed to reach anyone.
  • Tall digipeaters that hear too much are part of the problem. The documentation suggests limiting them to one hop, or moving their receive or transmit frequency [3].

A longer path doesn’t make a station easier to see. It makes the channel worse for everyone the extra copies reach.

06 · How Often to Beacon

The APRS specification describes a net cycle time: the time in which a listener should hear every station in range at least once. The stated goal is 10 minutes for local use, and the specification says all stations, even fixed ones, should beacon at the net cycle rate [1]. The net cycle time varies with local conditions and the number of digipeaters involved, so local networks often publish their own guidance.

Moving stations are different. A mobile beaconing on a fixed timer either wastes airtime parked or leaves gaps on the map while moving. Many trackers and radios adjust their rate to speed and heading instead, beaconing more often on the highway and when turning, and rarely when stopped. That technique is often called SmartBeaconing.

07 · IGates and APRS-IS

An IGate (Internet gateway) connects a local RF channel to APRS-IS, the internet network of APRS servers. That’s how map sites show stations from all over the world. The APRS-IS documentation gives an IGate two functions [4]:

  1. RF to internet: pass the APRS packets it hears on RF to APRS-IS. More precisely, all valid AX.25 frames with a control field of 0x03 and a PID of 0xF0 (UI frames with no layer-3 protocol) that didn’t originate on APRS-IS and aren’t generic queries.
  2. Internet to RF, on a bidirectional IGate only: pass message packets addressed to stations that are local to that IGate onto RF.

Some IGates are receive-only and do just the first. Packets that come from the internet go out on RF in a third-party format, and an IGate must never send them back to APRS-IS, which would create loops [4].

08 · The Rules That Apply

APRS operates under Part 97 like any other amateur data transmission. A few rules come up most:

  • Frequency. 144.39 MHz is the North American APRS channel by operating convention, not an FCC assignment. APRS’s own site says it “is dedicated throughout the continent”, with 144.80 MHz used in Europe and 145.175 MHz in Australia [8].
  • Identification (§ 97.119). Every APRS frame carries the sending station’s call sign and SSID in its AX.25 source address, which normally identifies it [5]. As with any packet station, an alias or a gateway that rewrites addresses deserves a closer look.
  • Unattended stations (§ 97.221). Digipeaters and IGates usually run with nobody at the controls. On 6 meters and shorter wavelengths, including 2 meters, § 97.221 allows a station to be automatically controlled while transmitting data [6].
  • Third-party traffic (§ 97.115). Messages an IGate brings in from the internet and transmits on RF are third-party communications, and § 97.115 sets the conditions for those [7].

09 · Primary References and Citations

  1. APRS Working Group, APRS Protocol Reference, Protocol Version 1.0, document v1.0.1, aprs.org. The 1992 introduction, UI frames, data types, position and message formats, Mic-E field layout, PHG and net cycle time.
  2. Bob Bruninga, WB4APR, Fixing Digipeaters: the New-N Paradigm, aprs.org/fix14439.html (archived copy). WIDEn-N, the recommended paths by station type, fill-in digipeaters and proportional pathing.
  3. Bob Bruninga, WB4APR, The APRS ALOHA Circle Concept, aprs.org/aloha.html. Channel capacity in stations and objects per RF domain, the ALOHA circle, and hop limits in dense areas.
  4. APRS-IS, IGate Design, aprs-is.net/IGating.aspx. IGate functions, the frames it gates, bidirectional gating and third-party packets.
  5. 47 CFR § 97.119, Station identification, eCFR.
  6. 47 CFR § 97.221, Automatically controlled digital station, eCFR.
  7. 47 CFR § 97.115, Third party communications, eCFR.
  8. APRS, APRS: Automatic Packet Reporting System, aprs.org. The current name, and the 144.39 MHz North American channel with the European and Australian frequencies.
Notebook

Key Takeaways

Everything Is a Broadcast

APRS sends every report as an unconnected UI frame to everyone in range. Lost packets are replaced by the next beacon; only numbered messages get acknowledgements, and those are an APRS feature, not an AX.25 connection.

Keep Paths Short

Keep N at 2 or less: WIDE2-2 for most stations, WIDE1-1,WIDE2-1 for mobiles where fill-in digipeaters exist. Every extra hop sends another copy of your packet across a channel your neighbours share.

Capacity Is Counted in Stations

A 1200 bit/s APRS channel carries roughly 60 to 100 average stations or objects in an RF domain, under typical assumptions. Your packets should reach your ALOHA circle and go no further.