Protocol

From APRSWiki
(Difference between revisions)
Jump to: navigation, search
(Application Layer)
 
(21 intermediate revisions by 3 users not shown)
Line 3: Line 3:
 
=== Application Layer ===
 
=== Application Layer ===
  
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. APRS1.1 Addendum has been approved and APRS1.2 proposals are in work.
+
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://aprs.org/doc/APRS101.PDF APRS Specification] or [http://www.tapr.org/aprs_working_group.html APRS Specification]
 +
* [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://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)
  
* [http://www.tapr.org/aprs_working_group.html APRS Specification]
+
Some devices have additional methods of changing their beacon rate or paths based on various parameters:
 +
* [[SmartBeaconing]] and [[CornerPegging]]
 +
* [http://aprs.org/newN/ProportionalPathing.txt Proportional Pathing] or [http://www.ew.usna.edu/~bruninga/aprs/ProportionalPathing.txt Proportional Pathing]
  
* [http://eng.usna.navy.mil/~bruninga/aprs/aprs11.html APRS 1.1 Addendum]
+
=== Link Layer ===
  
* [http://eng.usna.navy.mil/~bruninga/aprs/aprs12.html APRS 1.2 Proposals]
+
The APRS protocol uses unconnected information frames from the [[AX.25|AX.25 spec.]]
  
 
=== Physical Layer ===
 
=== Physical Layer ===
Line 15: Line 20:
 
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.
 
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.  
+
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 also 9600 baud APRS frequencies and equipment.  Here is one [http://www.amsat.org/amsat/articles/g3ruh/109.html 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.
 +
 +
== Computer Interface ==
 
There are three or more computer interface types to the radio.
 
There are three or more computer interface types to the radio.
* TNC in CMD: mode
+
* [[TNC]] in CMD: mode
* TNC in KISS mode
+
* [[TNC]] in KISS mode
* PC sound card with software TNC
+
* PC sound card with software [[TNC]]
  
 
==KISS mode==
 
==KISS mode==
Line 28: Line 36:
 
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 [http://www.ka9q.net/papers/kiss.html KISS Protocol] document.   
 
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 [http://www.ka9q.net/papers/kiss.html 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, as specified in the original KISS 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.

Latest revision as of 13: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