
           Using the Wisconsin Network - Part 12
                   by Andy Nemec, KB9ALN

     In the past editions of "Using the Wisconsin Network", we
have devoted a lot of discussion to using the various network
stations. We have also discussed, in basic terms, just how
these pieces work together. In this installment, we will go
backwards. Yes, we will look at the start of the network by
looking at your station. You see, the network starts at your
station, from your point of view, and from others as well.

     Why do we say this? Go back to what a node is (and what
it does) for your answer. A node is a sophisticated repeater
of packets that you, and the station you are connected to,
originate. If any of the stations using the network are not
set up correctly, a node gets busy, and in some cases can
sever a connection altogether.

     Looking at packet radio basics will tell show us why this
can happen.  Remember what the basis of packet radio is - the
sending of digital data by way of a shared radio channel. The
fact that packet radio data is sent in short bursts allows
several stations to use one frequency in the same time frame.
In fact, packet radio stations share time as much as they
share a frequency.

     Now let's review how packet becomes "error free" (or
nearly so). First, a line (or character) of text is sent from
your computer to the TNC. The TNC counts how many bytes of
data are being held in memory, ready to be sent out as a
packet. When the number of bytes gets to a certain value
(called the PACLEN), the TNC assembles a packet. When a packet
is assembled, it calculates a number, called a checksum. This
sending TNC assigns a sequence number to this packet, and
addresses it. Then, the TNC checks to see if the any other
stations are sending any packets on the frequency. It waits
for what it thinks is a good amount of time before 
transmitting. Finally, the TNC keys the transmitter and sends
the data to the transmitter in the form of audio tones.  When
the complete packet is sent, it unkeys the transmitter, and
waits.

    If receiving TNC can copy the packet, it converts the
audio tones back into data that the computer inside of the TNC
can use. It disassembles the packet, determines if the packet
meets the checksum, and if it is of the correct protocol.
Remember, most user stations use the AX.25 protocol, Nodes use
Net/Rom, and TCP/IP stations use TCP and IP. Then it replies
to let the sender know it's status.

    The receiving station replies in one of a few ways, if it
hears the packet. If the packet meets the checksum that is
sent with the packet, and the sequence number matches what it
is expecting, it checks to see if the frequency is clear. It
waits for what it considers a good amount of time, and
responds with a "Receiver Ready" packet. It also tells the
sender what the next expected packet will be numbered as. All
is well so far.

     If however, the packet is corrupted for some reason, or
it is a duplicate packet, the receiver will send a "Reject"
packet. If it fails the checksum, it tells the sender this.
Again, it tells the sender what sequence number of packet it
is expecting. If the packet is not of the expected protocol
(generally AX.25), then it sends a "Frame Reject". If it is a
serious protocol error, it will break the connection and make
you start over.  Protocol errors between two AX.25 packet
stations are rare, however, and are usually due to incorrectly
decoded packets.

     If the receiving station does not hear the packet, or if
the packet is so badly distorted that it cannot recognize it,
it does not reply.

     The sender is waiting for a reply, however, and a timer
determines just how long it will wait before it asks "Did you
get the last one?". If no reply is heard, and the timer
expires, it does just that. This is called "polling".

     While all of this might be "more than you really wanted
to know", it is important to understand in these basic terms.
Why? Look at all of the timing at work here. First, we divide
up time to allow several stations to use a given frequency.
The sender waits to send data. The receiver waits to
acknowlege the receipt of data. The sender waits a certain
amount of time before checking to see if the packet has
arrived. As with the rest of life, "Timing is Everything!".

     Consider what happens if a station sends a packet out,
and does not wait long enough for the receiver to reply. That
is a wasted packet. What happens if a receiver does not wait
long enough before acknowleging a packet? Some other station
will not get a chance to transmit a packet. What happens if
both stations do not wait long enough between transmissions,
or between polling? Then the frequency is virtually "locked
up" as long as these stations are connected!

     And that is where the network comes in. The network
starts with you, and your fellow packet operators. Remember,
we are all "time sharing", as well as frequency sharing.

     All of these timing parameters are configurable through
simple TNC commands. The sad fact is, the defaults that are
factory set are totally unrealistic in today's packet radio
environment. Most of these were decided on in the early 1980's
when packet radio was not nearly as well-populated as it is
now. Add to that the fact that a lot of TNC instruction
manuals are written in Techno-Babble, and it is no wonder that
we are all confounded and prefer to leave them as they are. We
could all be operating a lot more efficiently than we are now.

    And that is what the next installments of this series will
be about. We will discuss TNC parameters, what they mean, and
how to set them up in a cooperative manner.

   ***End of Part 12***
