Recently (well, almost four months ago) fellow Kansan and radio amateur John Goerzen posted The PC & Internet Revolution in Rural America to his blog. While reading through it I found that we had several experiences in common despite my being about a generation older than John. Both of us started with a Radio Shack Color Computer 2 and after some time moved to an IBM PC clone running MS-DOS which led to running Microsoft Windows 3.1 and later Linux kernel based operating systems but that is getting well ahead of the story.
I’ve detailed in several articles my personal history in amateur radio and computing/Linux. Where this one differs is the way I managed some form of online connectivity in those early years. Reading various articles in QST those early years of 1982/83 there were occasional references to online resources. It quickly became apparent that these were not available without substantial cost here in rural northeastern Kansas! Regardless, shortly after receiving my Novice amateur radio license in early November 1983, Radio Shack put their Color Computer 2 with 16k Extended Color BASIC on “sale” for something like $130 to $150 ($382 to $441 in November 2022 dollars). That did not include any accessories other than an interface to connect to a TV set on channel 3 or 4 (there was an RF modulator built into the computer) and a couple of manuals that came with it. Even the interface cable to use a portable cassette recorder as a storage device was on the order of $15 extra at the time. As John notes, these prices were normal for the time and given my general lack of knowledge of mail order sources, Radio Shack was where it was at for me! As time went on I would add a printer and a floppy disk drive which gave me access to a pile of software on floppy disks given to me by another radio amateur.
With the Coco I didn’t do too much those early years until I bought a printer–a DMP-105 dot matrix printer–and put together a rudimentary newsletter for our local amateur radio club. Purchasing the floppy drive added another dimension and finally reliable storage for programs and data as a consumer priced portable cassette recorder and tapes proved to be rather unsatisfactory. Radio Shack sold a recorder specifically for the Coco which didn’t look much different than the one we already had in the house and possibly sold better quality tapes to go with it. I didn’t go down that road but I can say that far too often a large program would be saved to tape after being painstakingly typed in only to have something with the tape cause an issue upon trying to load it next time. My Coco remained on an island of one for about four years.
Note: There are many terms in this article that may be unfamiliar. Some I have linked to while others I have not. The Terrestrial Amateur Radio Packet Network Web site has a Glossary of Packet Networking Terms that may be helpful.
Enter Packet Radio, standardized around the AX.25 protocol, to provide the very first taste of online connectivity for me and a lot of radio amateurs. What exactly is Packet Radio? Well, it is a means of providing error free data transfer over amateur radio frequencies. The packets are short data bursts, no longer than 256 data octets (bytes) plus a header per packet. The radios used were the same ones used for FM voice communications so the practical limit for data speed was about 2400 bps (bits per second) but given the cost of such chips at the time it was most economical to use chips that provided 1200 bps, a speed which is still used for the APRS (Automatic Packet Reporting System) to this day in 2022. In lieu of a modem that connected to a telephone line a TNC (Terminal Node Controller) was the device a ham would purchase to interface between a radio and the computer in order to participate in the Packet Radio scene of the day (I hesitate to call it a network as it really wasn’t a network but a collection of stations that would chat with each other and/or leave messages for each other in a “mailbox” which was a simple electronic message storage system built into the TNC firmware from the late ’80s onward).
I entered this world in the autumn of 1987 after purchasing a Kantronics KPC-2 (Kantronics Packet Communicator, version 2). I was hardly the first ham in the area to “get on” packet but I was far from the last as well. I was probably the first who left the station powered up 24 hours and soon I noticed traffic being relayed through my station as it was the only one in the area that filled a rather large gap with no other relay stations commonly known as “digipeaters” (digital repeaters) nearby (the AX.25 protocol and TNC parameters allowed for every station to act as such a relay). Well, that led to buying another radio so I could utilize voice communications on VHF again. One thing leads to another, they say, but back to packet.
Besides leaving messages for each other, hams would often chat in real time “keyboard to keyboard” which required a lot of typing! Why? Well, it was different than using Morse Code or chatting via voice and being on VHF frequencies the ability to route through several digipeaters meant that chats could take place over a longer distance than voice repeaters offered at the time. Unlike a telephone modem a TNC allows for monitoring of the data channel so that all traffic, not just that intended for one’s station, could be seen and read. This led to another way of using Packet Radio as TNCs have the capability to send so-called “unconnected” packets which were intended as broadcasts to all stations that were monitoring. Such unconnected packets had no guarantee of delivery but hams figured out that round table chats were possible with the use of unconnected packets. Later, software would become available that had chat server capability through normal connected mode, but early on, unconnected mode was much easier than the clunky way TNCs handle multiple connections which does not permit sending text to all others.
At the time a variety of computers or terminals were used to communicate with the TNC. Often times a simple terminal program was used on a computer–such a program was on that stack of floppies given to me for the Coco 2–or Procomm on an MS-DOS PC. Eventually dedicated software intended to be used for Packet Radio operations was developed. Among the earliest of these programs written for MS-DOS was YAPP (Yet Another Packet Program, as I recall (perhaps there were others preceding it?)) which provided a split screen for sent text separated from received text. YAPP 2.0 can be downloaded from https://nl3asd.tripod.com/yapp.html and will run in a FreeDOS virtual machine.
Several intrepid software developers began writing software that ran on the IBM PC/MS-DOS that would store far more messages than a TNC mailbox could hold and had the capability of forwarding messages to other BBS systems. Very quickly, hams had a means of sending a message to a BBS that could eventually be read nearly any where in the world! Electronic messages could also be addressed to a specific radio amateur via an addressing system unique to the packet BBS.
The primary use of a packet BBS was message forwarding. While most had a files section, its use was relatively rare as most hams had slow long distance radio paths to a given BBS and attempting a file transfer most often resulted in failure. Also, filling the channel with so-called binary characters (most packet used 7 bit ASCII characters at the time and 8 bit data would often cause issues with the simple terminals or software in use at the time) irritated other hams that were monitoring the channel and left a bad impression of certain packet radio users. Eventually, the BBS forwarding adopted file compression (8 bit data galore!) when forwarding and to retain some level of harmony restricted forwarding to the overnight or daylight working hours.
More populated areas pressed more frequencies into use for packet radio often reserving some frequency for keyboard QSOs (contacts/chats) and another for BBS access and perhaps other services on other frequencies. Some areas used higher frequency bands and higher speeds to form a backbone where BBSs could forward traffic to each other away and separate from the user frequencies. In those areas a real network was taking shape and a lot of time and money was invested by the early 1990s to handle the popularity of packet radio. All of this infrastructure required dedicated radios and TNCs–not cheap! Some of it was funded by clubs and most by dedicated individual radio amateurs with a passion for Packet Radio. In all cases it was available for use by all free of monetary charges.
Another technology arrived in the late 1980s, the Packet Cluster, the forerunner of today’s DX Cluster that now primarily operates on the Internet. The idea was to exchange information of stations heard and contacted (worked) on HF or other amateur radio bands over a large area. Users could connect to their local packet cluster and if it was connected to other packet clusters, would receive “spots” of DX (stations often in other countries) that could give them an edge toward “working a new one” for the prestigious DXCC (DX Century Club) award available from ARRL.
Packet Clusters were popular in areas where a number of hams were interested in HF DX and where a packet network was in place to handle the traffic. A Packet Cluster generated less traffic than a BBS but relied more on getting spots delivered to the end users in closer to real time and a reliable network between clusters was needed.
The desire to implement a routing protocol that could select a path based on certain criteria led to the development of Net/ROM. Net/ROM was a firmware replacement for TAPR (Tucson Amateur Packet Radio) TNC-2 TNCs. The object was to build out a network of such nodes that would communicate with each other and establish a reliable routing path. Ideally, a cluster of nodes would pass traffic between them on a separate frequency from the users of the network but out here that seldom was the case in practice due to the sparse ham population and the cost of “doing things right”.
After Net/ROM had been available in several versions a group of hams in West Germany called NORD><LINK developed a compatible firmware called TheNet. Claims were made that TheNet was merely Net/ROM with various text strings changed but the reality as I saw it was that a TheNet node had greater functionality presented to the end user than Net/ROM and thus was more than a simple copy. Controversy raged for a few years over all of this and eventually died away. Hams voted with their wallets as TheNet was available at no cost while Net/ROM was something like $75.00 for the programmed EPROM and less functionality. For those interested in learning more about the allegations, response, and analysis, the June 1989 issue of the Packet Status Register has the details beginning on page 9 and continuing through the first part of page 15. Another interesting tidbit is at the end of page 2 and the beginning of page 3.
In the end the Net/ROM protocol “won” even if its developer saw little return from its eventual popularity. The Net/ROM protocol was implemented by G8BPQ as a shim program between the TNC operating in KISS mode and other software that ran on MS-DOS and its protocol was independently implemented as part of the Linux kernel’s AX.25 stack.
As with any adoption of technology there will be growing pains and Packet Radio was certainly no exception. From the above you probably got a sense of the problems with increasing popularity of the mode in populated areas that led to the implementation of various services existing on separate frequencies.
Unlike the Internet where the entire world is accessible from your single connection to your ISP, Packet Radio lacked the networking capability to make that happen. Partly this had to do with a limitation of the technology, partly due to funding and a lack thereof, and partly due to politics surrounding the implementation of a better system.
The technology was limited due to the lack of anything that resembled a router for the AX.25 protocol (does one even exist today?). Routing, such as it was, was a manual endeavor with each operator selecting a path of digipeaters or Net/ROM nodes to reach some desired station. This required that each operator have a good mental map of the “network” of the time. To help matters along, some operators drew up ASCII maps showing the relative locations of digipeaters and nodes in a given area, often a statewide diagram, and of them which could be reached from another and shared them via the BBSs or by other means.
As one moved away from the populated areas the network became more simple quickly often only operating on one frequency less than 100 miles from where multiple frequencies were in use. In part this was due to fewer hams with an interest in Packet Radio and the cost of equipment.
It’s just a fact of life that as one moves away from a populated area like Kansas City or Omaha that the number of hams per county, let alone per square mile, drops off rapidly. For Packet Radio this meant that there were greater distances between users. It also meant that for the construction of digipeaters and nodes that the cost would be greater for each interested operator, assuming a group got together to do so. The result was that only a simple infrastructure on a single frequency was built. Such a system was often overloaded during the prime time evening hours and then hardly in use the rest of the 24 hour period.
I’ve mentioned the cost of a digipeater or node several times. In the late 1980s there were very few surplus TNCs as the manufacturers were selling as many as they could make and very few were found used at amateur radio flea markets. Hams were in full uptake mode of Packet Radio. Radios were a different story. They could be scrounged relatively inexpensively but most were crystal controlled meaning that a set of crystal elements for transmit and receive were needed. Depending on the radio in question getting a set of crystals for a single frequency could range from $20 to $100 ($20 in January 1990 is equivalent to $46.74 in November 2022). Then there was the question of whether a given commercial surplus radio could be converted to the lower part of the amateur radio 2 meter band and the selections were rather slim which caused a bump in prices for such surplus gear. A TNC would cost at least $130 or so for an MFJ-1270B (a TAPR TNC-2 clone), and then an antenna, feedline, an enclosure, a site, and an agreement for site access and possibly electric cost would need to be procured–not an inexpensive proposition even if three or four hams were sharing the cost. Adding a second frequency for a backbone? Forget about it!
Finally, the politics. In the populated areas it stands to reason that without some coordination that chaos reigned and no one was able to chat or read or send messages when everyone was on a single frequency. The prominent system operators set about coordinating their operations and pooling resources to build some semblance of a real network that would put various uses on separate frequencies. All of that was well and good but some lost sight of the reality that existed beyond their horizon and wanted to dictate policies on those of us in the rural areas where it made little sense and where we lacked the collective resources to satisfy those policies and thus they were ignored.
While I didn’t witness much of any personally, I’m sure some friction existed. Perhaps I was simply too far away even though I lived in Kansas City for nearly two years in the 1989 to 1991 time frame and did operate a little bit of Packet Radio while I was there. I do recall one operator who worked for a prominent company that laid out a plan for the state of Kansas and showed how the various digipeaters and nodes would change frequencies (buying more crystals) and then link these “cells” via a backbone network. It was a nice plan but the company wasn’t offering a price break on its TNC offerings and once we considered the cost, the rest of us in the state met this plan with a collective yawn and carried on.
This was the “online” world I lived in from late 1987 to early 1991. It was simultaneously fascinating and frustrating. Fascinating as from my vantage point here in rural Kansas I could monitor a lot of the traffic and learn a lot about the various systems on the air. Frustrating as these systems were often two or more digipeater or node “hops” away and such a connection was usually less than about 25% reliable unless one could use the link in the middle of the night when everyone else was asleep.
The reason for this poor performance is quite technical but boils down to too much traffic operating on a single frequency. Now, most operators at their home stations wouldn’t see much traffic but my station, or a node in an even higher location, could routinely see traffic over a 50 to 70 mile radius. For a time my station was the only digipeater/node station in the area and would have two or more connections flowing through it. Not only that traffic but all the other traffic in the area was seen at once and due to timing, delay, and channel busy detection built into the TNC firmware, my station had a hard time finding a quiet period in which to transmit all the traffic that had been queued to it. The problem was that high profile stations would “see” too much and were nearly paralyzed during prime time evening hours and everything would come to a screeching halt.
Back to the politics and the proposal for having local nodes on a separate frequency from their neighbors but would be linked to their neighbors on another frequency/band. All great in theory and completely impractical due to the cost and the management headaches. I say management headaches as while TNCs often came with suboptimal timing defaults some operators would tweak the parameters to make their node/digipeater more aggressive than others. Thus began a race to the bottom to be the “channel master” and pass their traffic at the expense of others.
It was bedlam and it became known as the “hidden transmitter syndrome” meaning that a station trying to use a node/digipeater but not hearing any or little other traffic would, due to timing parameters, resend a packet to the node/digipeater which had yet to transmit the earlier packet(s) due to its sensing the channel was busy. At best the node/digipeater would finally transmit and then receive and send the acknowledgement back to the originating station and at worst the originating station would time out and disconnect from the node often in a comical sequence of sending multiple disconnect packets before the poor node/digipeater ever had a chance to respond!
And every night I would watch the computer screen in a constant roll of the traffic being monitored at my station. I was fascinated but I also wasn’t using the computer (Coco 2) for much else it seemed. I mainly tried to use a BBS in the morning when traffic was low with some success.
Sometime in early 1991 I bought a 2400 bps telephone modem from a computer surplus store in Kansas City and discovered the world of land line BBSs. They were fun but always time limited such as an hour per day or week, I don’t recall, exactly. Typically one could get enough time to read a few messages or download a file and that was about it. Once the connection was terminated that was it. There was no eavesdropping or monitoring what the system was doing or what anyone else was doing, for that matter. Having a telephone modem was of some use but it lacked many things compared to watching Packet Radio.
By late 1991 I was residing in Enid, OK and found the Packet Radio scene to be rather quiet, certainly less active than I had observed from my vantage point here in northern Kansas, but I was in town with not much of an antenna initially. Later I learned that there had been some nodes/digipeaters in place a few years earlier but they were gone when I moved there. Several of us put together a node on one of the grain elevators in town which gave us a link to the world. Later we did expand it to a second frequency to help alleviate the hidden transmitter problem. We also set up a BBS system that ran on yet another frequency from where we did keyboard QSOs and it worked well. By 1995 that system was getting several hundred messages per day from another station in town that had Internet access and would forward it to the BBS at my house on the 70 cm (430 MHz) band at 9600 bps. Even at that speed and by using data compression the transfer would take almost all night. The volume of traffic hams were generating on the BBSs of the day was bringing them to the breaking point.
It was simply impossible to read every new message on the system every day via a 1200 bps link. As I ran the BBS from my house for a while I could monitor them via the computer console but then we relocated it and about all one could do was scan the subjects for anything that looked suspicious or out of place.
By early 1996 there was an Internet Service Provider (ISP) in town and most of us active on Packet Radio were also getting on the Internet. Packet Radio no longer served as the primary source of news as mailing lists, newsgroups, and some Web sites (yeah, that new fangled thing called the World Wide Web, will it amount to anything?) took on that role. Still, we kept the BBS running and still did keyboard chats with several of us using the KaGold program for Kantronics TNCs that had built-in chat capability and could link to each other. It was more reliable than the unconnected mode chats of the past ever were.
In mid 1997 the company moved my headquarters to Wichita, KS and I moved there the weekend after Labor Day. Not long after I set up the Packet Radio station and found there was not much activity. There was a BBS run by N0KTA south of town at Mulvane, KS that I could check into occasionally and things were quiet enough that a few of us could experiment with things like TCP/IP using Linux or a NOS program like JNOS for MS-DOS. My involvement in Packet Radio became less and less. It was a far different situation than just a decade earlier.
Some years later a job opportunity allowed me to move back to this area and I lived in the lower west end of Marysville, KS that didn’t allow for much range on the VHF/UHF bands. For the most part the Packet Radio equipment remained packed away except for a brief period when a few of us got active on the “local” frequency of 145.050 MHz (years prior activity had been on the primary frequency of 145.010 MHz). There was a digipeater put in service near Blue Rapids, KS on that frequency some years before to allow for local communications away from the busy “.010” frequency. Eventually that effort faded away and my interest turned toward putting a digipeater in service for APRS which I did in mid 2016, if memory serves, on the farm silo that serves as an iGate (Internet gateway) for the local area. I did run YAAC - “Yet Another APRS Client” from time to time but otherwise have not done anything with Packet Radio.
Writing this article piqued my interest to see what is going on with Packet Radio these days. There are localized pockets of AX.25 based activity these days. Some listening on the old popular frequencies shows that this area is not one of them. However, there are some interesting developments that may well supplant AX.25 and move amateur radio data communications forward by a considerable margin.
First off, it is good to have access to current news of these developments. The Zero Retries Newsletter by Steve Stroh, N8GNJ, is one such source of information. All of the archives since July 2021 are available and while the site will bug for an email address to subscribe, which is zero cost, it can be cleared and the archives read. I think Steve is doing a wonderful service for the amateur radio hobby with this newsletter.
There are groups doing various types of development and here is a list of just a few:
- Amateur Radio Emergency Data Network (AREDN)
- New Packet Radio (NPR)
- M17 Project (digital voice with CODEC2)
- GNU Radio (Software Defined Radio (SDR))
All of the above are “Open Source” projects in the sense that all parts of the project are available under permissive copyright licenses much like the software found in Linux or BSD operating system distributions.
I will be investigating the New Packet Radio project in the near future and hope to learn much more about it. Never stop learning as the saying goes.