Packet Radio

Introduction
Packet radio, also known as AX.25, is a specific type of Digital Amateur Radio. 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:
• Keyboard-to-keyboard interactive chat. Unlike some of the other Digital Amateur Radio, you
don’t have problems with simultaneous transmissions or errors. The software in the back
automatically handles queueing up text for transmission in small packets, and interleaving
packets from both people, so that contention is automatically resolved. Moreover, this system
permits multiple people to chat at once, similar to a chat room over RF.
• Store-and-forward messaging. You can send messages, similar in concept to emails, using packet
BBSs. (These BBSs aren’t the same as dialup style BBSs from the PC days, although the broad
concept is somewhat similar). Recipients can then check in later for their messages, sending
replies, etc. BBSs also can link together and route messages across the country or world via
packet radio.
• Intelligent routing. Packet nodes running protocols like NET/ROM can automatically discover
optimal routes to distant systems. For instance, if you are ham A and you want to talk to ham E,
but ham E is too far away for a VHF link, you might still be able to reach ham E via packet. If
both of you can see packet node B, you can connect “via” that node and make your connection
that way. Even more complicated, if ham A can see node B, node B sees node C, node C sees
node D, and node D can reach ham E, you can relay your communications via this series of nodes
and still get through. NET/ROM can help automate this path discovery so you don’t have to
figure out the path manually. Some nodes may have an Internet link instead of, or in addition to,
an RF link between them.
• Cheap to set up. Many people already own everything they need to set up packet. Portable or
emergency nodes may be set up with nothing more than a 2m handheld or mobile and a TNC,
which can be small and cheap.
• Emergency uses. A system that can provide guaranteed error-free communication, with both real-
time (keyboard-to-keyboard chat, possibly with many people) and store-and-forward messaging,
is obviously of interest for emergency communications. RACES groups in particular seem to be
showing interest in packet.
 • Packet is a multiplexing protocol. This means that you can run more than one communication
stream simultaneously on a single frequency. This is similar to the way you can browse the web
while you watch a video on an Internet connection.
• Run Internet Protocol applications over RF. IP can be routed over AX.25. One could run telnet or
FTP services over packet, for instance.
• Sending of files – images, word processing documents, etc.
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.

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

TNC

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:
• A standalone hardware box, made by companies such as Kantronics. These typically have an
audio cable to hook up to the radio and a serial or USB cable to hook up to a PC
• Some radios have a built-in TNC, particularly Kenwood
• If you have an interface from your PC to your radio, such as a sound card link or a SignaLink
USB, you can use a software-defined TNC. MultiPSK or MixW for Windows, or soundmodem
for Linux, are examples of these.

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:
• Setting your TNC’s Audio Drive Level
• Introduction to Packet Radio is very good, thorough, and helpful, despite being a bit dated. It has
lots of information on TNC commands, using a BBS, etc.

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:
Linux Packet Radio

Windows Notes
• MixW
• MultiPSK
• AGWPE
• BPQ / G8BPQ

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

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 192.168.0.5 Remote callsign ZZ0ZZ
Remote port 80 Remote SSID 1
Local IP 10.53.98.151 Local callsign YY0YY
Local port 53141 Local SSID 2
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:

• A BBS system for them to leave you a message when you’re not at the keyboard

• A chat system for them to have a live keyboard-to-keyboard QSO

• A node, letting people route their packet conversations via your rig to extend their range

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 ran FBB (Packet BBS) 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:

• A list of stations it has heard recently

 • The ability to connect to these stations via the node

• A list of users currently connected to the node

Some nodes also provide:

• More than one “port” (radio interface). For instance, a port connected to a VHF rig and another
connected to an HF rig.

• The ability to connect to a station on a different port than you connected from – essentially
hopping from one band to another.

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:

• First, connect to a node that’s 45 miles away

• Then, connect from the node to the station that’s 75 miles from you. It may be only 30 miles from
the node and have good connection to it.

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.

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

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

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

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

text
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.
NET/ROM

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:

text
nodes
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
• Hospital packet implementation guide with f6fbb
• Setting your TNC’s audio drive level
• Introduction to Packet Radio
• Packet Radio on HF
 • Linux Packet Radio

Links to this note

• Kansas Amateur Radio

Amateur Radio in Kansas

• Packet Radio on HF

Packet Radio is often used on VHF and UHF bands. It is also used on HF for longer-distance
communications. You should familiarize yourself with the information on the Packet Radio page before
proceeding here.

• Central Kansas Packet Radio

For an introduction, take a look at the Packet Radio and Kansas Amateur Radio pages.

• APRS

The most widely-used form of Packet Radio, APRS lets stations transmit periodic position beacons,
send messages, and other information and forms a self-organizing Mesh Network with the possibility
of propagation by both radios and, less frequently, Internet.

• FBB (Packet BBS)

FBB is a Packet Radio BBS. This page has a bit of information about it.

• Using the Kenwood TH-D72A With PC APRS Software

The TH-D72A is a very nice handheld Amateur Radio Transceiver. Among other things, it has an
integrated GPS, built-in APRS functionality, full AX.25 Packet Radio TNC, and a USB port (which
shows up as a serial device) to a computer – all built in.

• Digital Amateur Radio

Note: This page is a bit dated and doesn’t reflect some newer modes like FT8, but what’s here
should generally be correct.

• Amateur Radio

Amateur radio is a radio service in which people are allowed and encouraged to build their own radios,
antennas, and so forth. It can be used to communicate all around the globe without any intervening
infrastructure such as satellites or cables.

• Linux Packet Radio

Before proceeding, start with the Packet Radio page.