Protocol

From APRSWiki
(Difference between revisions)
Jump to: navigation, search
(Computer Interface)
(Application Layer)
 
Line 4: Line 4:
  
 
The APRS protocol itself is defined in the [http://www.tapr.org/aprs_working_group.html APRS Specification] prepared by the APRS Working Group.  There is also a collection of errata, addendums, recommendations, etc.
 
The APRS protocol itself is defined in the [http://www.tapr.org/aprs_working_group.html APRS Specification] prepared by the APRS Working Group.  There is also a collection of errata, addendums, recommendations, etc.
* [http://www.tapr.org/aprs_working_group.html APRS Specification]
+
* [http://aprs.org/doc/APRS101.PDF APRS Specification] or [http://www.tapr.org/aprs_working_group.html APRS Specification]
* [http://www.ew.usna.edu/~bruninga/aprs/aprs11.html APRS 1.1 Addendum] (Approved by the APRS Working Group)
+
* [http://aprs.org/aprs11.html APRS 1.1 Addendum] or [http://www.ew.usna.edu/~bruninga/aprs/aprs11.html APRS 1.1 Addendum] (Approved by the APRS Working Group)
* [http://www.ew.usna.edu/~bruninga/aprs/aprs12.html APRS 1.2 Proposals] (Not Approved as of yet)
+
* [http://aprs.org/aprs12.html APRS 1.2 Proposals] or [http://www.ew.usna.edu/~bruninga/aprs/aprs12.html 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:
 
Some devices have additional methods of changing their beacon rate or paths based on various parameters:
 
* [[SmartBeaconing]] and [[CornerPegging]]
 
* [[SmartBeaconing]] and [[CornerPegging]]
* [http://www.ew.usna.edu/~bruninga/aprs/ProportionalPathing.txt Proportional Pathing]
+
* [http://aprs.org/newN/ProportionalPathing.txt Proportional Pathing] or [http://www.ew.usna.edu/~bruninga/aprs/ProportionalPathing.txt Proportional Pathing]
  
 
=== Link Layer ===
 
=== Link Layer ===

Latest revision as of 14:54, 12 August 2009

Contents

[edit] APRS Protocol Information

[edit] 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.

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

[edit] Link Layer

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

[edit] 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.

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.

Kenwood TM-D700A/TM-D710A and TH-D7AG/E radios are capable of both 1200 and 9600 baud APRS operation.

[edit] 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

[edit] 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