Re: KISS and experimental AX.25

["Barry McLarnon" <barry@skat.dgbt.doc.ca>]

>     I read an article ( 11/15/93 by Tom McDermott - n5eg ) in the TPRS 
> Quarterly Report this morning that talked about Error-Correction codes for 
> packet radio.  It got me to thinking...  does a KISS TNC pass all received 
> packets (including invalid ax.25 packets ) to NOS and NOS determines if the 
> packet is valid and send a REJ (if needed) or does the KISS TNC determine 
> that a packet is invalid and send a REJ frame?  If the KISS code sends all 
> packets to NOS....  NOS could be modified to run the error correction code 
> on invalid packets and attempt to correct them before sending an REJ frame.  
>     Also....  if you added data (changed the data structure) for an ax.25 
> SABM frame...  ( Bits for compression, encoding, etc ) will the KISS TNC 
> pass the SABM frame to NOS or will it decide it's an invalid packet and 
> REJ the SABM frame itself?  
>     I'm assuming that even if the KISS code handles some of the REJ frames
> itself... the KISS code on the TNC is still responsible for validating
> received packets and sending the REJ. The other alternative would be an
> even lower level TNC program validating the packet and sending valid
> packets to the KISS code and sending the REJ frame itself. 

The KISS code doesn't know a REJ from a fencepost... it just passes onto
the RS232 port anything which the USRT chip in the TNC declares to be a
valid received packet.  'Valid' in this context means that a sequence of
received data bits was properly framed by HDLC flags and passed the CRC
check (plus some other criteria wrt to length of packet, etc).  So,
packets containing bit errors won't, in general, be passed up to NOS.
Most conventional TNC firmware includes a command for turning the CRC
check off (usually called PASSALL y/n).  This could be added to KISS,
but it's not a great idea.  AX.25 with its HDLC base is a poor candidate
for doing Forward Error Correction.  What would be much better is a
data link protocol with a robust frame sync and fixed-length frames (no
bit stuffing).  Then you have a much better chance of framing packets
which are munged by bit errors... and you can do stuff like soft-decision
decoding and code combining to enhance the improvement from FEC.

This is certainly a big issue for HF data comms, where AX.25 is a real
dog.  At VHF/UHF, you generally have more options for improving the BER
by engineering better rf links... but as Phil has said many times, there
are cases such as interference from radar where FEC could be a big win.

Barry

-- 
Barry McLarnon    VE3JF/VA3TCP  |  Internet: barry@dgbt.doc.ca
Communications Research Center  |  AMPRnet:  barry@va3tcp.ampr.org
Ottawa, Ontario, Canada         |  FreeNet:  aa187@freenet.carleton.ca