[aprssig] Why KISS?

[J. Lance Cotton]

Larry Cerney wrote:
> Thanks for your answer.  Although I knew the added "whistles & Bells" for
> the everyday packet user, as you said, and I agree " It doesn't offer any
> advantage if all you wish to do is be a digipeater or "normal" node."
> 
>>From the lack of responses from the rest of the list I guess no one else
> sees KISS as a must have.  So I take it that KISS is just a feature that
> some TNC's support, but isn't a big deal.  

I actually do think it's a big deal. My MFJ-1270 has the KISS-only chip 
in it. I also have a TNC-X (Pic-based KISS-only "radiomodem") which 
works great.

I know there are others here on the list that feel KISS is very 
important -- do not let their silence indicate that no one else thinks 
it is important.

One other advantage for me is that my desktop and laptops at various 
times run various programs, from Digi-Ned to Xastir to Linux's TCP/IP 
over AX.25. Each program is set up to talk to a KISS mode TNC running at 
a serial-port speed of 9600 baud. This means that all of my TNCs are 
plug-and-play with all of my programs. No startup scripts. No "leftover" 
settings like "PASSALL", etc.

I wouldn't push for those who have a working setup to move to a KISS 
type setup just for the heck of it, but don't overlook the advantages of 
KISS that not moving may prevent from even happening. Several months 
back there was a big todo on the list about the OpenTRAC protocol -- a 
binary ax.25 protocol which can perform many of the same functions that 
APRS can/does, but with a different specification (whose big deal was 
that it was "NOT APRS"). Since it's a binary protocol, it's not human 
readable in raw format and the packet payload could contain (at random, 
essentially) characters that would normally appear in a text-based APRS 
packet (like the carriage return, or field seperator, etc.) This could 
be a "Bad Thing" for those APRS applications (APRS-IS, Kenwoods) which 
assume 7-bit clean data in APRS format *IF* the binary protocol appeared 
on 144.39 along with APRS.

*IF*, at one point, all APRS users had 8-bit clean hardware (i.e. KISS 
mode TNCs) and software that respected the type flag which would 
indicate non-APRS data, *THEN* something NOT-APRS could co-exist more 
peacefully on an AX.25 channel with APRS. (Note that we found that 
nearly 100% of APRS applications properly ignored packets that came in 
with a non-aprs type flag -- but this flag cannot be extracted unless in 
KISS mode or one specialized applications like UIDIGI. One can also set 
a normal TNC to filter non-aprs packet types in convers mode, but I 
would doubt that many folks have set theirs to do so. [heresay and 
conjecture!])

I'm not saying that this will ever happen -- but it most certainly will 
not if nobody ever changes from the old ways which make certain 
assumptions about the nature of the data and of the channel which may 
not hold today.

Another advantage of KISS mode is that the TNC itself doesn't know who 
itself is, so to speak. Meaning there can be more than one application 
accessing the serial stream and sending data "from" different callsigns. 
You can run Xastir and digi-ned at the same time, along with a PBBS 
system, and a remote system login with no (zero!) conflicts if you have 
the KISS tnc connected to Linux's ax25 system.

> I think I'll continue to run UI-View in no host mode and let my TNC do its
> thing.

That's fine, but don't give up on KISS entirely if you would like to see 
Packet radio and/or APRS (or other position-reporting protocol) progress 
with efficiency!

-Lance KJ5O

-- 
J. Lance Cotton, KJ5O
joe at lightningflash.net
http://map.findu.com/kj5o-12
Three Step Plan: 1. Take over the world. 2. Get a lot of cookies. 3. Eat 
the cookies.