Equipment

Since the basic premise of the PacketCluster is to use packet radio to enhance DX or contest operating, you shouldn't have to have expensive or elaborate packet equipment to use it, and indeed that's not necessary. This section covers some basic principles for selecting and setting up your station to operate with the system. If you have this manual, it probably means you have already connected to the network, but there are a lot of ways you can improve the reliability of your connection.

Just about any terminal can be used. You can pick up a surplus RS-232 terminal at a hamfest. While these lack memory and the convenience features of a computer-cum-software combination, the price can often be very attractive. Alternatively, just about any computer can be used, with an appropriate terminal emulation program. Even a VIC-20 or Tandy Color Computer can be used, with the right software. The best choice is either a program specifically designed for your TNC or a generic packet terminal program. YAPP is one of the simplest and most convenient generic programs for the IBM PC and compatibles, but virtually any BBS frequented by hams (and certainly HAMNET on CompuServe) has public domain or shareware packet terminal programs free for the downloading.

Virtually any TNC will do as long as it is TAPR TNC-2 compatible. All TNCs currently sold meet this requirement. If you are in doubt about a piece of used equipment, check the manual to be sure that the TNC has the command called AX25L2V2, so it is compatible with PacketCluster software.

Before leaving the digital side of things, a caution about RFI. Since you want to use the system while operating HF, it is important both that your computer or terminal don't interfere with your receiver, and that your transmitted signal doesn't bother your computer or monitor. Recently-manufactured computer and terminal equipment should bear a label confirming that it conforms to FCC Class A or B standards. Class B, for home use, is more stringent and better for our purposes, but regardless, you may still have interference problems. Each case is individual, but the cures are the usual things -- grounding, snap-on chokes on leads, added shielding inside the monitor case, and so on.

On the RF side, it is important to have good signals both ways between you and the node to which you choose to connect (see below). That means "full quieting" in FM terms, but with packet signals, that can be hard to define. The best way is to note what minimum S-meter reading from a local repeater means full quieting on voice, and set that as your goal for signal strength from the PacketCluster node.

For PacketCluster operation (and any packet BBS, for that matter), best operation results when all stations in contact with the node can hear each other well. Your TNC is designed not to transmit when receiving another station, a feature that prevents collisions, but you have to be able to hear everyone else connected to your node in order for this feature to be effective. As a practical matter, you should try to achieve the needed signal levels through means other than a highly-directive antenna, because a nice narrow pattern and high front-to-side ratio make it unlikely that you will be able to hear most stations in contact with your node, and vice versa. A vertical gain antenna of some sort, or even a simple ground plane, is ideal. If you can't hear well enough, add a pre-amp (you'll better hear all stations connected to your local node). If you aren't loud enough into the node, add an amplifier (all stations connected to your local node will hear you better). If you must use a Yagi, make it no more than five elements, preferably only 3 or 4. It's important to maintain at least a rough balance between receiving and transmitting capabilities - it's "hear and be heard."

In setting up your packet system, be sure to adjust the audio output level from the TNC and/or the input level of your transceiver so that you are neither over- or under-deviating. Either condition can disastrously affect the reliability of packet communications. If you can't get your deviation measured somehow, you can tune to a clear channel and adjust your audio level by listening to yourself in a second receiver. Use an AC voltmeter in the speaker or headphone jack of the second receiver, or just listen if you don't have one. Set things up so that the received signal is slightly less than full quieting. If the radio you use for packet has a touch-tone pad, press one or more of the pad keys and observe the voltmeter. Then send packets and gradually turn up the gain on your TNC and/or transmitter until the voltmeter reads the same as it did with the pad. Typically, the result will be 3 kHz deviation and optimum setting. If you don't have a touch-tone pad on your packet rig, just turn up the TNC or transmitter mike gain until you do not measure or hear any corresponding increase in the loudness of the received signal with added transmit audio gain (since this is FM, your S-meter will not/should not change). Finally, back off the transmit audio gain to just below the point where this flattening-out occurs. You should be close to right.

Choosing a Node

Start by locating the nearest PacketCluster node or relay node(see Chapter 1). All of the nodes on the system have high antennas and decent receivers. A lot of effort is going into ensuring that all nodes on the network have comparable reliability, so there is no reason to favor a faraway node over one closer to you. Distance is the most important factor affecting signal strength, so you should start with the closest node, this will help you to minimize hidden-transmitter problems.

The following are general rules of thumb for the needed equipment depending on your distance from the node (but please remember these are VERY dependent on terrain, etc.). Also, you can trade off antenna height for power to some extent, on either end of the link. The use of handitalkies is not recommended in any but the most exceptional circumstances, for stations literally within a stone's throw of a node.

Distance and Equipment needed

To test your set-up, the first thing to do is to monitor the node without connecting. Set MALL ON, MON ON and MCOM ON in order to see all packets being exchanged between the node and connected stations. If you are copying the node well (full quieting S-meter reading) and also hearing most of the stations talking to the node, then you're in fine shape. To further verify the quality of the link, connect to the node (at a time when it isn't busy - weekdays and early morning are best) and send <CR> to it. Observe the PTT and STA lights on your TNC. With a good link under unbusy conditions, the STA light should go out after the first time the PTT light indicates you've sent the <CR> packet. If your TNC doesn't have lights, set the RETRY parameter at 3 and see if you are disconnected because of excessive retries. If you routinely have to resend packets more than twice, the link isn't good enough. If you have good signal quality with more than one node, it is a good idea to pick the one that is usually less busy. When there are a lot of DX spots being put out, as during a contest for example, users on a node with over 12-15 users may find that they are disconnected because of excessive retries when they try to send a message (such as a DX spot) to the cluster. Some tinkering with parameters may help (see below).

While the network backbone has been extremely reliable, Murphy's Law remains operable, and because of the way the backbone is configured it is possible that a node could become isolated, even while the rest of the network continues to operate. To stay in touch under such circumstances, it's best to have identified at least two entry nodes that you can reach with acceptable reliability.

Recommended Parameters

While you don't need to be a packet guru in order to use a PacketCluster effectively, checking a few basics can be worthwhile, both for your own enjoyment and for the system's overall effectiveness. In general, the default settings of your TNC will be fine, but it is awfully easy to reset parameters while experimenting and forget you've done it. Some TNCs have things others don't, and the defaults vary a bit, as do the ways of setting parameters, but the following should be a general guide. Bear with us for a few minutes and check your parameters against the following list (the underlined part is what you need to enter at the "cmd:" prompt):

AX25L2V2 ON (default) - Ensures proper handling of retries between the node and the connected station.

BEACON EVERY 0 (default) - So that you don't send "CQ" messages on the node frequency every few seconds.

BUDLIST OFF (default) - To make sure you don't accidentally prevent yourself from reading packets from the node (you may laugh, but ...).

CANPAC $01 (control-A) (default is usually $19 or control-Y) - The PacketCluster uses control-Y to cancel a message without posting it, while your TNC normally interprets it as a command to cancel the current packet. Resetting it to control-A avoids this problem.

CHECK 0 (default typically 300 seconds) - This parameter tells the TNC to check and make sure if the other station is still there (by swapping packets every 5 minutes). There's no need for this feature with PacketCluster, so turn it off.

CR ON (default) - Together with SENDPAC $0D, this sends a carriage return character after each packet, which is particularly important when exchanging mail messages on the system to prevent formatting problems.

DWAIT 0 - This is important, because any other value will reduce throughput by adding a fixed delay before each retry between your station and the node. Its only purpose is to defer to digipeaters, and we don't want to encourage digipeaters on node frequencies. Default value is usually 16 - change it!

FRACK 4 (default usually 3 or 4 sec.) - The default value is usually fine here. You need a higher value when working through digis, but leaving it at the higher value when connected to a PacketCluster node only reduces throughput to and from you. On the other hand, cutting it much below the default may increase how often you're spontaneously disconnected from the node. If you discover that you are being spontaneously disconnected when your node is very busy, try increasing your FRACK 1 second at a time and see if that helps. You'll see that your TNC stops trying to transmit every time there's a momentary pause in node activity, so your messages don't get posted as quickly, but you'll be less likely to retry out.

LFADD OFF - This parameter should always be set to "OFF". If you get an error message "*** Unrecognized command ***" on all of your inputs to the system, this parameter may be set incorrectly.

MAXFRAME 4 (default 4, maximum 7) - Sets the maximum number of unacknowledged packets that your TNC can have outstanding. The default value is usually fine but can result in disconnects if a node is unusually busy.

MYCALL call - Be sure to set your call on your TNC so that the system will recognize you, to notify about new mail, etc.

PACLEN 128 (default is 128 bytes) - The default value is about right, although you can increase it for better throughput if you are satisfied that this doesn't result in increased retries with your local node.

PERSIST 80 (default is 63) - This parameter on many TNCs sets the probability of retransmission following a collision. A value of 80 may be slightly better, depending on individual circumstances. Must be used with the following parameter set ON.

PPERSIST ON (default is OFF) - On AEA TNCs, enabling this parameter permits more efficient collision avoidance.

RESPTIME n (default usually 500 ms.) - Sometimes varied as a means of randomizing retry intervals to cut down on collisions, but this should not be necessary with TNC-2 compatible TNCs. The Kantronics and AEAs use the PERSIST, PPERSIST and SLOTTIME parameters to accomplish this, while MFJs use randomized delays (multiples of the TXDELAY parameter). Try setting it at 0.

RETRY 10 (default 10) - OK to leave at 10, although you shouldn't need 10 retries, even under contest conditions. Good idea to set at 3 for the first few connects to your local node, until you can verify (at a time when the node isn't very busy) that signal quality both ways is good enough that retries aren't normally necessary. Never EVER set to 0, which permits infinite retries.

SLOTTIME 10 (default 10 ms.) - Together with PPERSIST ON, gives true Carrier-Sensed Multiple Access collision avoidance on AEA TNCs. The default value is probably fine.

TXDELAY 30 - Set for your particular transmitter, with an eye to minimizing it, because Txdelay is a drag on throughput. Some delay is needed, however, to allow for switching time in your rig. See how little you can live with, but don't reduce so far that you start getting frequent retries with your local node. Typically, the TXD parameter should be set to the desired delay (in milliseconds) divided by 10. In other words, TXD=25 would set the transmit delay to 250 ms.