[aprssig] KISS TNC discussion

[Curt, WE7U]

On Tue, 1 Nov 2005, Andre PE1RDW wrote:

> KISS mode does not even care about crc, that is done in the computer or
> whatever kiss aplication you are running,

You're correct!  I checked the original KISS spec and there's only
one mention of the abbreviation "CRC".  That threw me for a bit.

I've always done KISS from the perspective of implementing decoding
for the AX.25 packet immediately on the processor, not from the
perspective of implementing a TNC, so I missed the simplified CRC
thing.  It certainly looks like you only have to do the frame
end/frame escape stuff and not worry about whether or not it's a
corrupted packet.

You should also drop packets from the computer if you can't handle
sending them right then, as the upper-level protocols are supposed
to worry about retries and such.  If the TNC loses them because it
can't process/send them right then, no big deal.

This means you only need a one byte buffer for received data, skip
checking the CRC altogether, and just insert frame ends and the
other few characters where necessary as you're spitting the packets
out to the computer.  The TNC is doing practically nothing in this
case.  Less than I thought it was doing as it doesn't need to
process the CRC.


> so convers mode would need the
> two frame buffer but kiss only needs one as the bare minimum.

Looks that way to me.  Of course the spec does say that a KISS TNC
should support 1024-byte packets at a minimum (it mentions packet
size, not info field size).  You'd need slightly more than double
that amount in order to handle outgoing packets:  One buffer to
queue up a packet that is waiting for a clear channel to be
transmitted, one buffer to queue up a packet being sent by the
computer.

Perhaps you could get by with only the one transmit queue and ignore
any bytes that arrive from the computer while you're waiting to
transmit, but that'd be poor design:  You'd lose too many packets.
Even cranking down the serial port speed wouldn't help much 'cuz
you'd lose the first few bytes at least of the next packet.

You'd need slightly more than seven times the buffer size if you
want to be able to handle a full window's worth of 1024-byte packets
heading out.

Figure 8k for the outgoing buffer minimum (but more is better), one
byte buffer for the incoming buffer, maybe a slight bit more if
you're running at the same speed on the serial port and have to
insert the KISS special chars here and there in the datastream.

--
Curt, WE7U.   APRS Client Comparisons: http://www.eskimo.com/~archer
"Lotto:    A tax on people who are bad at math." -- unknown
"Windows:  Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"