General Information
Introduction
Features
Supported TNCs
User Interface
Registration
Copyright
Program Setup
Radio Port Mgr
. Edit TNC/modem Port
. Edit Sound Card Port
- Tuning Aid
- Volume Settings
. Edit Parameters
New Port Setup
Network TCP/IP Settings
Radioport Sharing
Auto Start Clients
Other Settings
Views
Program Status
Port Activity Status
Shared Radio Ports
AX.25 Status (Stations)
Connected Programs
Heard Stations List
Monitor
Other Features
TCP/IP Over Radio
. Driver Install
. PE Pro Settings
. Windows Settings
Registration
HTTP Interface
Live Update
Launch IE Browser
Go to AGWsoft web site
Send Error Report
Tips, Tricks, & Trouble
Tips and Tricks
Problems?
Sound Card Use
. Sound Card Interface
. HF Operations
. 9600 Operations
. Receive Problems
. Transmit
Problems
Help Date:
21 June 2004
|
Trouble Shooting Problems
A. General
Program Use
B. Linking to Client Applications
C. Not Transmitting
D.
Problems Receiving Packets
E. Problems with your transmitted packets
F. Slow exchanges when connected
Note:
If you are using a sound card, see these
pages for additional solutions:
|
-
If I register the program, will I be able to
use the same key to install AGWPE Pro on a second computer?
No. You can install PE Pro on all of the
computers you own (same callsign) without extra charge, but you will
have to email the program author and ask him to send you the free
"Registration Key Codes" for each of the unique "Key To Send"
strings that are generated in each instance of PE Pro. It will be
different for each computer.
- Do I need
a
registration code to run TCP/IP Over the Radio?
How much does it
cost?
You only need the TCP/IP registration code if you want to run TCP/IP over radio for more
than 45 minutes a session.
If you register PE Pro, the TCP/IP over radio registration code is
then free (the TCP/IP registration code is different from the PE
Pro registration key code). To get a TCP/IP registration code,
request one from program author by
email. Include
your callsign and mention that you have already registered and paid
for PE Pro.
- PE Pro
starts but then gives a message that it is closing down abnormally.
or
PE Pro is behaving very strangely, particularly my
radioport configuration.
In the PE Pro folder, delete the AGWPE.ini file and all port?.ini
(port0.ini, port1.ini, etc.)
files and then restart and reconfigure PE Pro.
- My sound card cable is connected to the LTP
port for PTT control. When Windows 2000 or XP starts up, all pins in the LPT
port go HIGH (have voltage) and my transceiver starts transmitting
until PE Pro finishes loading. Is there a way to prevent this?
Other than keeping your radio turned off until PE Pro
loads, we don't know of a solution yet. Maybe Microsoft has a fix or
perhaps it relates to how the LTP port is configured. Tell the
program author if you find a fix.
- My Baycom
modem isn't working on my Windows XP machine.
As of the June 2004 version of PE Pro, it will only work if your
computer has non-ACPI (power management) serial ports. Most
newer computers do not; they have ACPI-compliant ports. One
workaround is to install an ISA serial port board, which will be
non-ACPI compliant.
- I don't know how to configure my client
application to link to PE Pro.
There may be instructions in the
Help section of the client application; or you can try the
Application Setup section of
this site:
http://www.qsl.net/soundcardpacket/
- It doesn't appear that my
client application is getting any data from or to PE Pro.
or
When I try to run a client application, I get an
error message from the client indicating the IP connection was
refused, even though the port assignment in both programs is the same: 8000
- Make sure that PE
Pro's TCP/IP application interface is active: from the left menu select
Network TCP/IP Setup and enable the
Network TCP/IP Application Interface
with a checkmark.
- Make sure the TCP/IP
Protocol is installed on your computer. If you have
the Window's Dialup adapter or a network card installed,
then it probably is. If neither is installed, create a
Dialup connection (using a dummy telephone number) and make
sure the "internet Protocol (TCP/IP)" is installed with it.
- If you have a firewall program running, turn off the firewall
temporarily to see if this fixes the problem. If it does, configure
the firewall to so that PE Pro can accept and respond to requests
from other programs via the PE Pro application interface port
(default is 8000).
- My application program sent a packet, but I do not see
the red light in the PE Pro modem icon indicating it has transmitted
the packet to the radio.
- Make sure the radio's squelch is fully open at all times.
PE Pro needs
to hear the frequency noise level at all times -- no squelching!
- Make sure you application program is correctly linked to PE
Pro. See the section above about Linking to
Client Programs.
- Make sure the application program is really sending
a packet. For example, a terminal program/TNC doesn't transmit
in COMMAND
mode, unless you are trying to CONNECT or DISCONNECT. If the
terminal program/TNC is in
COMMAND mode,
you are not sending anything to be transmitted.
Go to CONVERSE mode (K) or try a CONNECT command.
- I saw the red light blink in the PE Pro
modem icon, but the radio isn't transmitting.
- Your application program may not be configured to use the correct PE Pro radioport.
If you need instructions for changing the
radioport, look in the Help section of the client
application; or you can try the
Application Setup section here:
http://www.qsl.net/soundcardpacket/
- Sometimes PE Pro will not transmit immediately if
PE Pro's automatic timing features are in effect.
PE Pro monitors the frequency and uses "slotting"
to send your packet when the frequency is not
likely to be busy. So, PE Pro is holding the packet for a few
seconds before transmitting it.
If this really bothers you, you can override this feature or set the timing parameters
yourself. Call up the Properties
screen for the radioport, click on the the
Tnc Commands
tab and then select Let
me Control Parameters. But remember that PE Pro
usually does a very good job of adjusting the timing to match traffic
conditions on the frequency.
- 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. Usually there is an option to turn these
sounds off in the application, as there is for Windows' sound
schemes.
- Many new transceivers, e.g. Yaesu 8100, won't
transmit if the TX audio level is too high. Lower the drive level in
the TNC or, for sound cards, use the Volume
Settings screen to lower the TX Master
and/or TX Wave
volume.
D. Problems Receiving
Packets
- You are not tuned to the right frequency.
- Poorly tuned signals (HF SSB): If you are using a sound
card, see the HF Packet Operations
Help page
- The radio's squelch is set too high and blocking many signals.
- Packet collisions -- two or more transmitting stations
send packets at the same time, making both unintelligible. This is a common problem on busy frequencies, e.g. APRS. No
real solution is available although network members could experiment with traffic
reduction and collision avoidance schemes and settings, such as
slotting.
- The other station's packets are too distant/faint/noisy:
- Increase your radio knob's volume control if the
radio knob controls RX audio volume. For sound cards, increase your
RX Volume Setting
for LINE IN (or Microphone, if you are using that).
- Poor radio signal path:
You may be experiencing multi-path refraction/
reflection problems (signal waves arriving out of phase) or a Fresnel null (part of the signal wave
is blocked) because of the antenna's poor position. Try moving your antenna.
- Use a better antenna (more height, more gain, more
separation from noise EMI or RFI sources).
- Ask the other station to increase power.
- Ask the other station to try a different antenna
or a different antenna location.
- Consider an antenna feed-line problem at your station if there
is any other evidence of weakened signals, e.g. moving the antenna
doesn't help and you experience low audio and static
on your RX signal compared to the signal someone nearby is receiving.
- Transmitted packets are poorly formed:
- The sending station sent the
packet without sufficient TX delay. Its radio didn't have
sufficient time to power up or switch from receive to transmit. As a
result, the beginning of the packet was lost. Ask the sending station to
increase TX delay in his station's TNC or sound
card.
- The sending station's TNC
was over-driving the radio (sending packet tones that were too
loud) and his radio had to "clip" the signal (reduce the deviation).
This results in a poorly formed packets at the receiving end (low tone
is louder than high tone). Ask the sending station to reduce
his station's TNC drive level.
- If you are operating a handheld radio, your battery saver option may have had your receiver off for a
split second at the beginning of an incoming packet. Turn off your handheld's "battery saver"
option when running
packet.
You may need signal reports from the distant
station to help diagnose some problems.
Put your TNC terminal program in 'monitor all'
mode so that you can see all packets, especially information and
supervisory frames.
- Problem: I'm receiving many
REJ
packets.
Solution: Increase your TXDelay parameter.
- Problem: I'm sending many
REJ
packets.
Solution: If available, use your TNC's
software carrier detect option and then open
the squelch completely. Ask the other station to increase his
TXDelay.
- Problem: I'm receiving many
RR1
packets in same transmission.
Solution: Increase your FRACK parameter.
- Problem: I'm sending many
RR#s
(R1, R2, R3, etc.) in the same transmission.
Solution: Increase your RESPTIME
parameter.
Copyright 2004 SV2AGW George Rossopoulos
. All rights reserved.
|