[aprssig] KISS TNC discussion

[Curt, WE7U]

On Tue, 1 Nov 2005, Curt, WE7U wrote:

> 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.

Nope.  I was wrong on my first guess.  Something tells me I've been
down this road before as well.  If so it at least says my thought
processes haven't changed much, even if the memory is gone!

It's not obvious from the KISS Protocol spec what the TNC is
supposed to do w.r.t. the CRC.  In fact the spec says:  "the AX.25
protocol is removed entirely from the TNC", which is wrong, as it
has to have some knowledge of the frame end characters and the
checksum bytes and algorithm, plus on transmit it needs to implement
hold-off while the channel is busy and the proper timing.

Here's a good link:

http://www.a00.de/tcpgroup/1995/msg00048.php

Which mentions that a KISS TNC only sends frames up to the computer
which have passed the CRC check.  The good AX.25 frames that get
sent up as KISS frames do not include the CRC bytes at all.  There
are several places on the web that talk about this.

I looked at the Xastir code for Serial KISS interfaces:  There's no
mention of CRC there.  We don't check it in the Xastir code and we
don't even receive those bytes from the TNC.  I wrote that code but
it was a while back and I've since forgotten the data-gathering I
did for KISS/SMACK/6-PACK/etc. protocols at the time.

SMACK protocol TNC's add the CRC bytes back in so that the computer
can check the frame to assure it didn't get corrupted between the
TNC and the computer, something you can't do with KISS protocol.


> 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.

Now we're back to needing a complete buffer for a received frame
plus enough buffer for whatever is coming in from the radio while
we're dumping the first frame up to the computer (with a few extra
bytes inserted by the KISS protocol).  If the CRC-check fails you
dump the first packet.  You can still be ahead of the game a bit by
computing the CRC as the bytes are coming in.  If the serial speed
to the computer is at least slightly faster than the incoming radio
data speed you can get by with just a few bytes of extra buffer and
using a circular queue.


> 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.

Change that to 1k+ for the incoming buffer.

BTW:  One of the reasons I'm including all this from the previous is
so it is all in one place for future reference, a summary message.
I'm working on some KISS code for SmartPalm now and this will make
it easier to keep track of the useful bits.

--
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!"