[aprssig] Why KISS?
J. Lance Cotton
joe at lightningflash.net
Thu Dec 2 00:23:05 CST 2004
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
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
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
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
J. Lance Cotton, KJ5O
joe at lightningflash.net
Three Step Plan: 1. Take over the world. 2. Get a lot of cookies. 3. Eat
More information about the aprssig