Ham radio networking took center stage at the first ARRL Amateur Radio Computer Networking Conference on Oct. 16, 1981, at the National Bureau of Standards. The goal was ambitious: explore a network linking American and Canadian amateurs through HF, VHF and satellite packet radio. Experimenters brought accounts of working equipment and proposals for what to build next.
ARRL’s contemporary announcement named AMRAD and AMSAT as hosts, with Paul Rinaldo, W4RI, receiving proposed papers. The invitation reached beyond computer hardware. It asked how independently developed stations could form a useful network for passing traffic.
The surviving papers show builders working out both the station equipment and the rules that would let stations cooperate. Two contributions approached that task from quite different directions. Their questions remain familiar today: How do we connect stations, share limited airtime and keep messages moving when a link fails?
A Bay Area Network Already on the Air
Hank Magnuski, KA6M, described a packet repeater that had started at his Menlo Park home in December 1980. Initially, the only other equipped station was in the same house. By the conference, improved hardware and a move to a 700-foot elevation had helped it serve a group approaching 30 stations, with coverage from Marin and Berkeley to south San Jose.
The station used a Z80 processor and a Bell 202-compatible modem, sending 1,200-baud data through FM voice equipment. Its software was compatible with the Vancouver Digital Communications Group’s terminal node controller. Compatibility gave operators a practical way to join an existing network rather than design every station together.
The repeater received a complete packet, stored it, then retransmitted on the same frequency. That avoided the duplexer and isolation requirements of a simultaneous transmit-and-receive repeater. The price was airtime: each repeated packet occupied the channel again. Magnuski encouraged direct station-to-station contacts where possible to reduce repeater traffic. A higher site increased coverage, but also brought more users onto the shared channel.
Ham Radio Networking That Could Rewrite Itself
Jens Zander, SM5HEV, presented SOFTNET, an experimental network under construction at Linköping University in Sweden. Amateurs, computer hobbyists and university researchers were developing a distributed system in which individual nodes could forward packets toward their destinations. A failed node might leave another usable route.
The unusual feature was programmability over the network during normal operation. SOFTNET used FORTH, whose compact, extensible language let a remote operator define new behavior at a node. Zander’s example created a command called SPLIT: an intermediate node duplicated a packet and forwarded copies to two destinations. The definition could later be removed to reclaim memory.
This went beyond changing a destination address. The network itself was intended as an experimental platform for routing, channel access and traffic control. Its planned radio hardware used 100-kilobit-per-second transmission on 432 MHz, with transmitter power under digital control. Adjusting power could change which neighbors a node reached, making RF coverage part of the networking experiment. These were design goals and implementation plans, rather than a report of a completed nationwide system.
What Would the Network Carry?
ARRL’s call for papers specifically included integration with the National Traffic System and connections to computerized bulletin boards. Those were concrete destinations for the engineering: move messages between local radio networks, existing traffic-handling operations and computers where users could leave information for someone to retrieve later.
Those uses became central to packet’s appeal. Bulletin boards carried messages, equipment listings and amateur-radio information. DX spotting and keyboard conversations gave operators reasons to leave stations running. Networks grew beyond individual digipeaters into linked nodes and message-forwarding systems. They also exposed the difficulty Magnuski had already identified: every transmission consumed part of a shared channel. TARPN’s account of packet-network development
Tucson Helped Put Packet on the Bench
The years immediately after the Gaithersburg meeting brought equipment that more amateurs could assemble and use.
In Tucson, Arizona, TAPR’s first TNC radio tests took place in June 1982. Its TNC-1 followed in 1982–83, packaging the processing, modem and radio interface into a kit. TAPR introduced the lower-cost TNC-2 at the 1985 Dayton Hamvention. These designs helped turn packet from a project requiring extensive development into something an operator could build, connect and put on the air. TAPR’s historical account
The traditional hardware TNC did substantial work. It handled packet formatting and checking, converted data into modem signals and managed the radio link. An operator could use a terminal or terminal program while the TNC handled the protocol.
A common language mattered as much as accessible hardware. Publication of AX.25 version 2.0 in 1984 provided a shared link-layer specification. It defined how stations addressed and exchanged frames, giving equipment from different builders a basis for communicating. Routing and applications could develop above that common foundation. AX.25 protocol history
From Your PC to the Air
A typical 1200-baud FM packet station sends data through four stages. Follow the transmit path in numbered order.
1. PC
Packet software prepares a message or network data and sends it to the TNC.
Digital Data · USB or Serial
2. TNC
The terminal node controller (TNC) encodes packet bits as audio tones and keys the transmitter.
Audio + Transmit Control (PTT)
3. Radio
The FM transmitter uses the tones to modulate a radio-frequency (RF) signal.
RF Signal · Coaxial Cable
4. Antenna
The antenna radiates the signal toward another packet station or network node.
Over the Air · To Another Station
A software TNC can run on the PC with an audio interface. Packet handling is shared differently in full-function and KISS-mode TNC setups.
The Computer Took on More of the Work
Moving TNC functions into the station computer was an early idea. At the 1984 networking conference, Robert Richardson, W4UCH, described software for TRS-80 computers that replaced much of the dedicated TNC electronics while retaining an external modem. Modern sound-card packet had not arrived, but the direction was already clear: let software do work that otherwise required another board of components. Richardson’s 1984 paper
Another milestone came from Phil Karn, KA9Q. His networking software began in late 1985 on a Z80 computer running CP/M, then moved to DOS PCs. KA9Q NOS could act as a TCP/IP client, server and router, and became widely used in amateur packet during the late 1980s and early 1990s. Amateur stations were experimenting with Internet protocols on computers whose operating systems did not yet provide those capabilities themselves. Karn’s account of KA9Q NOS
In 1987, Mike Chepponis, K3MC, and Karn presented the KISS interface at the networking conference in Redondo Beach, California. KISS simplified communication between a computer and its TNC. Rather than making an application work through commands designed for a human operator, it allowed the computer to exchange frames directly with the TNC.
That division gave host software greater control over protocols and networking behavior. It also established an interface still useful today: an application can communicate through KISS whether the modem functions reside in an external device or in another program on the computer. The original KISS paper
APRS Gave Packet Another Job
Packet also developed beyond connected sessions and bulletin boards.
Bob Bruninga, WB4APR, introduced APRS at the 1992 ARRL Digital Communications Conference. It used packet to distribute information useful immediately: station positions, weather, messages and reports about local activity. Operators could see information from multiple stations without establishing a separate connected session with each one.
The Internet subsequently extended its reach. Bruninga’s history identifies Steve Dimse’s introduction of APRServe at the 1997 conference in Baltimore as a milestone in building a worldwide Internet backbone for APRS traffic. RF networks could exchange information through gateways, bringing distant activity onto computer displays while retaining local radio access. Bruninga’s APRS history
That combination remains part of APRS today. Its development and coordination continue through projects and organizations including the APRS Foundation. APRS Foundation strategic plan
From a Separate TNC to a Software Modem
As computers gained processing power and audio interfaces became commonplace, software could take over the modem itself.
A program such as John Langner’s, WB2OSZ, Dire Wolf processes received audio, decodes packet frames and generates transmit audio. It can provide a virtual TNC to another application or operate as a tracker, digipeater or Internet gateway. It runs on ordinary computers, including Raspberry Pi systems. The project continues to develop; its release history lists version 1.8.1 in November 2025. Dire Wolf project, release history
For a typical FM packet station, the external TNC box can therefore give way to software on the PC and an audio interface to the radio. The radio and interface still matter. Software needs suitable audio levels, a clean signal path and reliable transmit control.
Software also makes further experimentation easier. Dire Wolf supports FX.25 forward error correction alongside conventional AX.25 operation, and IL2P as another link protocol. These options have different compatibility requirements; installing newer software does not automatically make every station on a channel interoperable. Dire Wolf’s supported protocols
Hardware TNCs Still Have a Place
The transition has expanded the choices rather than eliminated dedicated hardware.
A standalone TNC can provide a consistent station configuration without relying on a computer’s audio settings. Santa Clara County ARES/RACES, for example, continues to base its packet training on full-function hardware TNCs, while recognizing software TNCs, KISS devices and radio-integrated TNCs as other workable approaches. Santa Clara County’s TNC guidance
Hardware has advanced, too. The NinoTNC uses a modern microcontroller, connects through USB and supports several packet speeds and protocols. It is an example of dedicated hardware evolving alongside software modems. TARPN’s NinoTNC documentation
The practical choice depends on the station: a portable setup, a shared emergency-communications station and an unattended network node may have different needs.
Where Packet Radio Stands Today
Packet activity today includes several overlapping communities.
APRS carries position reports, weather, telemetry and short messages. Connected packet remains useful for bulletin boards, local messaging and network experimentation. Winlink uses packet as one of its radio-access methods, with gateway information available through its live system listings. Winlink also supports other modes, so Winlink activity and AX.25 packet activity should not be treated as interchangeable. Winlink live system information, gateway software documentation
Regional groups are also building radio-linked networks. TARPN documents projects in North Carolina, Virginia, Kentucky and Georgia. Its Georgia listing reports stations linked on 145, 222 and 440 MHz as of spring 2026. These are specific examples of continuing construction, rather than evidence that a uniform nationwide packet network has returned. TARPN network projects
Local infrastructure still determines much of the operating experience. Software makes a station easier to equip, but a useful network also needs reachable neighbors, maintained nodes and services people want to use. Long paths and busy channels still require careful engineering.
Forty-five years after the Gaithersburg meeting, considerably more of the station can run in software. The networking problem remains recognizable: connect independently built stations, use the available spectrum well and give operators a reason to exchange traffic.
Sources and Further Reading
- ARRL: Call for Papers on Packet Radio and Computer Networking, QST, July 1981 — Page 32, Strays
- KA6M, Magnuski: On the Care and Feeding of Your Packet Repeater, First ARRL Amateur Radio Computer Networking Conference, 1981 — Printed pages 1.37–1.38
- Jens Zander, SM5HEV: SOFTNET—Packet Radio in Sweden, First ARRL Amateur Radio Computer Networking Conference, 1981 — PDF pages 1–2 and 4
- TAPR: Digital Communications Conference Proceedings Index