

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

      In Part 3 of our series, we explored how a node broadcasts
 it's "Routes", and why this is important to the node. We also
 talked a little about how this information can be gotten from the
 node, and how it can be useful to you. We will continue here, and
 go further into how you can more effectively use network nodes.

      We have talked about how radio paths are not always 100%
 perfect, and how the route quality numbers can help you determine
 how good a path to a given node is. But how do you determine where
 you can go, and more importantly, how to get there?

      Remember that the node keeps a "Route Table" of nodes that it
 can reach. Each is assigned a quality number. This number is
 recalculated every time a route is rebroadcast through a node. For
 example, lets say that we have a Node called WAPR1 hearing a node
 with the alias of WAPR2. The path quality to WAPR2 is 160. Another
 node with an alias of WAPR3 hears the node WAPR1 with a route
 quality of 160. Node WAPR3 calculates the route to WAPR2 as being
 140. This is because there is a little bit of route quality loss
 evey time a route is passed through a node.

      Earlier we mentioned that a route quality of 150 and higher
 will probably be a fair-quality route. Not excellent, but usable
 under most circumstances. If a route is lower than 150, it will
 not be reliable. So, most nodes are set to ignore routes with a
 quality lower than 150. Routes with a quality of higher than 150
 are put on a "Nodes List".

      You may have already seen a "Nodes List". You can easily see
 this by giving a node the "Nodes" or "N" command. This will tell
 you every other  node that can be reached by the node that you are
 connected to. It lists both the Alias and the Call-Sign of these
 nodes.

      This Nodes List is updated automatically every hour. New
 routes are added when the nodes hears other nodes broadcasts, and
 old ones that are no longer heard are gradually deleted from the
 nodes list. Notice the word "Gradually". This does not happen
 right away, and an "Obsolete" route may remain on the nodes list
 for a few hours. This is a source of frustration for packeteers, a
 node may be on the list, but they can't connect to it. The node
 thinks this obsolete listing is there, but it may have faded out
 due to band conditions.

      How do we get deal with marginal or obsolete routes? First,
 use the "N" (Nodes) command sparingly. Sometimes, a rather sizable
 list of nodes  will appear when you invoke this command. This will
 not only give you a few "Obsolete" node listings, but it tends to
 congest the frequency you are on, not to metion other frequencies
 that a distant node or nodes may be on. When connected to a
 distant node, the R (routes) command may be a much better
 indicator of nodes that you can actually connect to.

      It is also helpful to know where a particular node is, and
 where it goes. Another node command, the I (info) command, will be
 most helpful. This will usually return one or two sentences
 telling you where the node is, perhaps who sponsors it, and
 sometimes what function it provides. This can help you pick your
 path by eliminating useless connections, ones that you do not need
 to make to get from point A to point B.

      Another thing that will help you navigate the network is
 careful observation. Keep an eye on your local Nodes List. Keep
 track of what nodes reliably appear on the list, and when they
 appear. Nodes that appear only in the early morning hours are
 probably not reachable at about 2 P.M. It is wise not to try
 connecting to them in the late morning hours, even if they are
 still on the nodes list. Remember, it takes a few hours for a
 route to become obsolete and disappear from the nodes list.

      Perhaps the most helpful suggestion that can be made about
 navigating the network with success is to use it carefully. If you
 like to log onto distant BBS's to check them out, use the features
 of the BBS to keep the  connection quick, and more reliable. This
 is done by keeping your packets short. This will also be
 appreciated by your fellow packeteers. Large packets may disrupt
 the connections of others using the network.

      This is an ideal time to talk about using distant BBS's with
 care. A large majority of BBS's in Wisconsin are similar. Note
 that they are networked together, and messages from one are
 forwarded to another, if they are for ALLUSA, RTWIS, or DIST9
 distribution. So it makes no sense to list all of the messages
 with the L command, because you will probably see the same
 messages on your local BBS. A much better option would be to use
 the L@ command. Let's say you are on a BBS with the call-sign if
 KB9ALN. Send the command L@KB9ALN and you will get messages that
 originate from that BBS only, instead of the same messages that
 can be read at your local BBS.

     Other "DX-BBS" hints:

 1) Send the BBS the "XS" command. This sends one line at a time,
    and makes for shorter, more reliable packets.
 2) Use the "X" command if you are very familiar with the style of
    BBS that you are on. This will give you a shorter command line.
 3) Use a variation of the X command to limit the number of lines
    that the BBS will send before pausing to ask you if you want
    more. X10 will tell the BBS to send 10 lines before asking you
    if you want more. NEVER tell a distant BBS to send a listing
    Continuously. This will probably kill your connection, and it
    may disrupt other traffic on the network.

      Keep this information in mind when you use the network. We
 will show practical examples of how to use this information in our
 next installment of "Using the Wisconsin Network".
 
 *End of Part 4*
