Table of Contents
Advertisement
PK-232 TECHNICAL MANUAL
2. Asynchronous Frame Format
The "asynchronous packet protocol" spoken between the host and TNC is very simple, since its on-
ly function is to delimit frames. Each frame is both preceded and followed by a special FEND
(Frame End) character, analogous to an HDLC flag. No CRC or checksum is provided. In addition,
no RS-232C handshaking signals are employed.
The special characters are:
Abbreviation
FEND
FESC
TFEND
TFESC
The reason for both preceding and ending frames with FENDs is to improve performance when
there is noise on the asynch line. The FEND at the beginning of a frame serves to "flush out" any
accumulated garbage into a separate frame (which will be discarded by the upper layer protocol)
instead of sticking it on the front of an otherwise good frame. As with back-to-back flags in HDLC,
two FEND characters in a row should not be interpreted as delimiting an empty frame.
3. Transparency
Frames are sent in 8-bit binary; the asynchronous link is set to 8 data bits, 1 stop bit, and no par-
ity. If a FEND ever appears in the data, it is translated into the two byte sequence FESC TFEND
(Frame Escape, Transposed Frame End). Likewise, if the FESC character ever appears in the user
data, it is replaced with the two character sequence FESC TFESC (Frame Escape, Transposed
Frame Escape).
As characters arrive at the receiver, they are appended to a buffer containing the current frame.
Receiving a FEND marks the end of the current frame. Receipt of a FESC puts the receiver into
"escaped mode", causing the receiver to translate a following TFESC or TFEND back to FESC or
FEND, respectively, before adding it to the receive buffer and leaving escaped mode. Receipt of
any character other than TFESC or TFEND while in escaped mode is an error; no action is taken
and frame assembly continues. A TFEND or TESC received while not in escaped mode is treated as
an ordinary data character.
This procedure may seem somewhat complicated, but it is easy to implement and recovers quickly
from errors. In particular, the FEND character is never sent over the channel except as an actual
end-of-frame indication. This ensures that any intact frame (properly delimited by FEND charac-
ters) will always be received properly regardless of the starting state of the receiver or corruption
of the preceding frame.
This asynchronous framing protocol is identical to "SLIP" (Serial Line IP), a popular method for
sending ARPA IP datagrams across asynchronous links. It could also form the basis of an asynchro-
nous amateur packet radio link protocol that avoids the complexity of HDLC on slow speed chan-
nels.
4. Control of the KISS TNC
Each asynchronous data frame sent to the TNC is converted back into "pure" form and queued for
transmission as a separate HDLC frame. Although removing the human interface and the AX.25
protocol from the TNC makes most existing TNC commands unnecessary (i.e., they become host
functions), the TNC is still responsible for keying the transmitter's PTT line and deferring to other
activity on the radio channel. It is therefore necessary to allow the host to control a few TNC pa-
PK232TM Rev. A 5/87
Description
Frame
End
Frame
Escape
Transposed Frame End
Transposed Frame Escape
APPENDIX B – KISS TNC Specification
Hex value
C0
DB
DC
DD
B-2
Page 71
Advertisement
Table of Contents
Troubleshooting
