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

Packet: Data Exchange Modes

Unconnected mode
Connected mode
Error free packets
The Connection Process

On the Packet Overview, we looked at the basic mechanics of the packet exchange, including such key components as the terminal program, the AX.25 protocol, and the TNC (Terminal Node Controller). On this page we'll look a little deeper into those components.

First. let's talk about the two basic methods for sending packet frames -- unconnected mode and connected mode. We will start with the simpler mode first: unconnected mode.

Unconnected Mode

Unconnected mode frames, also called "unnumbered information" or UI frames,  can be thought of as information beacons. In fact, one common use of a UI frame is to send out a periodic beacon to others on the frequency letting them know your station is on the air and listening:

"This is the High Mountain Bulletin Board System -- NM5RM-14"

Or they can be used to send a "CQ" inviting others to make contact with you.

A UI frame is sent:

  • to no station in particular, but rather to all stations
  • without any expectation that a receiving station will acknowledge receipt of the packet
  • without any expectation the packet will be received 100% error-free.

While the person sending the frame hopes that the frame will be received and received accurately, it is not a critical failure if that does not happen. Unconnected mode can be thought of as a one-to-many system, where one station can send information to many other stations without being slowed down waiting for acknowledgement from the many stations.

Typically, this mode is  used by stations sending data through APRS (Automatic Packet Reporting System). It is also frequently used in satellite communications, where short, unconfirmed packets are an effective way of communicating.

Note that many terminal programs cannot send UI frames. You will most likely need an APRS program or the UISS satellite program to send them.

Unconnected mode frames are called unnumbered frames because they are not part of a sequence of frames. They are stand-alone frames. In the next section, we will talk about numbered frames.

Connected Mode

Connected mode frames can be thought of as sentences in a private telephone text message (although nothing sent by radio is ever private since it can be heard and decoded by anyone). Connected mode frames are:

  • addressed to a particular station
  • use AX.25 transmission protocols (rules) which require the receiving station to actively acknowledge that all packets have been received error free.

Connected mode is a person-to-person, one-to-one mode. It is the mode two stations would use to exchange a data file or to have a direct, keyboard-to-keyboard conversation . The beauty of connect mode is that, as long as conditions permit the exchange of packets, the frames will be exchanged in the proper order and with 100% accuracy.

Connected mode exchanges are typically handled by terminal programs.

How can packet send information error-free?

The AX.25 protocol includes three techniques for sending error-free messages in connected mode.

  1. Frame acknowledgements - Each frame sent by the sending station must be acknowledged by the receiving station. If the receiving station believes it received a frame accurately, if sends an acknowledgement (ACK) packet  back to the sending station. If it feels it received an inaccurate statement, it sends a rejected (REJ) packet instead.
  2. Frame-Check Sequence (FCS) - How does the receiving station know that it received a frame accurately? When the sending TNC assembles a frame, it calculates a number (using a complex formula beyond the scope of this page) that is based on the order of the bits (zeros and ones) in the frame. It is called the Frame-Check Sequence or FCS; it may also be referred to as a "check sum". The sending TNC includes this calculated FCS number in the frame.

    When the frame is  received, the receiving TNC uses the same formula to calculate a FCS based on the bits it has received. It then compares its FCS to the FCS in the frame. If they are identical, then it is assumed the frame has been received accurately. It it doesn't match, then that frame is deemed invalid and discarded. The receiving station will then send a REJ packet that leads to the sending station resending the frame.
  3. Number frames - In connected mode, the sending TNC includes a frame number (0 to 7, and then back to 0), in each frame it sends. The receiving station keeps track of the frame numbers it has received. If it receives a frame that appears out of order, it will send a reject (REJ) frame telling the sending station the number of the last frame it received accurately. The sending station then know to re-send the frame after that last accurately received frame.

    In the event the sending station does not get either a ACK or REJ frame from the receiving station, it will simply resend the frame that was not acknowledged.

So it is the process of acknowledgements and rejections that results in error free packet exchanges. You may not see the ACK and REJ packets on your computer screen, but they are being exchanged during connected mode.

The TNC During the Connection Process

Let's now look a the process of establishing a connected mode exchange. Having a basic understanding of this process and what the TNC is doing, will help you understand more about AGWPE.

So far on this page we have talked about two different modes for exchanging packets. Besides these two modes, most TNCs have other modes of operation. One is KISS mode which we will talk about on the AGWPE and TNCs page. Still another is COMMAND mode.

COMMAND mode is normally a TNCs default mode. It is the mode that is used to "talk" to the TNC; to give it operating instructions or to change various operating settings (such as the text of a beacon and how often to send it; and how long to wait after receiving a packet before acknowledging it).

When you first turn on a new TNC, if it is in COMMAND mode, the TNC will send a prompt to your terminal program that  says "CMD:". This is the TNC's invitation to you to give it a command.

As it turns out, the way to enter connected mode is by using the TNC's COMMAND mode. So to connect to another station, you would use your terminal program to type in the "connect" command at the CMD: prompt. Your connect command would also include the callsign of your target station. So you would type something like: CONNECT W5ZZZ (which can be abbreviated to C W5ZZZ).

With this command, the TNC sends out a connection request to the target station (a SABM frame). If the target station is free to accept the request, it will return a connection acceptance (a UA frame); otherwise it sends a denial (a DM frame), perhaps because it is already connected with another station. All this is handled by the logic chip within the TNC.

Assuming the connect request is accepted by the target station, the two station are now both in connected mode and will be using the AX.25 protocols to ensure all packets are exchanged 100% error free as discussed above. This will all be done with the help of the TNC's logic chip.

After the stations are connected, they enter a sub-mode called CONVERSE mode to make the connection exchange more effective. In converse mode:

  • All text that is typed into the terminal program will be sent out as frames when either the Enter key on the keyboard is pressed or when the number of typed characters reaches a certain limit.
  • There is no need to type in the target station's callsign as the destination; the TNC remembers the target's callsign and automatically includes the target station's callsign in the address field of each packet frame you send.
  • Only packet frames from your station and the target station are displayed. Frames from all other stations are suppressed. This let's you focus on what you are typing and what the target station is sending you.

Throughout the connection, the TNC's are frame numbers and frame check sequences, along with ACK and REJ frames, to make sure all data frames are being exchanged in the proper order and 100% error free. If there is an extended time when neither station sends a packet, the TNCs will even exchange frames to confirm that both stations are still connected but just waiting for frames to be sent.

When it comes time to end the connection, one of the stations must send a "disconnect" request to the other station (a DISC frame). To do this, you must temporarily leave CONVERSE mode and return to COMMAND mode; you  do this with a Ctrl and C key combination. Then at the CMD: prompt, enter Disconnect or simply D. This sends out a disconnect request which the other station will acknowledge (by a UA frame). Then both stations' TNCs will leave CONVERSE mode and connected mode and return to COMMAND mode.

Note: Some terminal programs may have menu options for "Connect to ____" and "Disconnect", so it may not be necessary to type the commands on the command line.

As you can see, the TNC is handling many operations through it's logic chip, including  confirming the accuracy of frames, entering and leaving connected/CONVERSE  mode, and maintaining the connection process . On the AGWPE and TNC page, we will learn how AGWPE has been programmed to take over most of those functions.

Note: If you are interested in learning more about the different types of frames used to control the connection process, see the Deciphering Packet Headers page on this web site.


Last Updated:


Top of page