APRS and AX.25¶

Protocols¶

At the data link layer, APRS uses AX.25 frames, as defined in AX.25 Link Access Protocol for Amateur Packet Radio (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 and APRS Specifications do not mandate a particular type of modem for the physical layer.

The AX.25 Frame¶

All APRS transmissions use AX.25 UI-frames, with 9 fields of data:

• Flag — The flag field at each end of the frame is the bit sequence 01111110 that separates each frame. A single flag can be both the end of one frame and the beginning of the next. Whenever it is necessary for a TNC to keep its transmitter on while not actually sending frames, the time should be filled with contiguous flags.

• Destination Address — Unlike Packet Radio, this is not used for the destination for the packet. This field is used in multiple ways for the different APRS data types. APRS data is encoded to ensure that the field conforms to the standard AX.25 callsign format (i.e. up to 6 upper case alphanumeric characters plus SSID). Most often it will be of the form APxxxx to identify the type of system that generated the packet. If the SSID is non-zero, it specifies a generic APRS digipeater path.

In accordance with the AX.25 specification, for UI frames, the C bit of the Destination SSID octet should be 1. Receiving applications must ignore it because this has not been done consistently.

• 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.

In accordance with the AX.25 specification, for UI frames, the C bit of the Source SSID octet should be 0. Receiving applications must ignore it because this has not been done consistently.

• Digipeater Addresses — From zero to 8 digipeater callsigns may be ncluded in this field. These can be actual station names but are usually aliases so you don’t need to know about the network topology.
  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 (DTI) 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.

Channel Access¶

APRS is designed for many stations to share a single frequency and transmit at unpredictable times. Obviously you should wait for the channel to be clear before transmitting. If everyone transmitted as soon as the channel becomes clear, there would be many collisions. These collisions can be minimized by waiting a minimum amount of time and then waiting a random amount of time. The technical term for this is p-persistent Carrier Sense Multiple Access (CSMA).

Channel Busy | ___ Random Delay | | PTT | Transmit Audio | ___ | TXDELAY | AX.25 Frame(s) | TXTAIL

Transmit timing is determined by 4 parameters with these traditional names and typical default values.

Some implementations use milliseconds, rather than units of 10 milliseconds, so read the documentation if not using the defaults provided by the application.

• For digipeated frames the transmission should begin immediately after the channel is clear. Having multiple digipeaters transmit at the same time is intentional to minimize the amount of time taken for the same packet. The strongest signal will win due to the FM capture effect.
• For other frames, SLOTTIME and PERSIST are used to generate a random delay to minimize the chances of two different stations starting to transmit at the same time. The process is:(a) Wait for channel to be clear (i.e. no signal detected by modem)

(b) Wait for SLOTTIME.

(c) If the channel is busy (i.e. signal detected by the modem), go back to step (a).

(d) Generate a random number in the range of 0 to 255. If it is less than or equal to PERSIST (Typically 25% probability), start to transmit. Otherwise go back to step (b).

For the typical default values, we have delays with the following probabilities:

The Push to Talk (PTT) control line is asserted.

The data can't be sent immediately because the transmitter takes a little while to stabilize and reach full power after being activated.

The HDLC "flag" pattern (0111110) is sent for a time period of TXDELAY. For historical reasons, going back to the 1980s, the configuration numbers are often expressed in 10 millisecond (mS) units so 30 actually means 300 milliseconds.

When sending with a hardware modem, you know exactly when the audio for the frame is finished so the transmitter can be turned off fairly soon after that. TXTAIL can be very small.

When sending audio out through a "soundcard" there is latency between sending an audio waveform to the audio output device and when the sound comes out. We can't be sure precisely when the queued up sound has been completed so we need to keep the PTT on a little longer. The HDLC "frame" pattern is also sent during this time to keep the channel busy.