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
 

What Can You Do With Packet?

Some History
APRS
Bulletin Board Systems (BBS)
Conversation Mode
Digipeater
WinLink
NTS Messages
Personal Mail Boxes
TCP/IP Linking
Network Exploration
DX Clusters
Satellite Communications
Meteor Scatter
 

This page is intended to give ham radio operators some information about the various ways packet is being used today -- let's call them packet functions. It also suggests some AGWPE-compatible programs that will be useful for a specific packet function.

Note that accuracty of information on this page may not be perfect since it is limited by the author's knowledge, location (USA), and length of time in the hobby, so he welcomes any news, corrections and constructive comments, especially about activities in other countries or ITU regions.

New users should also see the page on A Packet Overview on this website for a simplified overview of the mechanics of packet. The Baud Rates and Mode page has an overview of different signal modulation techniques used in packet. And the Common Frequencies page has  information about where to look for packet operations.

Some HIstory of Packet Functions

Packet is a "mature" digital mode having reached its greatest popularity in the 1980s and 1990s. In that era, traditional packet functions, such as Packet Bulletin Board Systems (BBSs), DX clusters, satellite BBSs, and direct keyboard-to-keyboard conversations were very popular. All of these functions will be described below.

During this same time period, however, the internet was growing in leaps and bounds. It didn't take long before hams were instead using the internet for many of the functions which traditional packet provided.

For example, packet-based Bulletin Board Systems provided:

  • Mail exchange (via store-and-forward mailboxes)
  • Reference file uploads and downloads
  • Callsign lookups
  • "For Sale/Wanted" ads
  • Bulletins about local, regional and national ham activities
  • Bulletins about propagation predictions
  • Bulletins about satellite Keplerian data
  • Network links that allowed regional conversations
  • Internet links that allowed inter-continental conversations

Starting in the 1990s, all these BBS functions began to be provided over the internet by email services, websites, eBay, EchoLink, IRLP and special interest mailing lists and discussion groups. Likewise, the services of DX clusters services were available through DX spotting websites.

Still more traditional packet functions lost popularity because of other technology advances. Telephone text messaging and new sound card-based digital conversation modes, such as PSK31, cut into the attractiveness of packet-based keyboard-to-keyboard conversations. And satellite packet activity eclined simply because there have been fewer satellites with packet capabilities.

Yet, packet activity still continues, even though many BBS, DX cluster, and network nodes have stopped operations. Packet's ability to transfer data error-free, although at a fairly slow rate compared to typical internet speeds, remains attractive in some situations.

Here's where packet can excel:

  • for mobile/telemetry operations, where data volume is low and fast transfer rates are not required; see APRS below
  • where radio is perhaps the only way able to provide a link from a remote area or disaster site to an internet connection; see WinLink below
  • for satellite communications

In addition, there are packet users who just enjoy doing things by packet -- or users who do not have ready access to an internet connection and use packet as an important link to the outside world. So the mode is not dead yet.

But packet's loss of luster has made it increasing difficulty to get basic information about traditional packet functions.  Many of the internet-based references and tutorials about packet are either outdated or have disappeared from the web. And most packet books are also outdated, out of print, or no longer carried by new book vendors, although you may find them as re-sales. As you can imagine, there's not much interest in writing about a static or declining mode. The two exceptions are APRS and WinLink, for which you should be able to find sufficient information.

This web page attempts to fill some of the information void by:

  • offering an overview of traditional packet functions, such as BBSs, DX clusters, networks, and satellites
  • suggesting some AGWPE-compatible programs suited for specific packet functions

But ultimately, learning about packet in your area may come down to research and exploration on your part. Users in larger metropolitan areas will probably have the best chance of finding operating BBSs, DX clusters, and network nodes. Try tuning to your area's packet frequencies  and listen for beacons and other packet traffic.  If you hear a beacon or traffic from a BBS, DX cluster or network node station, try to connect to it and then use its menu system to explore what it can do.

Of course, you should also talk to some of the more experienced hams in your area and ask if they have any information about current packet activity.

And if you find a packet function that piques your interest, aggressively mine the internet for any information about it. Enjoy!

So, what are the some popular uses of packet today (2015)?

 

APRS (Automatic Packet Reporting System)

APRS is a packet function that gained momentum in the 1990s. Bob Bruninga WB4APR came up with the novel idea of using GPS (Global Position System) units tied to packet radios to report station positions. These position reports can then be plotted on a computer map using APRS programs that read the latitude and longitude data in the packets. It can be quite interesting to watch people, cars, tractor trailers, boats, bicycles and balloons "move" across the map; or to check weather reports or special event locations throughout the world.

Currently, Bob WB4APR views APRS as a "two-way, tactical, real-time digital communications system between all assets in a network sharing information about everything going on in the local area". A good example would be its use as a advisory system for travelers. APRS can display such things as information about the local voice repeater, ham radio club meetings, and upcoming hamfests.

APRS has many other interesting facets, including text messaging and internet input and output. You can read about them by visiting the websites below and doing your own web search to find many other very good sites:

To participate in the APRS network with packet, all you need besides your sound card interface and a radio is an APRS program that links to AGWPE. Some of the more popular APRS programs that can do this are UI-View32, AGWTracker, WinAPRS and Xastir. You can find out more about these programs in the "APRS" section on the Compatible Programs page on this website. That sections also has links to explanations of how to configure those programs to work with AGWPE.

Packet Bulletin Board Systems (BBS)

BBSs can still be found in many metropolitan areas on the VHF or UHF data frequencies.  In North America, you can also find the "Network 105" BBS on 14.105 MHz LSB.

To access a BBS, you connect to it using a terminal program.  Some of the more popular terminal programs that use AGWPE are WinPack, AGWTerm, and Hamscope. You can find out more about these programs  in the "Terminal Programs" section on the Compatible Programs page on this website.  That page also has links to explanations of how to configure those programs to work with AGWPE.

So what does a BBS offer? First, use the BBS menu that comes up when you first connect to the BBS to explore what's available on the BBS.

  • A primary BBS function is to make available a variety of "general information" messages that relate to satellites, propagation, items "wanted" or "for sale", hamfest notices, and many more topics. Typically, you will scan the list of message topics and then ask the BBS to send you the full text of any message that interests you. These messages come to the BBS by radio (or internet) from other BBSs around the state, nation and world.
     
  • Another important BBS function is messaging. When you first connect to a BBS, it will probably ask you some simple questions and then offer to be your "home" BBS and create a mail box for you using your callsign. This mailbox lets other users -- either locally or around the world -- send a message to you. You can then pick up the messages from your mailbox when you next log into the BBS. Likewise, you can send messages to other packet users around the world if you know their callsign and the routing to their home BBS. (Typically the addressing format goes like this: callsign@my home BBS.optional  region code.state code.county code.continent code or NM5RM@N5###.NM.USA.NOAM)
     
  •  BBSs may also offer chat "rooms"/conferences; callsign lookup programs; internet access or gateways; and connections to other BBSs, either directly or through network nodes (relay stations).

TELNET - Some BBSs may offer Telnet (internet) connectivity that lets you access the BBS without a packet radio connection. You might check this site for a listing of ham-related BBSs (it lists BBSs without ham-related information) or do a internet search for "ham radio telenet BBS". You will need a Telnet program to access the BBS via telnet; this page has some suggestions

For more basic information about BBS operations via radio, see the Further Reading links at the bottom of this page.

 Hosting a BSS - The actual hosting and operation of a public BBS program is an advanced undertaking. Most BBS programs do not link to AGWPE, but FBB is one that does. You can find out more about FBB and AGWPE by looking under the "BBS" section on the Compatible Programs page on this website.

 

Direct 1-to-1 Conversations (keyboard-to-keyboard)

It is also possible for two stations to talk directly using packet, just as they might with RTTY or PSK31. Typically, they would do this by using terminal programs, such as WinPack, AGWTerm, Outpost and Hamscope. You can find out more about these programs under "terminal programs" on the Compatible Programs page on this website.

It is also possible to use an APRS program or UISS to conduct a conversation using unconnected packets. See the "APRS"  and "Satellite" (for UISS) sections on the Compatible Programs page on this website for such programs.

Normally one-to-one packet conversations are established by a pre-arranged schedule (a "sked"). You can also configure a beacon in your terminal program to send a "CQ" call periodically. Any station hearing your CQ could then try to connect to you.

Real-time conversations can be conducted either on HF or on VHF/UHF.  Consult the band plan for your region and use the digital/RTTY section of the band.

HF connections are a little more difficult since fine tuning is required and the packet frames are more susceptible to interference that could distort the packet frame and render it unreadable. Of course, packet's automatic repeat request (called ARQ) feature would result in a re-sending of the packet, but it might take several retries before the packet might arrive successfully. Other modes such as RTTY and PSK31 are often faster, although less accurate word-for-word. Nevertheless in those modes, even if part of the transmission is lost, some of the characters will still get through and the receiving station may be able to get a sense of the basic message. With packet, it's all or nothing at all. Read more information about HF packet activity.

On VHF or UHF, the average packet station can communicate directly with stations within 10-40 miles depending on local terrain, but this range can be extended either by a.) nearby digipeaters or b.) nearby network nodes (both are relay stations).

Real-time conversations are normally between just two stations. However, some DX cluster (discussed below) and BBS programs permit conferencing among multiple stations. Some nodes even have internet bridges which allow you to be part of a multi-station conversation based in a different continent! By connecting to different BBSs and nodes in your network, you can explore what services they offer.
 

Digipeater Station

Actually, being a digipeater station doesn't offer much fun since it's a passive role -- you don't actively do anything; you set your equipment to do it automatically.

Digipeaters (digital repeaters) are private stations that have been configured to relay (repeat) packet frames as a service to others. They simply retransmit any frame heard if it has their callsign in the frame's address. So a frame addressed from Station A to Station B via Station C (your station) would first be received at your station C, which would then automatically retransmit it to station B.

  Station A --->  Station C ----> Station B

In the early days of packet before networks matured, it was helpful to have every private station be able to act as a relay station. In fact, the digipeating logic was built into most TNCs. You would simply configure your TNC to permit digipeating and leave it running to automatically digipeat packets for others.

As networks matured and well-placed BBSs and nodes came on line, they took over the job of relaying with better results; these stations were usually in high places and running reliably 24 hours a day. Private digipeating became unnecessary, except in situations were you might digipeat for a friend who couldn't reach a BBS or node.

This didn't change much until APRS came along. APRS relies on an informal network of private digipeaters to relay packets to other stations. But as APRS matured, even this got worked out. Only a few well placed (high elevation) digipeaters (called WIDE digipeaters in APRS jargon) are needed. Most other stations were asked NOT to digipeat (too much of good thing can actually hurt the network).

So if there isn't much of a need for digipeating, why bring it up? The answer is that you should know the AGWPE's sound card mode can't digipeat on its own like a TNC can. It just doesn't include the logic for digipeating. But, AGWPE can link to compatible digipeater programs that can perform that function. You can get information about those programs in the "Digipeater" section on the Compatible Programs page on this website.

Would you ever need to run an AGWPE-compatible digipeater program? Maybe, but probably not. As I've said, there may be unusual situations where a digipeater might be needed, such as a friend in a black hole (a location with poor signal quality) who can't reach the BBS directly and needs a relay to the BBS; or in an emergency when a digipeater might help relay messages in the WinLink system or other packet messaging network. But this would be rare.

And you probably should NOT run a digipeater in the APRS network. Most APRS networks already have adequate digipeaters. However, there may be locales or emergency situations where a digipeater might fill in a gap and be helpful. You will only be able to decide if there is a need for this after you have gained experience by running APRS for a period of time and talking to other APRS users in your area. They can also help you with the proper settings and configuration for your digipeater software. And remember that an AGWPE digipeater needs a computer to be running constantly. A TNC might be a better choice in those situations.


Ham Radio Mail (or Store-and-Forward Messaging)

You can send a typed message to a mail drop (either an AGWPE-compatible software program or a TNC) which lets the recipient pick it up at his/her convenience. Think of it as ham radio email. As mentioned about, BBSs were commonlly used for this function.

Here are some other packet messaging techniques:

  • WinLink - is a radio-to-internet-to-radio email system that started out as a service to amateur radio sailors. It has evolved into a communications system for any situation where a traditional wired link to the internet does not exist and a radio-link can bridge the gap. It's been used by doctors in remote jungle regions and by emergency responders working in disaster areas where wired internet services do not exist or have been lost. In fact, many emergency planners are now incorporating WinLink into their contingency plans.

WinLink uses PACTOR (not packet) and a new sound card-based mode called WINMOR for long-range, HF frequency connections to land-based WinLink relay sites with connections to the internet. But VHF packet to a WinLink relay site is an option for short-range situations.

You can read more about WinLink and download its AGWPE-compatible packet program, PacLink, from this site: http://www.winlink.org/  

Note: There is AGWPE configuration help within Paclink. Use the Paclink menu to call up "Help", and within the Help "Contents", look under "Configuration" where you will find topics on "AGW Engine Properties" and "Packet AGW Channel.
 

  • NTS: In the United States, the National Traffic System, or NTS, is used to relay short "radiogram"  messages using amateur radio. Messages can range from high priority emergency traffic to routine birthday greetings. Several modes may be used to relay the message from the originating station to the recipient  -- Morse code, voice, and packet. The final step in the delivery of a message is usually a phone call to the message recipient.

NTS nets are held daily around the country. Messages for transfer are usually brought to the net by voice, but messages can also be originated by packet or relayed by packet using special NTS BBS nodes. Packet-based NTS messages can be relayed to the voice net or, if no one on the voice net is near the recipient, then the packet message can be left on the NTS BBS for handling at a later time. To access the NTS BBS and see these messages, you need a packet terminal program . such as WinPack, AGWTerm, and Hamscope, to connect to the BBS. You can find out more about these programs  in the "Terminal Programs" section on the Compatible Programs page on this website.

To learn about NTS in your area, first talk to experienced hams, who will probably know when the local NTS voice nets are held; or listen on local UHF or VHF repeaters for the voice nets, which are often held at 10:30 am, 7:30 pm and 10:30 pm. The net control operator (NCO) of the net will be glad to answer your questions about NTS and tell you if and how packet is used.

For additional information, you can also visit this web page which was written by Dave Streubel WB2FTX and describes NTS packet operations in New Jersey. The description Dave provides will probably work in other states.
 

  • Personal Mail Boxes: In addition to the mailboxes found on BBSs, many TNCs (Terminal Node Controllers) offer personal mailboxes that allow other packet users to connect to your station and drop off messages for you or other users of your station.

AGWPE does not offer this feature by itself, but it can link to programs which can provide personal mailboxes. They include PMS (an external add-on for the WinPack program), HamServ, and Outpost. You can find out more about these programs  in the "Terminal Programs" section on the Compatible Programs page on this website.
 

TCP/IP Linking

Using the special TCP/IP Over Radio (TOR) feature found in AGWPE and PE Pro, two stations can exchange TCP/IP-based data by packet.

TOR is most frequently used as a way for a ham radio station without internet service to gain internet email service by working through a ham radio station with internet service. For this to work, both stations must be running AGWPE (or PE Pro). Note: There is a special fee payable it you want to run AGWPE's TOR feature (for Windows XP and earlier versions only) for more than 45 minutes. If you purchase PE Pro, TOR is included.

For applications needing fast transfer rates, such as high-content web browsing or audio and video streaming, TOR's relatively slow transfer rate will not be adequate.  But for other applications where high transfer rates are not required, such as email, ICQ, small file transfers, or simple web pages, this rate may be adequate.

For more information about TOR, see the TOR page on this website. 

Network Exploration

In the not too distant past, there were numerous packet networks in the US, Europe and other parts of the world. These networks consisted of  BBSs, packet nodes (relay stations/switches) and other links, all tied together. It was quite interesting to explore a network and discover the services available at the different BBSs and nodes. These included callsign lookups, reference file downloads, gateways to the internet, and gateways to conferences/chat rooms that were hosted in continents far away.

Additionally, these networks were developed to provide emergency messaging in the event regular telecommunications were lost. Some states or regions in the US may still have such networks including Florida, Michigan, Virginia, Northeast US, and Colorado (the "last revised" date for some of these websites suggests they may no longer be very robust. 

In general, with the decline of packet and with the appearance of WinLink and other digital messaging systems (such as NBEMS: Narrow-Band Emergency Message System ) that don't need traditional networks, it appears many packet networks are crumbling or outright disappearing.

To find out if there is a network in your area, you can try an internet search; you might try your area's (State, Province, Country) name and the words "packet radio network", "RACES", "digital", "NTS" and "ARES" as search terms.

But perhaps the best way to investigate networks is to do it by radio. Tune to your area's packet frequencies and listen for beacons and other packet traffic.  If you hear a beacon or traffic from a BBS, DX cluster or network node station, try to connect to it and then use its menu system to explore what it can do (use one of the "Terminal Programs" on the Compatible Programs page on this website.)

Some network info: Software programs running networks include

TheNET/X1J.4, Net/Rom, Flexnet, JNOS, TNOS,  AMPRNet, TCP/IP, TexNet, G8BPQ, ROSE, and KaNodes. Generally speaking, knowing the name of the software running the network is not important to most packet users, but if you come across a network name during your research, you now know what it is.

 

DX Packet Cluster

A DX packet cluster is a group (or cluster) of hams who have connected to a central  station running "cluster" management software to share reports of DX "spots", distant stations on the HF frequencies. When a participant notices a spot, he/she sends a notice by packet to the cluster with information about the spot's callsign, operating frequency, and perhaps a comment, such as "listening 5 down". The cluster software then relays this spot notice by packet to each of the other connected cluster participants. As you can imagine, a DX cluster can be a great tool for finding interesting or rare DX stations.

Some metropolitan areas may still have packet-based DX clusters, but many clusters have now stopped operating because there are internet websites that provide the same function more effectively (do a web search for "DX spotting").

To connect to a DX cluster, you would use a terminal programs such as WinPack, AGWTerm, and Hamscope. You can find out more about these programs  in the "Terminal Programs" section on the Compatible Programs page on this website.

If you should be tempted to start a DX cluster, there are also some cluster management programs that are compatible with AGWPE, however, I can't attest to their quality; look under "DX Clusters" on the  Compatible Programs page.

 

Satellite Communications

With the advent of packet, a few satellites were launched with amateur radio packet stations, usually operating on the VHF and UHF frequencies, some using Single Side Band (SSB) modulation and some using FM. Some of these satellites had store-and-forward BBS message capabilities. Some even transmitted status reports or images by packet. Most or all of these early satellites are no longer operational.

More recent packet satellites have been mostly Low Elevation Orbit (LEO) satellites which have relatively quick pass times (10 minutes or less). Most LEOs are used primarily as digipeaters -- to relay a simple, unconnected packet to a distant station, a la APRS. (If a LEO satellite had a store-and-forward BBS, it would be difficult to use -- too many operators competing to access it; not enough pass time to complete the contact --but a  packet terminal program would be used for such a contact.)

A good program for sending an unconnected packet through a satellite is the UISS program. It is able to send UI (unconnected, beacon-style) packets; most terminal programs can not. Look for UISS download information under "Satellites" section on the  Compatible Programs page.

The current situation on packet satellites will fluctuate as new satellites get launched and older satellites stop operating. Of late (2015), the situation has not been good. The ISS (International Space Station or ARISS) has packet capability in the form of a Kenwood D700 with an integrated TNC (2 meter and 70 cm frequencies), but the crew also uses the radio for voice, SSTV, and crossband voice repeating.  If the radio's packet mode has been turned on, it provides digipeating services only -- no BBS services -- so use the UISS program to send unconnected packets.

A typical unconnected packet would have a target station of "CQ" and a VIA station of "RS0ISS", the packet callsign of the ISS. The message inside your packet might include your name and your grid square or other location information. A station hearing your CQ would digipeat a confirmation back through the ISS. You would reply with a confirmation of the other station's packet.

From time to time other satellites are launched with packet capabilities; some may even be in orbit now. To check on the current status of packet-capable satellites, visit the AMSAT website at http://www.amsat.org/amsat-new/satellites/status.php. The last column in the chart indicates if the satellite has packet capability. If it does, do further research on the satellite to learn its schedule for packet operation, type of operations (digipeater, mailbox, or both), its uplink and downlink frequencies,  and its overhead pass times for your area.

Note that most satellites use one frequency band for uplinks (receiving) and another for downlinks (transmitting). This means you must either have a dual band radio or use two different radios. Fortunately, the bands normally used are VHF (2 meter) and UHF (70 cm/440), and such radios are fairly common.

Jan PE0SAT has an interesting page about decoding 9600 baud AX25 packets from the STRaND-1 satellite.  

Meteor Scatter

Meteor scatter is similar to satellite use (above). Periodically you would send a short packet and hope that it bounces off the ionization trail of a incoming meteor/meteorite to a distant station.

In the past, there have been organized attempts to make 1200 baud packet contacts during heightened meteor activity/showers. (Here's a newsletter from 1984 with a meteor scatter report.)  From time to time, someone resurrects that idea, but there's generally not much enthusiasm, partly because there are other digital sound card modes better suited for it, such as FSK441.

If packet contacts were attempted via meteor scatter, it would probably work best with very short UI/Unconnected packets.  The UISS program would be good for this purpose.

Meteor scatter theory suggests the best bands to try are between 30 and 50 MHz. In fact, the 6 meter band has historically showed the most success.

If you are not interested in a confirmed contact from another station, another option is to use automated APRS meteor scatter. In this mode, you simply listen for APRS packets that may have arrived via meteor scatter. Here's what Bob Bruninga WB4APR suggests for doing this:

Let the 10,000 other APRS signals on the air be your test signals...

1) See if you can find a place with weak 144.39 MHz APRS signals (in the US), such as down in a valley where nearby surrounding city APRS traffic is hard to hear, but you can still see the sky down to about 20 degrees towards a really BIG APRS activity area about 500 miles to 800 miles away.  Keep your beam low (to minimize local QRM), but point it up about 10 to 20 degrees in the favored direction (actually, tilting it is not needed at all...  the point is to keep it LOW to the horizon)...

2. Run your APRS station on 144.39 MHz (in the US) all night.

3. In the morning, look at what packets/stations your software has captured, looking carefully at the PATH.  If you heard them
direct and they are over 200 miles or so away, then it was most likely via meteor scatter (but perhaps tropospheric scatter ...).

You can also use one of the APRS data collection sites on the internet, findu.com or aprs.fi, to see if your raw packets were reported at a distant station, an indication that perhaps meteor scatter was at work.

The UI-View32 APRS program has a meteor scatter mode setting that is useful for sending  very short packet (with your grid square) at variable intervals suited for meteor scatter.
 

Last Updated:
18Aug2015

 

Top of page