Protocol

From APRSWiki
Revision as of 07:07, 17 August 2007 by We7u (Talk | contribs)

Jump to: navigation, search

Contents

APRS Protocol Information

Application Layer

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. APRS1.1 Addendum has been approved and APRS1.2 proposals are in work.

Some devices have additional methods of changing their beacon rate or paths based on various parameters:

Link Layer

The APRS protocol uses only the unconnected information frames from the AX.25 spec.

Physical Layer

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.

Computer Interface

There are three or more computer interface types to the radio.

  • TNC in CMD: mode
  • TNC in KISS mode
  • PC sound card with software TNC

KISS mode

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.

Personal tools