💾 Archived View for gemini.complete.org › packet-radio captured on 2024-08-31 at 12:03:01. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-07-09)
-=-=-=-=-=-=-
Packet radio, also known as AX.25, is a specific type of Digital Amateur Radio[1]. 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.
Some of the things it can be used for include:
Keyboard-to-keyboard interactive chat. Unlike some of the other Digital Amateur Radio[2], 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.
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:
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.
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.
Here are some links to help you get started:
Setting your TNC's Audio Drive Level
Introduction to Packet Radio[3] is very good, thorough, and helpful, despite being a bit dated. It has lots of information on TNC commands, using a BBS, etc.
3: http://choisser.com/packet/
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:
BPQ / G8BPQ
Packet is certainly possible on HF. There are various operators doing so. For more information, see Packet Radio on HF[4]
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.
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.
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.
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 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[5] and help on common BBS commands[6] available already, so I won't duplicate that information here.
5: http://choisser.com/packet/part05.html
6: http://choisser.com/packet/part06.html
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)[7] and am saving some notes about it.
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.
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[8].
8: http://choisser.com/packet/part04.html
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:
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.
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.
Hospital packet implementation guide with f6fbb
Setting your TNC's audio drive level
--------------------------------------------------------------------------------
9: /central-kansas-packet-radio/
For an introduction, take a look at the
Packet Radio[10] and Kansas Amateur Radio[11] pages.
Amateur Radio[13] in Kansas[14]
The most widely-used form of Packet Radio[16], APRS lets stations transmit periodic position beacons, send messages, and other information and forms a self-organizing Mesh Network[17]
with the possibility of propagation by both radios and, less frequently, Internet.
18: /using-the-kenwood-th-d72a-with-pc-aprs-software/
The TH-D72A is a very nice handheld Amateur Radio Transceiver[19]. Among other things, it has an
integrated GPS, built-in APRS[20] functionality, full AX.25 Packet Radio[21]
TNC, and a USB port (which shows up as a serial device) to a computer --
all built in.
19: /amateur-radio-transceivers/
FBB is a Packet Radio[23]
BBS. This page has a bit of
information about it.
Packet Radio[25] 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[26] page before
proceeding here.
Before proceeding, start with the
Packet Radio[28] page.
**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 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.
(c) 2022-2024 John Goerzen