o Find another station who can reliably digipeat your signals.
o Set your UNPROTO path to TEST via the callsign of the station who
can digipeat your signals.
o Set the MONITOR command to at least 1.
o Go to CONVERSE mode and send a few packets by pressing the
<Enter> key. Note that you should see them on your own screen
when they are digipeated by the other station.
o Start reducing TXDELAY by units of 5 each time making sure the
other station is still digipeating ALL your UNPROTO packets.
Eventually you will find a value where the other station can no
longer copy your packets to digipeat them.
o When this happens, increase TXDELAY in units of one or two until
the other station again digipeats ALL of your packets. This will
be the optimum setting of TXDELAY.
After TXDELAY is adjusted as indicated above you may want to adjust
the audio delay (AUDELAY) as indicated in the Command Summary.
The next sections of this chapter will discuss some of the more
advanced packet features including Multiple Connects, Packet Timing
and Protocol, and HF Packet Operation.
4.4.8.2 AXDELAY and AXHANG
Although it is not common, packet can be used through voice repeaters.
When sending packets through an audio repeater you may require a
longer key-up delay than is normally needed for direct communications.
The AXDELAY command adds more key-up delay in your PK-232 so that the
repeater can lock-up. The AXHANG command sets the time your PK-232
assumes is needed for the repeater to drop.
4.5 Packet Protocol Basics
Here we will talk a little about the AX.25 packet protocol. You do
not need to understand this to use packet, but it is helpful in
understanding the packet protocol parameters.
There are two modes of packet transmissions Connected mode and
Unconnected mode. Most of the time when you use packet, you will be
conversing with another packet station in Connected mode. Still the
Unconnected or Unprotocol mode comes in handy for beacon transmissions
and roundtable conversations.
All packets are constructed basically the same. Packets contain
source and destination callsigns (and any digipeaters if they are
used), as well as information identifying the type of packet. This
packet identification can be seen with the MONITOR command discussed
earlier. All packets contain an error check code called the CRC.
This ensures that when a packet is received, it will not contain a
single error. The command PASSALL can disable the CRC error check,
but this should only be done for experimental purposes only.
4/91 4-19
