Sound Card Packet  with AGWPE

Translations and PDF of this site
Most recent AGWPE version is:  2013.415  15 Apr 2013

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

Program Behavior

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
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

A. Connections not made

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.

B. Connections not maintained

  • 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.)

C. Slow Exchanges

  • 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.

Is Your Sound Card Full Duplex Capable?

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:
  • 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:

Troubleshooting page on this web site:
    Program Behavior

Last Updated:


Top of page