Bufferless TNC.en

Siirry navigaatioon Siirry hakuun

A Bufferless (KISS) TNC is a TNC (radio terminal node controller) device that transmits heard bits as soon as possible without collecting a full frame in local memory at first.

A KISS TNC does convert a KISS encapsulated byte stream into HDLC bitstream (and back), and does also modulation of that bitstream to audio tones that are then fed to/from a radio. A bufferless processing will need a few bytes worth of buffers, but not entire frames. For example the verification of received HDLC frames requires that last two bytes of the frame are kept in the TNC's memory without sending them to host, and then observing a HDLC FLAG following those bytes is the way to give them a meaning of "these two bytes are CCITT-CRC16" of the preceding frame.

Because this TNC will send to host also data frames that are broken as received, the KISS serial link must be running in a mode that is able to indicate received frame to be bad. A few of such indication methods exist, "BPQ-CRC" is actually XOR-sum of bytes the preceding frame, SMACK is CRC16 checksum of the preceding frame. SMACK also puts special indication bit on KISS frame control byte so that both ends of the TNC-Host link can see that this is indeed a SMACK data frame.

This allows:

  • Minimal latency from heard bits on radio to bits in host memory
  • Indication that received frame was bad - by intentionally inverting the frame checksum data, or otherwise altering it from the valid one.
  • The "Bufferless KISS TNC" can be done without large local buffer, indeed it could be done on a hardware logic alone with small FIFOs.

This requires:

  • TNC-to-Host serial link must be faster than radio side data speed.
  • Serial link can serve only one modem, no KISS TNC multiplexing is possible.
  • Serial link communication must use SMACK checksumming to indicate (in-)valid frames

Transmitter forms a bit more challenge:

  • KISS/SMACK protocol can be used to set a few operational parameters to TNC
    • A few bytes of FIFO on TNC serial port receiver can be used to buffer these control sequences so that no actual transmit needs to start at first received KISS frame delimitter byte.
  • There must be some sort of flow control to
    • Observe a real data-to-be-transmit frame beginning
    • Hold off the Host-to-TNC character flow in order to start transmit only to clear radio channel. In practice this means CTS signal from TNC to host.
  • At possible Host-to-TNC serial link under-run of bytes to be sent the TNC must then:
    • Terminate transmit with invalid CCITT-CRC16 for it, an end-flag and releasing the PTT after configured hold-off time, so that receiving systems can detect the frame to be bad.
    • Enter KISS sync hunt mode to find next frame delimiter byte, and to try to send next real frame


  • No need for full frame buffer storage in the TNC.
  • Very low latency from packet reception to its processing at host.
  • Very low potential latency for packet transmit.
  • Will report also partially heard frames, which can then be used to better estimate channel occupancy (alias Erlang), or otherwise monitor what is heard on channel, including broken frames.


  • Host must understand used checksum scheme.
  • Can not be used without the checksum scheme at all.
  • Transmit requires CTS flow control signal from TNC to Host, 3-wire serial connection is not enough, and host software must use modem flow control.
  • There can be only one TNC on any given serial port, no multiplexing is possible.

See also: