Sound Card Packet  with AGWPE

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

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 Transmitting

As you troubleshoot transmit problems, remember that AGWPE provides a visual aid:

  • If AGWPE gets a packet transmission request from a client application and then tries to pass that packet to the sound card and radio for transmission, the red light in AGWPE modem icon (lower right in system tray) will flash once    and your radio should transmit.

To Force a Transmission through AGWPE, use the AGWTerminal (TCPIP 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.

Note: Please 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. Transmitting on Wrong Device or Speaker
2. Radio Doesn't transmit
3. Radio Locks in Transmit mode
4. Intermittent Transmissions
5. No audio or poor audio on transmit
 

1. Transmitting on Wrong Device or Speaker

The problem: You are running Windows Vista or more recent versions and you are using a second card or sound device (such as a SignaLink or other external sound device). The AGWPE transmission (TX) sounds are going to your default speakers instead of going to the device you want!

Solutions:

A.  You must rename the desired playback and recording devices in Windows so that they have the same name. See the Renaming a Sound Device page to learn how to do this. 

B. If you have renamed the devices as describe in A., then the problem may be that you started Windows and/or AGWPE without first plugging in your external device. When AGWPE didn't find the sound device it was configured to use, it defaulted to default devices. Close AGWPE (and maybe Windows), plug in the device, and then restart AGWPE.

C. If the solution in B. fails, then check the sound card configuration setting in AGWPE. If the sound card setting does not show the sound device you want, then the configuration files may not have been updated correctly after you selected that device. The usual reason for this is because you installed the AGWPE folder in the C:\Program Files folder and Windows prevented any changes to the AGWPE configuration file. The solution is to re-install AGWPE in a folder outside of C:\Program Files.    

2.Radio Doesn't Transmit

  • A. No Red Light Seen: My application program sent a packet, but I do not see 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. AGWPE needs 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 Client Programs.
       
    • 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.


       
  • B. Red Light is Seen: I saw the red light blink in the AGWPE modem icon, but the radio isn't transmitting.
     
    • Double check that the PTT cable is connected tightly to the appropriate COM (or LPT) port. Make sure you do not have a loose connection.
       
    • It may be that the physical COM or LPT port where your PTT cable is connected isn't really the port you think it is: e.g. you think it's COM1, but your mouse or internal modem is on COM1, so your PTT is really plugged into COM2 . Try changing the port for PTT Control in the Port Properties or move the PTT cable to another COM or LPT port.
       
    • Is there a problem with your PTT cable and circuit? You can test it by using a 9 volt battery to apply voltage to the cable's RTS/DTR pin (in the DB9 or DB25 connector) and then using a voltmeter to test for voltage on the radio end of the cable or, if the cable is connected to the radio, look to see if the radio is transmitting.
       
    • Your application program may be configured for the wrong AGWPE radioport. If you need instructions for changing the radioport in the application program, look in the Help section of the client application; or you can try the Application Setup page on this website.
       
    • Are you trying to use the parallel port (LPT) for PTT control and running Windows XP or 2000? This can't be done with AGWPE and those versions of Windows. For those versions, your only choice is to purchase  Packet Engine Pro. (Windows XP and 2000 use a port addressing scheme that is different from the scheme used in Win 95, 98, and ME, which do let AGWPE use the LPT port for PTT control.)

      Alternatively, you can use the following PTT signaling methods instead of the LPT if you have Windows XP/2000 (these methods are all described on the PTT cable page):
      • use a serial (COM) port
      • use an USB-to-Serial Port (COM) adapter to simulate a COM port
      • use a TX audio tone keyer that uses detected audio to trip the PTT circuit

       

    • Are you using the parallel port (LPT) with Windows 98SE/ ME? It should work but, if it doesn't, some users have success configuring the LPT1 port to a "legacy" I/O address, i.e. IRQ 7 and address 0378-037F. To do this, go into Settings, Control Panel, System, Device Manager, Ports, Printer Port and select the Resources tab. Configure manually to the above settings and reboot. Check that there are no conflicts with other devices.
       
    • Is your PTT cable wired to the correct pin at the computer's RS-232 port (COM or LPT)? AGWPE sends the PTT signal to the RTS pin only if you have chosen Single Port in the Port Properties window. It does not also send it to the DTR pin, as some other sound card programs do or as earlier versions of AGWPE did. If AGWPE is set for Dual Port then the radioport 1 radio (left channel ) will use the RTS pin, while radioport 2 (right channel) will use the DTR. See the PTT Cable page for wiring schematics. Possibly so some manufactured interfaces may have wired the PTT cable to the DTR pin only and not the RTS.
       
    • SignaLink USB Interface user?  See the AGWPE-Signalink USB page on this web site for troubleshooting suggestions.
       
    • Occasionally there is a problem with the physical port. You can use a voltmeter to test the COM/LPT port pin. There should be DC voltage on the pin when the red pixel in the AGWPE modem icon lights.

      Note: When Windows boots, it tests all COM and LPT ports by momentarily putting a signal on the port pins (Windows XP does it 5 times). If you have your PTT cable connected and your radio "on" when Windows boots, then the radio PTT will activate for a few short bursts during the boot sequence. This is a good indication that your PTT cable is working correctly.

       

      COM Port Problem?

      Although I haven't heard of this happening with sound card interfaces or AGWPE, I have heard that TNCs and GPS units  attached to a COM port can pose problems for Windows and your ability to use that COM port for packet programs.

      During the boot up process, Windows will automatically try to determine what device is attached to every COM port if finds. For example, if it finds a TNC or GPS on COM1, it may incorrectly identify that device as a "Ballpoint" track ball mouse, reserve it for that (non-existent) mouse and prevent other programs, such as packet programs, from using COM1.

      Booting up without the sound card interface/ TNC / GPS attached to the COM port may be one way to avoid this problem. (Another, more radical but still temporary fix is to use Windows' Device Manager to delete the COM port, turn off the computer, and disconnect the device from the COM port. When you restart the computer, Windows will re-discover the empty COM port and not reserve it for a particular use. You can then re-attach your device to the COM port and use it for your packet programs.)

      But a better, more permanent solution to this problem is to run Microsoft's free COMdisable utility.  Contrary to it's name, this  Microsoft utility does not disable COM ports or even disable the boot-up detection of COM ports. Rather, it prevents Windows' from trying to identify what devices are connected to COM ports and reserving ports unnecessarily. You need run COMdisable only once; Windows will remember your preferences. After you run COMdisable, you then will be able to leave your TNC/GPS/sound card interface attached to your preferred COM port when you boot up.

      You can get COMdisable at:

      http://download.microsoft.com/download/b/2/6/b2624690-0fdc-4842-b850-8d21ca893962/COMDisable.msi

      Thanks to Stephen WA8LMF for this tip. He also keeps a copy of COMdisable on his site: http://wa8lmf.net/aprs/GPS_Mouse.htm


       

    • Many new transceivers, e.g. Yaesu 8100, won't transmit if the TX audio level is too high. Use the Volume Settings screen to lower the TX Master and/or TX Wave volume. Or adjust the potentiometer on the line, if thre is one.
       
    • Some radios use different TX audio pins for HF and VHF/UHF. The ICOM 706 is one. Consult your radio's user manual for pin out instructions. This can be the solution if your interface works correctly for HF digital modes such as PSK31, but won't work for VHF/UHF packet, or vice versa.
       
    • If AGWPE seems to run fine for a set time (15, 30 minutes) and then stops transmitting, your computer's power management scheme may be turning off the COM/LPT port that controls PTT.
       
    • Are you using a special audio recording programs such as Total Recorder? The recording program may be "intercepting' the AGWPE audio and sending it to a destination other than your sound card's (or SignaLink's) LINE OUT or headphone jack. Try disabling the recording program or its drivers. If that fixes it, then you'll then need to re-configure the recording program so that it works with AGWPE.
       
    • I'm using a commercial sound card interface (in this case a RASCAL GLX). I can transmit once, but I can't transmit again unless I reboot. I'm running Win2k Pro, SP4 (but may be a problem with other Windows versions).

      Many commercial interfaces are wired to allow PTT control by either the RTS or DTR line of the COM port. It may be that a small amount of negative voltage (-V) on the DRT line was canceling the positive voltage +V on RTS line.

      To fix this, you will need to disconnect the wire in the interface that connects the DTR line to the PTT circuit. Use just the RTS line for AGWPE in single port mode.
       

3. Radio Locks in Transmit mode

  • First try closing and restarting the packet application and AGWPE; 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 transmit.)
       
  • 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.

    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 find them.)

    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 these ports.
     

  • 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 example, in Windows XP, you get there by clicking on Sound and Audio Devices, then click on the Audio tab. Under Sound Playback, click on the Advanced button then click on the Performance tab.)
     
  •  On newer sound cards with digital volume settings, too low a setting may cause the PTT function to hang.
     

4. Intermittent Transmissions

  • 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 Properties screen for the radioport, click on the  the Tnc Commands 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 schemes.
     
  • Problem:  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 again.
    *
    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 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. 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 serial ports.

5. No audio or poor audio on Transmit

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 four ( 4 ) devices that could modify it:

  • the sound card's mixer,
  • the interface cable,
  • 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 will sound.

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).
     
  • The attenuation 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 it.

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

Use a program that can send unconnected packets or a beacon (AGWTerm can send a beacon or "ASK QRA"; UISS 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 than loud.

 

  • Are the TX Audio cables connected tightly to the LINEOUT jack on the sound card of a desktop computer (or the headphones jack on a laptop?)
     
  • Make sure you are using a stereo plug (has 2 bands below the tip) for the LINE OUT (TX audio) jack. If you use a mono cable (has 1 band below the tip) you may get only half the audio volume on transmit or you may even short out one channel of the sound card.
     
  • Re-check the soldering and component placement in the TX cable.
     
  • EMI or RFI: The strong magnetic fields in your monitor may be distorting the signal, or there may be  electro-magnetic interference (EMI) from your computer or other nearby devices, or there may be radio frequency interference (FRFI):
    • Use a shielded audio cable. Connect the shield to either the sound card ground or the radio's ground but not both.
    • Try using ferrite chokes on the audio cable
    • If you antenna is near your computer, move it further away
       
  • If you have unusual sounds in your transmitted audio or experience delays before AGWPE transmits a packet, it may be that your sound card is getting input from sources other than AGWPE:
    • Turn off any sound schemes for Windows.
    • Turn off any sounds that might be generated by your packet applications, for example voice announcements in UI-View.
       
  • Some radios offer a bass boost function that will distort a packet signal. Make sure you this feature is off.
     
  •  Some sound cards offer Dolby processing (usually on the headphone jack). For AGWPE use, this feature must be turned off for the TX audio.
     
  •  HF: Speech compression should be off for digital modes and the Drive adjustment should be turned all the way up (then use the sound card's Volume settings to control the radio's transmit power output). Microphone Gain should be set to normal.
     
  • If you hear interruptions, or stuttering, of the packet stream, it may be because:
    • your sound card is not fully capable of full duplex operations (sending and receiving). This is mostly a factor on older 16-bit  sound cards. To turn off Full Duplex, go to the AGWPE Port properties' Sound Card Setup screen and uncheck the Full Duplex  box.
    • your  computer/or driver is not fast enough. In that case, set the Port Properties for Single Port use and use only the left channel. Also, set your VGA card accelerator a click below full level and adjust the soundcard hardware acceleration and sample rate quality until you find an optimum setting (these sound card settings are made through the Window Control Panel.  For example, in Windows XP, you get there by clicking on Sound and Audio Devices, then click on the Audio tab. Under Sound Playback, click on the Advanced button then click on the Performance tab.)

    Listen! --->  Sample Wav files:

  • If you hear other noises mixed in with your packets,  our sound card is getting input from sources other than AGWPE, such as you CD player or another application:
     

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

Other troubleshooting page on this web site:
    Program Behavior
    Receiving
    Connections

Last Updated:
18Aug2015

 

Top of page