welcome: please sign in
location: PacketRadio

AmateurRadio > PacketRadio

Packet Radio


Packet radio, also known as AX.25, is a specific type of DigitalAmateurRadio. Packet radio works somewhat like the Internet in that it splits communications into discrete packets, performs error checking on these packets, automatically requests retransmision of packets that arrived with errors, and thus provides a reliable and error-free communication channel.

In addition, packet radio nodes (something like repeaters) can be chained together to let people hop from place to place geographically. The cost of setting up a node is low, since packet is a frequency-sharing technology, and a standard 2m rig will do.

What can you do with packet?

Some of the things it can be used for include:

In addition, APRS is a subset of packet. APRS is most often used in conjunction with a GPS to automatically transmit a station's position on the earth. APRS reception stations can then view these locations on a map. This is handy for event coordination and emergency uses. Some radios implement only the APRS part of packet. This page is mainly devoted to the non-APRS aspects of packet radio.

A Word on History

Packet saw its heyday in the 1990s, and saw a general decline in popularity in North America as Internet access became widespread. As of 2010, anecdotal evidence suggests there is something of a resurgence in interest in packet worldwide, and development on packet software and networks appears to be increasing.

As a result, you can probably still find used packet equipment at very good prices.


Packet radio is an open standard, supported by multiple vendors.

To get on packet, you will need, of course, a radio. Most packet happens on 2m, but some happens on UHF and even down to 40m as well.

Most packet happens at 1200 baud (bps). On HF, it tends to be 300bps, while some UHF links run at 9600 or even faster.


You'll also need a Terminal Node Controller, or TNC. The TNC acts like a modem: it encodes digital information into tones that the TNC on the other end can understand. TNCs come in various flavors:

How it Works

Traditionally, a packet TNC was more than just a modem. It also had a simple, low-end computer built in. This is probably still the most common mode of packet communication. You will open up a terminal program on your PC and use your serial port to talk to a TNC. You will issue commands such as CONNECT to establish a connection with a remote station.

This works fine, but gets both complicated and limiting if you want to do things like multiplexing. For instance, if you have a single 2m rig and you want to both run a BBS on it and be able to still use it personally to connect to other nodes, you need multiplexing. (Even to allow multiple users to connect to the BBS simultaneously, you may need multiplexing.) There is a protocol called KISS, similar in concept to PPP for the Internet, that allows this. KISS offloads the low-level construction of AX.25 frames to the PC, turning the TNC into a simple modem. The PC can then handle AX.25 as another network protocol and does what it needs to support multiple simultaneous activities.

Working with Packet and your TNC

Here are some links to help you get started:

Linux Notes

Linux has the most complete AX.25 stack of any operating system available today. It also has multiple nodes and BBS software available. Because of all this, the Linux information is on a separate page:


Windows Notes

HF Packet

Packet is certainly possible on HF. There are various operators doing so. For more information, see PacketRadioOnHF.

The Packet Protocol: AX.25, Callsigns, and SSIDs

There is a lot of confusion about packet SSIDs and how they work. This confusion is furthered in part because many TNCs, when not being used in KISS mode, have internal limitations that don't reflect limitations of the protocol.

Packetizing and Multiplexing

Let's start with the basics. I will begin with an analogy to TCP/IP, the protocol behind the Internet. AX.25, the protocol behind packet, is similar in many ways.

Both protocols are multiplexing, packetizing protocols. That is, they use a single physical carrier medium, whether it be a serial cable, Ethernet cable, or specific RF frequency. On that single wire or frequency, they support multiple simultaneous activities. That is, on an Internet connection, you can send an email while watching a video. They do that by breaking down your transmissions into small discrete pieces called packets. The system can, say, send 3 packets relating to your video followed by two relating to your email down the wire. The computer on the other end reassembles the data into a logical stream, routing it back to the appropriate application.

A connection, then, is a logical state between applications on two computers (or TNCs). With an analog phone, which doesn't use multiplexing, there is always either 0 or 1 connection on a given line. With packet and TCP/IP, there are 0 or more connections. Most software only cares about its one connection; the operating system or TNC takes care of the details of the connection.

With either TCP/IP or AX.25, four pieces of information uniquely identify a connection:

TCP/IP info

TCP/IP Example

AX.25 info

AX.25 example

Remote IP

Remote callsign


Remote port


Remote SSID


Local IP

Local callsign


Local port


Local SSID


Change any one of these four attributes and you have identified a different connection.

With TCP/IP, there are over 65,000 possible port numbers, while the IP is fixed. With packet, there are 16 possible SSIDs, but the callsign is sometimes replaced with an alias.

The Role of the SSID

Let's say that you have a single radio running packet at your station. Here, you would like to make available to others:

These are three separate services, provided by three separate programs on your PC (or modules in your TNC firmware). So, you can have your system -- a "server" in TCP/IP terms -- listen on three different callsign/SSID combinations.

Before we go on, here's an important note on writing SSIDs. Normally, people write CALLSIGN-SSID, for instance, ZZ0ZZ-5 means callsign ZZ0ZZ, SSID 5. For SSID 0, instead of writing ZZ0ZZ-0, it is customary to write ZZ0ZZ, and the -0 is assumed.

Now then, if you want these three services, you could, for instance. listen for connections on ZZ0ZZ for chat, ZZ0ZZ-1 for BBS, and ZZ0ZZ-7 for the node. Alternatively, you could use an alias and listen on ZZ0ZZ for chat, ZZBOX for BBS, and ZZNODE for the node. (Note that you must set up an automated identification to emit your real callsign every 10 minutes in this case for legal compliance.) Some groups discourage aliases, while others encourage them; that is up to the group.

So, let's say that you have a BBS at ZZ0ZZ-1. YY0YY can connect to ZZ0ZZ-1 and start interacting with the BBS. While that is happening, XX0XX can also connect to ZZ0ZZ-1 and have a separate conversation with the BBS. This is perfectly valid even though both stations are talking to ZZ0ZZ-1, because one of the 4 unique elements to identify a connection is different (the remote call, YY0YY or XX0XX).

What if, during this scenario, YY0YY wants to establish a second simultaneous connection to the BBS? YY0YY can't just connect again as YY0YY, since that quartet of attributes (calls and SSIDs) is already used. But, YY0YY could set the SSID on its end to -1, and connect as YY0YY-1. This too is perfectly valid.

It should be said here that some software used in the packet world is very old or running on limited embedded systems; not all BBSs actually support multiple simultaneous connections. Many do, however, using just this method.

Differences from TCP/IP

Some differences from TCP/IP are readily apparent: TCP normally randomly assigns a client port number when making a connection, while the convention is to explicitly specify a client SSID for packet. Another difference is that all communications via packet are essentially what is called a broadcast packet in the TCP/IP world: visible to the networking stack on all receiving devices. This makes it very easy to support aliases or listen for connections at various alias/SSID pairs.

There are a total of 16 SSIDs, numbered 0 through 15.

Packet BBSs

Packet BBSs are used so send non-real-time messages to people, similar to email. Many TNCs have a built-in PBBS (Personal BBS) in firmware, which is intended to let people simply leave short notes to the person even if that person isn't at the keyboard right then. Other BBSs run on PC hosts, and can even forward messages around the world via a linked BBS network.

There is a good introduction to packet BBSs and help on common BBS commands available already, so I won't duplicate that information here.

Convention many places seems to be that BBSs listen on SSID 1, though some listen on SSID 0, particularly when using an alias.

I personally run FBB and am saving some notes about it.

Hopping Around The World with Nodes

Before long, you will hear people talking about these things called nodes. A node is a packet system -- it may run directly on a TNC or on a PC -- that people can connect to. The node typically provides these services:

Some nodes also provide:

The great utility of nodes is that they extend your reach. Let's say, for instance, that your 2m rig can maintain good packet links with stations up to 50 miles away. Further, perhaps you wish to reach a station 75 miles away. You could:

Some people used to be able to get clear across continents on VHF using this method, though that is probably less possible today. Nevertheless, it is possible to cross many hundreds of miles on VHF using nodes. It is also possible to go even farther than that, even with only a technician license, by hopping onto HF via a dual-port node.

Some groups usually run nodes on SSID 0, while others typically use SSID 7 for them.

A sample session

Nodes are fairly common part of TNCs and are readily available at many places. Let's take a brief look at one. This is LinuxNode running on my station. Each node looks a bit different, but in almost all of them, ? or HELP will get you information.

KR0L} Welcome to KR0L network node

? for list of commands.  HELP <commandname> for details.
kr0l-0@kr0l 22:58:00> 

This is what you see upon connecting. At this point the node is awaiting your input. Let's get a list of commands.

kr0l-0@kr0l 22:58:00> ?
KR0L} Commands:
?, BBS, Bye, CHat, Connect, Escape, Finger, Help, HOst, Info
Links, Mheard, NLinks, Nodes, PIng, Ports, Routes, Status, TAlk, Telnet
TIme, Users, ZConnect, ZTelnet

kr0l-0@kr0l 22:59:09> 

This is a fairly typical list of commands. Most nodes let you abbreviate commands by just using the first letter. This node looks like it uses ports, so let's first find out what ports it has.

kr0l-0@kr0l 22:59:09> ports
KR0L} Ports:
Port   Description
hf     HF
vhf    VHF

OK. This is a dual-port system, supporting HF and VHF. Dual-port nodes sometimes take a port name as part of the connect command, as in CONNECT hf ZZ0ZZ instead of just CONNECT ZZ0ZZ. This node is one such. Others support a C command to connect to stations on the same frequency you're using, and an X command to connect to them on the other port.

Anyhow, let's move on and see what stations we may be able to connect to. The command to do that is usually MHEARD or JHEARD.

kr0l-0@kr0l 22:59:57> mheard
KR0L} Usage: mheard <port>

Well it looks like this node wants a specific port name. That's fine, we'll give it:

kr0l-0@kr0l 23:01:44> mheard hf
KR0L} Heard list for port hf:
Callsign  Frames   Last heard                      Pids
WA5ETK    253      Dec  7 22:52:47  ( 9m 29s ago)  Text
KC6OAR    39       Dec  7 22:51:27  (10m 49s ago)  Text
AB4KR-7   43       Dec  7 22:51:08  (11m  8s ago)  NET/ROM Text
AB4KR     17       Dec  7 22:51:07  (11m  9s ago)  Text
KH6GN     19       Dec  7 22:45:36  (16m 40s ago)  Text

So here we have a list of stations the system has seen recently. At this point, we can say CONNECT hf WA5ETK, for instance, to connect to that station.

More information on nodes can be found at Introduction to Packet.


You can, of course, manually log on to nodes and run MHEARD to see what they know about. However, that's kind of a pain and there are various protocols to automate this process. The most well-known is called NET/ROM (or NETROM).

NET/ROM is pretty simple. Every hour or so, each node transmits a broadcast message. In its message is information about itself and, especially on VHF, all the nodes that it knows about.

Each NET/ROM station that copies that message remembers the information in it, and uses it to build up a list of what NET/ROM nodes are out there and how to reach them. In short, the computer automates the manual task of running MHEARD and connecting across nodes.

A NET/ROM-enabled node usually has a NODES command. It's similar to MHEARD or JHEARD, but instead of listing raw AX.25 packets, list all NET/ROM nodes for which it has a route. These may be more than one "hop" away, but the NET/ROM system will automatically handle that detail in the background. Here's an example, this time from a dual-port Kantronics TNC:

BEAVER/V     (W5GAF-10)  12/05/10  07:08:51
GUYMON/V     (N5DFQ-10)  12/05/10  09:45:46
PLVW/V       (W5WV-4)    12/05/10  09:56:14
AMAYYE/V*    (WA8YYE)    12/05/10  10:29:29

This is showing us that the system called BEAVER in NET/ROM maps to W5GAF-10, and it's on the port V. One could simply issue a command to connect to BEAVER, and the system will take care of figuring out how to get your packets to W5GAF-10.

A Note on Digipeating

Back before NET/ROM and similar protocols, an older method existed for doing this: digipeating. This is still supported in many TNCs and nodes, and has to do with "via" lists.

The problem with digipeating is that it works really poorly. When you connect to a node, and then connect to the remote, it establishes a completely new connection on your behalf, and then relays the data back to you. If the node has a problem with errors in packets from the remote, the node will tell the remote that, and not send data to you until it gets an error-free copy.

By conrast, with digipeating, any problems must be retransmitted along the entire route. It results in much poorer performance, reliability problems, as well as taking up more time on the frequency. For these reasons, digipeating is generally discouraged these days.

See Also


WikiCompleteOrg: PacketRadio (last edited February 15, 2012 by JohnGoerzen)