PacketRadio.ca

FILED UNDER LEGACY // AX.25 // TNC ERA

Packet radio was a way of moving digital data over voice-bandwidth amateur radio channels using a protocol called AX.25. That sentence is technically complete and tells you almost nothing, so the rest of this page is the longer version. It is written for a reader who is comfortable with the idea of a network but did not necessarily live through the era when amateurs were running their own.

The short version: starting in the early 1980s and running through the 1990s as a dominant mode, with a long quiet tail through the 2000s and 2010s, amateur radio operators built and operated a digital data network on top of two-metre and seventy-centimetre VHF/UHF channels. They did this before the public internet was a household idea, and the network did things — store-and-forward email, position reporting, real-time chat, file transfer — that the public internet would later do better and faster, but which packet did first, on hardware most operators built or modified themselves.

The hardware: TNC, radio, terminal

The basic packet station had three pieces. A radio — usually an FM transceiver on 144 or 430 MHz. A terminal node controller, the TNC, which sat between the radio and the computer and did the modulation, demodulation, framing, and link-layer protocol work. And a terminal — first a dumb serial terminal, then a PC running a terminal program, eventually a laptop running JNOS or BPQ.

TNC

Terminal node controller. The box that turned bytes into audio tones the radio could transmit, and audio tones from the radio back into bytes. Common units included the Kantronics KPC series, the AEA PK-232, and the MFJ-1270 family. Most TNCs ran an embedded firmware that implemented AX.25 directly, so the host computer just sent ASCII over a serial port.

AX.25

The link-layer protocol. A modified version of the X.25 packet protocol, adapted to use amateur radio callsigns as addresses. Frames carried a source callsign, a destination callsign, an optional digipeater path, and a payload.

1200 / 9600 baud

The two common over-the-air rates. 1200 baud used Bell 202 audio FSK and would work through any FM voice radio. 9600 baud used direct FSK into the modulator and required a radio with a 9600-capable data port — usually a specific pin on the back of the rig.

Digipeater

A station that listened for AX.25 frames addressed to it as a relay and re-transmitted them. The basic mechanism for extending range beyond a single hop without dedicated infrastructure.

Why amateurs built it

The honest answer is: because they could, and because at the time there was no comparable civilian alternative. Dial-up to a commercial service cost money per minute. The internet, where it existed for a member of the public, was reached through a university account or a hobbyist BBS connected over a phone line. Packet was free in the sense that the spectrum was shared and licensed for amateur use, and the only ongoing cost was the electricity to keep your station on the air.

It was also the natural extension of what amateur radio had always been: an experimental service. If you could put together a TNC, an antenna, and a radio, you could move data. If you could put together a node stack and find a high site willing to host it, you could give other operators reach. If you could host a BBS, you could give the network somewhere to leave messages. None of this required a license beyond the standard amateur ticket, and none of it required asking permission from anyone except the operators whose frequencies you were sharing.

What the network did

By the late 1980s the visible services on a typical packet network looked like a stripped-down version of what people would later expect from the early consumer internet. There was personal mail, addressed by callsign and routed across forwarding links between BBSes. There were bulletins, which were essentially Usenet-style topical posts that propagated between systems. There were real-time keyboard-to-keyboard sessions, where two operators could connect and have a conversation by typing at each other. There was file download, including text files, source code, and small binaries. There was, eventually, position reporting in the form of APRS.

What it did not do well was anything time-sensitive at scale. 1200 baud is roughly 120 characters per second after overhead. Two operators sharing a channel are, by definition, not transmitting at the same time. Add a digipeater into the path and you halve the effective throughput again. The network was perfect for messages and terrible for anything resembling streaming. That was a feature in some ways: it forced an asynchronous, store-and-forward design that turned out to be very robust.

Why the design choices still matter

Packet was a distributed, store-and-forward, addressable network with no central authority. Every node was operated by a volunteer. Every link existed because two operators agreed it should exist. There was no NOC, no SLA, no provider. If a BBS in Acton went down for a week because the duplexer needed re-tuning, traffic backed up and then resumed, and nobody filed a ticket. The network as a whole kept moving.

That structural choice — distribution over centralisation, asynchronous over real-time, voluntary cooperation over contract — is exactly the design lens that makes packet still relevant when you think about why distributed networks still matter. It is also, not by coincidence, the lens that the smarter end of community broadcasting has been working from for decades. The bridge from packet to current digital networks is not technological; the radios changed, the modes changed, the protocols changed. The bridge is the operating model.

A typical session

For a reader who never sat in front of a packet station, here is what an evening of operating actually looked like in, say, 1995. You walk into the radio room, switch on the 2 metre rig, switch on the TNC, and bring up the terminal program on the PC. The TNC's command prompt appears: a colon, a cursor. You type C VE3CON to connect to the local BBS. The TNC keys the radio. You hear the brief warble of a 1200-baud frame going out. A few seconds later the radio receives a frame back. The terminal shows *** CONNECTED to VE3CON, and then the BBS welcome banner.

You type L to list new messages. The BBS sends back a numbered list. You type R 4421 to read message 4421 — a personal note from another operator a few hundred kilometres away, forwarded in over the previous night. You type S VE3XYZ to send a reply. The BBS prompts for a subject line, then opens an editor for the body. You type your message, end with /ex on a line by itself. The BBS confirms the message is queued for forwarding. You type B to disconnect, and the TNC reports *** DISCONNECTED.

None of that was fast. The whole sequence might take fifteen minutes. But the transaction happened over a radio you owned, on a frequency free to use, with no provider in the middle and no monthly bill. That is what packet was day-to-day: a slow, free, operator-owned messaging system that worked.

Why it faded

Packet faded for the obvious reason. By the early 2000s anyone who wanted to send a message to anyone else had a dozen better ways to do it: email over broadband, instant messaging, eventually mobile data. The packet network was slower, less reliable for time-sensitive traffic, and required a license to operate as a sender. The user base aged. New amateurs coming in were less likely to set up a TNC than they were to get on a digital voice mode like D-STAR or, later, DMR.

It did not disappear, though. APRS in particular found a steady role in backup communications and emergency operating. BBS forwarding still runs, including the systems that the SOPRA network kept up across the GTA. The Radio Amateurs of Canada still publishes guidance for digital modes and the licensing framework that makes amateur experimentation possible. The relevant part of the legacy is not the specific technology. It is that a few hundred people, with their own equipment and their own time, built and ran a continental-scale data network for the better part of two decades, and the lessons from how they coordinated it are still applicable to anyone trying to keep streaming infrastructure local and resilient today.

What is worth carrying forward

If you take only one thing from the packet era, take this: a usable network does not require unlimited bandwidth or always-on connectivity. It requires a clear addressing scheme, an honest acknowledgement protocol, agreed-on routing between cooperating operators, and someone willing to keep the relays running. The bandwidth ceiling shapes the design, but it does not break it. Packet was 1200 baud and it still moved continental traffic.

The same observation applies to community broadcasting at small scale. A station that wants to survive a single-provider outage needs what an AX.25 network needed: more than one path, more than one operator who can fix things, and a routing arrangement that does not assume the upstream is always there. For the worked-through version see the low-cost online radio stack and why distributed networks still matter.

And one practical fact: if you want to learn the protocols hands-on, the equipment is still available, the licensing path through RAC is unchanged, and there are operators in the GTA willing to help a beginner bring up a TNC. The network is quieter than it used to be. It is not dead.