More about AGWPE
Kits and Pre-assembled
Receive Audio Cable
Transmit Audio Cable
PTT (TX Control) Cable
2 Radio Modification
2. AGWPE Set Up
Download and Install
Basic AGWPE Setup
2 Radio Setup
2 Card Setup
3. Sound Card Setup
4. Windows™ Setup
6. Using AGWPE
AGWPE on a Network
Baud Rates & Modes
TCP/IP Over Radio
Tips and Tricks
7. Compatible Programs:
8. Packet Reference
TNCs and AGWPE
What to do with Packet
Sound Card Mechanics
Problems with Transmitting
As you troubleshoot transmit problems,
remember that AGWPE provides you this visual aid:
- If AGWPE receives a packet transmission
request from a client application and then successfully passes that
packet to the sound card and radio for transmission, the
red light in the transmitting
radioport's modem icon will flash once
and your radio should transmit.
To Force a Transmission through AGWPE, use
version) program to send a QRA packet: From AGWTerm tool bar, press the
"Tower & Question mark" button, and then select the
radioport you want to test.
make sure you are using the latest version of AGWPE before troubleshooting problems. Your problem
may have been fixed in the most recent version of AGWPE!
1. Radio Doesn't transmit
Radio Locks in Transmit mode
3. Intermittent Transmissions
4. No audio or poor audio on transmit
1. Radio Doesn't Transmit
- A. No Red Light Seen: My application program sent a packet, but I do
the red light in the AGWPE modem icon indicating it has transmitted
the packet to the radio.
- Make sure the radio's is
ON and the squelch is fully open at all times.
to hear the frequency noise level at all times -- no squelching! --
otherwise it may not transmit.
- Make sure you application program is correctly linked to
AGWPE. See the Program Behavior
page about Linking to
- Make sure the application
program really is requesting a packet transmission. For example, a terminal
program will not send anything if it is linked to AGWPE in COMMAND
mode (unless you use the CONNECT or DISCONNECT commands). Try a CONNECT
command if you are not yet connected or go to CONVERSE mode (K)
if you are connected.
Red Light is Seen: I saw the
red light blink in the AGWPE
modem icon, but the radio isn't transmitting.
- First try closing and restarting the packet application and
or try rebooting.
- If you are using a hand held radio:
- Remember that, in addition to the usual PTT
circuit components, you will still need all the PTT components
recommended by the radio manufacturer for MIC and Speaker jack
data use. Many handhelds need a capacitor on
the TX audio line between the radio and the PTT gate
circuit (as well as a resistor on the PTT line). Without
that capacitor, the PTT circuit may be active at all times.
- If the manufacturer says to use a stereo
plug for the radio's MIC jack, don't use a mono plug!
- You may have a wiring problem in the PTT cable.
Double check the wiring, components, and circuit routing:
- the PTT line from the radio must not touch the
shield or ground before it gets to the transistor or optocoupler.
- the PTT line must be wired to the correct
pin on the transistor or optocoupler. See PTT Cable
for a schematic. If the PTT closes
when AGWPE transmits, then you most likely have the
transistor or optocoupler wiring inverted. (You can
test your cable and circuit by using a 9 volt battery to
simulate the computer RTS line: plug the PTT cable into the
radio and on the computer end of the cable, apply the
positive side of the battery to the #7 pin (RTS ) pin and
the negative side to the #5 pin (Ground). This should close
the transistor/optocoupler gate and the radio should
- Windows can start up leaving the COM port
handshaking lines "high" (with voltage) instead of "low" as it
should. This seems to be limited to ound card interfaces that
are wired to use the DTR line to key the transmitter (many
commercial interfaces are wired to use either the RTS or DTR
line for PTT keying). This has been reported happening with
Windows ME and XP; also in other versions of Windows when using
a USB-to-Serial Port Adapter.
For Windows ME:
Look first on the Microsoft web site for a
Windows fix; see
Or Roger Barker, G4IDE/SK, wrote a
free 20 kb utility, HSOFF,
that can be used to reset the handshaking lines of a COM port if
they are left "high". HSOFF come in a zip
file that includes a .TXT file of instructions. (Note that the
program needs the Microsoft runtime libraries MSVBVM60.DLL and
MSCOMM32.OCX to run. These libraries are installed if you
install UI-View32; and
they are also available at some web sites -- do a web search to
For Windows XP: Although I
couldn't find verification of this problem on the Microsoft web
site, it have been said that when Windows XP boots up, it
too may leave the DTR (Data Terminal Ready) line of the serial
port in a HIGH state. The supposed fix for this is problem is to
go to the Device Manager within
Windows XP and remove all of the Communication Ports, or COM
ports, as listed under "Ports (COM & LPT)". After doing that,
re-boot Windows XP and it will re-install all of the drivers for
- It's possible that some other device is
affecting the COM/LPT port you have chosen for PTT control. For example, one user forgot that he
had an unused adapter "installed" in Windows that was
conflicting with the PTT port.
Another user reported a conflict with the Palm HotSync Manager, which
loads on startup and puts the COM RTS
pin high; Windows didn't report that the COM port
was being used by the Palm device driver, but it was. Still
another user had both the COM port and an infrared port assigned
to the same IRQ. Another user suggested that, if your XP
machine is running an NVIDIA graphics adapter, some of its drivers
are reported to tie up COM1 for no reason -- so disable Nview 2.0.
- Try disabling the Full Duplex mode of the card. On
the Sound Card Setup screen,
un- check Full Duplex.
- On older/slower computers, the default sound
card sampling rate may be too high for the computer to process. You
can try using the Windows Control
Panel to adjust the soundcard hardware acceleration
and sample rate quality until you find an optimum setting (For
Windows XP, you get there by clicking on
Audio Devices, then
click on the Audio tab.
Under Sound Playback, click
on the Advanced
click on the Performance
- On newer sound cards with digital
volume settings, too low a setting may cause the PTT function to
- Sometimes AGWPE will not transmit immediately if AGWPE's automatic timing features are in effect.
AGWPE monitors the frequency and uses "slotting"
to send your packet when the frequency is not
likely to be busy. So, AGWPE is holding the packet for a few
seconds before transmitting it.
If this delay really bothers you, you can override this feature by setting the timing parameters
yourself. Call up the
screen for the radioport, click on the the
tab, select Let
me Control Parameters. , and then change the Persist and Slot
parameters. But remember that AGWPE
usually does a very good job of adjusting the timing to match traffic
conditions on the frequency. You may make matters worse by
controlling them yourself. For example, you may not be as
prompt to change parameters when frequency traffic changes.
Another reason for a transmit delay is if the sound card is
busy processing other sounds from Windows or your
application programs. For example, UI-View has an option to announce
received callsigns and this slows everything down. Usually there is an option to turn these
sounds off in the application, as there is for Windows' sound
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 the packet application, but it just happens
Solution: This seems to happen
mostly on computers with older processors.
It's possible your computer isn't keeping up with the quick
switching that is taking place between the sound card and AGWPE. The
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. Also, see the paragraph above
about interruptions of the packet stream.
- Note: If
transmitting works for a while but then stops, your computer's power
management settings may be turning off the sound card and/or the
|How does my transmit audio sound?
The surest test of your transmitted audio is to use a second radio to listen to the audio
transmitted by your first
radio. A hand held radio is great for this. Or ask a nearby friend to listen.
You should be hearing packets signals from your station that
sound similar to the packets you hear from other stations
(although perhaps a bit louder and with less noise).
Remember that your audio signal must pass through
4 ) devices that could modify it:
- the sound card's mixer,
- the radio and
- your transmission system,
i.e. antenna and feed line.
For example, you can test the audio coming from
the sound card mixer by temporarily putting your computer speakers
back into the LINE OUT jack. This will give you a fairly good
indication of whether you have
good volume level settings, but it isn't how your final audio
Your interface's TX cable has an attenuation
circuit or potentiometer that could reduce the audio significantly -- or maybe not
enough. As a result, your radio may be receiving audio that is too
weak or too loud.
Even your radio may have audio modification
circuits in it. Some VHF radios have a "bass boost" option
(should be off), and HF
radios have speech compression settings (should be off), drive
settings (should be turned all the way up) and microphone gain
settings (should be left at normal).
And of course your transmission system -- feed
line and antenna -- could attenuate your signals.
So the best way to test your audio is to listen to
how it sounds on another radio.
If you might have a problem with your TX audio:
- Re-check AGWPE's
volume settings for Playback
(TX audio). Make sure the
TX Master and
TX Wave settings
are not muted and that none of
the four sliders is too close to the bottom of the scale (remember that
sliders 1 and 3 control the transmit audio for radioport 1, while sliders 2 and 4 control
audio for radioport 2).
circuit in your TX cable may be over/under attenuating your TX audio. If
you have a variable resistor (pot) in the attenuation circuit, try adjusting
Adjusting Your Transmit Audio Level
With TNCs and sound cards you want a
transmit audio level that is decodable but not too high. One
of the biggest reasons for poor packet performance is
too much audio. If you do not
have access to a deviation meter to set the level (you want
about 3 KHz of deviation), use a local digipeater and
"trial-and-error" to get the lowest audio level that works
Use a program that can send unconnected
packets or a beacon (AGWTerm
can send a beacon or "ASK QRA";
can send unconnected packets). Set the beacon PATH to
relay through the digipeater (e.g. TEST VIA LOCALDIGI),
then go into converse mode and transmit a single carriage
return. Watch to see if your single packet gets digipeated
by that one local digipeater. If it doesn't get through, try
several more times because it may not have gotten through
because of a collision.
If it does get through, turn down the
transmit audio level a little and try again. Keep turning
down the audio until your packet reliable DOES NOT get
digipeated ... and then turn it back up just a little bit
until it does once again.
Remember, in packet, soft is better
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:
Troubleshooting page on this web site: