|
Introduction
Overview
Computer requirements
Packet Engine Pro
Configure AGWPE
Download and Install
Basic AGWPE Setup
2 Radio Setup
2 Card Setup
Sound Device Setup
Basic Device Settings
Rename Sound Device
Additional Settings
Using the Tuning Aid
Problems?
Program Behavior
Receiving
Transmitting
Connections
Firewalls
AGWPE Features
AGWPE on a Network
Baud Rates & Modes
Remote Control
TCP/IP Over Radio
Tips and Tricks
Traffic Parameters
Compatible Programs:
Setup Help
Radio Interface
Getting Started
Kits and Pre-assembled
USB SignaLink
Receive Audio Cable
Transmit Audio Cable
PTT (TX Control) Cable
2 Radio Modification
About Packet
Packet Overview
Exchange Modes
TNCs and AGWPE
What
To Do with Packet
Common Frequencies
Frame Headers
Further Reading
|
|
Problems with Packet Connections
A. Connections not made
B. Connections not maintained
C. Slow Exchanges
D. Diagnosing Exchange Problems by
Packet Type
First, make sure you don't have an underlying
problem receiving or
transmitting.
- I can see on my radio that the
PTT has been opened and the radio is transmitting, but I can't
connect with another station.
- It looks like the other
station heard my connections request and is responding since the
radio is receiving packets, but AGWPE is not decoding the packets.
-
I'm having difficulty
connecting at 9600 baud.
Read the 9600 baud section of the Baud
Rates and Modes page for a discussion of the difficulties or
operating 9600 baud packet. Problems could be: your radio is not
9600 capable without modification; incorrect radio settings; using
audio transformers in the audio cables; and poor signal quality.
- I am having difficulty connecting
on HF at 300 baud.
Use the Sound Card Tuning Aid to help
tune your radio to the correct frequency. Also read the
300 baud section of the Baud Rates and
Modes page for a discussion of the difficulties or operating 300
baud packet.
- When I connect, the other
station (a BBS) immediately disconnects me.
You probably have Dual Port selected in the
port properties screen and probably have
the same baud selected for both ports. Try
changing the second port's baud rate to something other than the
first.
Better yet, if you are not using the second port, select
Single Port, close AGWPE, delete the
port1.ini file from the AGWPE folder
(retain port0.ini, do not delete it)
and restart AGWPE.
If you are using the second port (to run two different radios from
the same sound card) and want to use the same baud rate on both
channels, the only known solution is to reduce the receive (RX) audio
volume in both channels to the minimum needed to decode packets
reliably (find this setting through trial-and-error.) You can do
this with the volume control
recording sliders, but it may help to reduce the volume using
a voltage attenuator circuit in the
RX audio line; or if you are pulling the audio from the radio's
speaker jack, turn down the radio's volume control.
What seems to be happening is that there is not adequate audio
channel separation, i.e. cross-talk, in the sound card, so AGWPE
hears both radio ports. In the scenario above, port 1 asks
for a connection and the BBS sends a connect confirmation. Because
of cross-talk, AGWPE hears this on both port 1 and 2. Realizing this
is a problem, AGWPE sends a disconnect request, which the BBS accepts
and that is the message you see.
-
I can send and receive a few
packets, but pretty soon transmitting stops, especially if I try to send
packets too rapidly. This clears up if I close and restart AGWPE
and my packet application, but then it just happens again.
It may be that your computer isn't keeping up with the quick
switching that is taking place between the sound card and AGWPE. The
computer
may have missed a "hand shaking" data segment from AGWPE, so it's waiting for a
signal from AGWPE that will never come again. This may mean you need
a faster processor (or perhaps a sound card driver upgrade) to run
AGWPE, although you can try to cut the processor load by shutting down
other programs and background tasks. (George,
SV2AGW, talks about this problem on his web site.)
- The other station
doesn't seem to hear all my transmission, so my station is sending
many repeats.
Try disabling the Full Duplex mode of the card. On
the Sound Card Setup screen,
un-check
Full Duplex.
Some sound cards (usually older ones) have only one 16-bit and
one 8-bit channel, so they can not handle both receive and transmit
(i.e. full duplex) at 16-bit rates. They compensate by moving one function
-- usually transmit -- to the 8-bit channel where the audio signal is
not as good. By un-checking Full
Duplex, you force the card to alternate between receive and transmit,
but it will always use the 16-bit channel.
|
Can your sound card send and receive
simultaneously? In Windows, you can test for full-duplex
capability by launching two copies of Sound Recorder.
You'll find
Sound Recorder from the Start button:
Programs > Accessories
> Entertainment > Sound recorder
Repeat the process in the above
sentence to launch two copies of
the Sound Recorder. You can test for full duplex by playing a file on
one Windows Sound Recorder and, while that file is playing,
making a recording with the Sound Recorder.
Another way to test is with an AGWPE
debugging log. AGWPE asks soundcard drivers if they have
Full Duplex capabilities. To see the results of this query:
- Open the agwpe.ini file in Notepad
and edit the file to add these lines:
[DEBUG]
TRACE=3
- When AGWPE restarts it will create
an agwpe.log file. If you
open that file with noted pad, you should find a SOUND
CARD: FULLDUPLEX line that says either YES or NO, which
is the result of AGWPE's query of the card.
|
D. Diagnosing Exchange Problems by
Packet Type
The following suggestions are based on observations
which can be made by running AGWTerm:
(download from
the AGW Programs
page on this site).
When you use AGWTerm to make a connection with
another station, you can monitor ALL packets in the exchange by
selecting Window: Unproto Channel from the
AGWTerm menu. This will let you see supervisory packets not normally
seen in AGWTerm's "receive" window. The type of packet -- SABM, UA, I,
RR, REJ -- is identified immediately after the target or VIA
station's callsign in the packet, for example here is an RR packet:
1:Fm NM5RM To SV2AGW
<RR P/F R1 >
Remember to leave the Unproto
channel window and switch back to the the
Channel 1 window to resume your exchange with the other station,
since you can not send from the Unproto channel window.
-
I'm receiving many
REJ
packets.
Increase your
TXDelay parameter on the
TNC
commands tab of the Properties for Portx
screen.
- I'm sending many
REJ
packets.
Ask the other station to increase his
TXDelay.
- I'm seeing a RR packet
from the other station, then a RR packet from my station, and then
this repeats again and again.
The other station is not hearing your acknowledgement of a packet
it just sent you. Increase you transmitted audio (Wave "playback" in
the sound card volume control) or improve you transmitted signal
(higher power, better antenna).
-
I'm receiving many
RR
packets in the same transmission.
Increase your
FRACK
parameter on the TNC
commands tab of the Properties for Portx
screen. Consider letting AGWPE resume controlling the
parameter.
-
I'm sending many
RR packets
(R1, R2, R3, etc.) in the same transmission.
Increase your
RESPTIME
parameter on the
TNC
commands tab of the Properties for Portx
screen . Consider letting AGWPE resume
controlling the parameter.
- After receiving a burst
of data, AGWPE usually responds, for example, with "RR R3", "RR R4", "RR
R5", all in ONE burst. But with this one BBS, AGWPE frequently responds with
a short break between "RR R3" and "RR R4". During the break, AGWPE
releases the PTT and that results in the BBS sending more data. This new
data causes a collision with AGWPE's transmission of "RR R4", and the
whole packet exchange slows down dramatically. Why does AGWPE insert
that break?
This problem usually results when the sender -- the BBS in this
case -- isn't using the AX.25 ver. 2 protocol and has a PACLEN of less
than 255 characters. This creates a timing problem in the
acknowledgement of packets.
Since you are seeing multiple "RR"s, this means
you are probably setting the timing parameters yourself and not letting AGWPE control the timing (AGWPE would
probably only send
one "RR"). Increase the value of the
RespTime
until the problem goes away. Or select let the AGWPE "program adjust
parameters"
If your problem is not resolved by the problem solving pages on this
website, join the
AGWPE Yahoo Group to ask a question or search the archives for
previous postings that may relate to your problem:
http://www.egroups.com/group/SV2AGW
Troubleshooting page on this web site:
Program Behavior
Receiving
Transmitting
|