APRS Protocol Information
The APRS protocol itself is defined in the APRS Specification prepared by the APRS Working Group. There is also a collection of errata, addendums, recommendations, etc.
- APRS Specification or APRS Specification
- APRS 1.1 Addendum or APRS 1.1 Addendum (Approved by the APRS Working Group)
- APRS 1.2 Proposals or APRS 1.2 Proposals (Not Approved as of yet)
Some devices have additional methods of changing their beacon rate or paths based on various parameters:
The APRS protocol uses unconnected information frames from the AX.25 spec.
APRS primarily uses 1200 baud Bell 202 audio frequency shift keying. The signal is modulated using two audio tones, as opposed to regular FSK, where the radio frequency carrier itself is shifted in frequency. Using FSK generally requires a DC-coupled connection directly to the radio's discriminator. AFSK has the advantage of working through a regular audio path, which makes it well suited for use with radios designed for voice.
The audio tones are 1200 hz and 2200 hz, with NRZI (non-return to zero inverted) encoding, which means that a 0 is encoded as a change in tone, and a 1 is encoded as no change in tone.
There are also 9600 baud APRS frequencies and equipment. Here is one 9600 baud packet radio modem design which implements it (there are others). Gain the specs and theory of operation from that link.
There are three or more computer interface types to the radio.
The KISS (Keep It Simple Stupid) protocol was created to allow an external device to perform many of the functions that are normally embedded into the firmware of the TNC. The KISS protocol causes the data flow to include all of the physical pieces of the AX.25 packet data, instead of just the text that is most commonly seen. The packet stream into and out of the TNC, when it is in KISS mode, is encoded using the specifications in KA9Q's original KISS Protocol document.
It is used a lot between computers and TNC's. It's not human-readable unless decoding software provides a dump of the raw bytes. It's used when more control is needed over a TNC than is available in the existing firmware. Plus, it can be more dependable over time for automatic control since the TNC's firmware is doing less to get confused about. No checksums are used between the TNC and the computer. Other variants have appeared since, namely SMACK, KISS-CRC, 6-PACK, KISS Multi-Drop/BPQKISS/XKISS, JKISS, MKISS, FlexKISS/FlexCRC/RMNC-KISS/CRC-RMNC. It appears that none of these protocols implement any form of hardware flow control. This is correct as specified in the original KISS document.