SuperPacket

New web page - A Brief Survey of Technological Innovation in Amateur Radio

This is a paper I wrote for the ARRL and TAPR Digital Communications Conference 2022.

A Brief Survey of Technological Innovation in Amateur Radio

By Steve Stroh N8GNJ¹
ARRL and TAPR 2022 Digital Communications Conference Charlotte, North Carolina, USA 2022-09-16 thru 18

Abstract

In recent decades, the perception of Amateur Radio within the general public has shifted from Amateur Radio being useful, innovative, and an interesting technical activity, to Amateur Radio being perceived as an anachronism and largely irrelevant (except in the direst of communications emergencies). Summarized: “Ham Radio – that’s still around?”

Amateur Radio’s service to the public for emergency communications is being supplanted by improved commercial and government communications capabilities such as improved Iridium² satellite phones, the FirstNET³ public safety cellular system, and most recently, the nomadic capability of the Starlink⁴ broadband satellite system.

Amateur Radio has continuously developed unique technological innovations in radio technology, and that has not only continued in the modern era but has accelerated. However, that ongoing, unique contribution to technological society is, increasingly, unrecognized. That is unfortunate. If regulators, lawmakers, industry, the general public... and the Amateur Radio community itself understood the unique contributions to technological innovations in radio technology that Amateur Radio continues to develop, perhaps such recognition might improve Amateur Radio’s perception that it remains a valuable part of society, worthy of continued access to portions of the electromagnetic spectrum.

Keywords

Amateur, Radio, Operator, Ham, Wireless, Technology, Innovation, Spectrum, Digital, VHF, UHF, SHF, Microwave, Communications, ARDC, Techies, Makers, Hackers, Zero Retries Newsletter, Experimentation, Research and Development, FlexRadio, Steve Stroh N8GNJ

Background

For decades, I have been an admirer of technological innovation in Amateur Radio. Not just new technologies like Packet Radio emerging in the 1980s, but new techniques for old problems such as digital techniques enabling reliable communications via unreliable mediums such as the High Frequency (HF)⁵ (aka Shortwave) portions of the electromagnetic spectrum.

Amateur Radio’s unique culture, the varying characteristics of various portions of spectrum allocated to (or shared with) Amateur Radio operations, and the many highly capable and skilled Amateur Radio Operators, have resulted in a fertile, and welcoming “experimental zone” for technological innovation in radio technologies. Until recent decades, that culture of technological innovation was widely recognized, and encouraged. In the last few decades, the recognition of

1 Email – [email protected]
2 https://www.iridium.com/network/
3 https://firstnet.gov/network
4 https://www.starlink.com/rv
5 https://en.wikipedia.org/wiki/High_frequency

A Brief Survey of Technological Innovation in Amateur Radio

Amateur Radio’s utility and contributions to technological innovation have been deprecated to near irrelevence... at least in popular perception... by ubiquitous Internet access, mobile phones, caricatures of Amateur Radio as “Grandpa sitting in the basement tapping on a Morse Code key”, and most notably, the removal of old barriers to individuals communicating across international borders.

A primary reason that this is a concern for society is that it has become irrevocably dependent on radio technology as the primary method of communications for mobile devices, most notably cellular technology, wireless local area networks (Wi-Fi), and most recently, direct-to-user satellite communications. For many people, their mobile phone is their only method of communications and media consumption. Much of that technology has been developed and manufactured in China. Dependence on China for such a critical infrastructure function is proving to be fraught with peril. To counter that peril, the US and other Western nations must quickly develop additional expertise, and personnel, “in nation” to better develop and support this now-critical wireless infrastructure. Amateur Radio can be a “training ground” for developing familiarity and expertise with radio technology, leading to careers in developing and supporting radio technology... but only if Amateur Radio is recognized as a useful and interesting.

The rise of technology specialists, especially those trained in Information Technology (IT), the “Maker culture”⁶, and the “Hacking Culture”⁷ have breathed new life into Amateur Radio. “Techies” have discovered Amateur Radio as an enabling technology for supporting experimentation with Information Technologies (such as building hobbyist / not-for-profit wide- area microwave networks). Makers have discovered that there are incredibly interesting things that they can add to their personal knowledge base and practical projects based on capabilities Amateur Radio has long taken for granted, such as long-range communications via VHF / UHF repeaters. Hackers have discovered Amateur Radio as a fertile “playground” for their experiments and expansion of knowledge about radio technology, such as Software Defined Receivers... and Transmitters (with an Amateur Radio license).

I started the Zero Retries Newsletter⁸ in July, 2021 out of frustration that the totality of technological innovation in Amateur Radio wasn’t being recognized by the Amateur Radio community, its regulators, and especially the public at large. Specifically, I was worried about the growing public perception that Amateur Radio is irrelevant, or worse, an anachronism. Such a perception, if it is to continue for much longer, may prove catastrophic to Amateur Radio, most notably in the loss of Amateur Radio access to various portions of spectrum. To date I’ve published more than fifty weekly issues of Zero Retries, and each issue highlights some aspect of technological innovation in Amateur Radio.

Literally, Amateur Radio is a license to experiment with radio technology and a welcoming “innovation zone” to develop new and exciting technological innovations in radio technology. I hope to make that point with the vignettes in this paper.

 

6 https://en.wikipedia.org/wiki/Maker_culture
7 https://en.wikipedia.org/wiki/Hacker_culture
8 https://zeroretries.substack.com (will eventually migrate to https://zeroretries.org)

...

Read the rest of the paper at:

https://www.superpacket.org/n8gnj_dcc_2022_final_for_web.pdf

 

RadioMirror, Meet flamp

My two articles on RadioMirror - Revisiting RadioMirror and More Thoughts on RadioMirror, constitute a reasonably deep dive on the use case, concepts, and details of RadioMirror. Again, as far as I'm aware, RadioMirror never quite got going, other than some experiments to prove out the concept. To reconstitute RadioMirror in 2021 would require cobbling together some old Windows code for the server and client, terminal node controllers (TNCs) or using DireWolf's "KISS" interface, Windows computers, etc.

As I explained my enthusiasm for the RadioMirror concept, my friend, colleague, and co-conspirator on many of my Amateur Radio data communications experiments Bill Vodall W7NWP* verbally "smacked me upside the head" (probably a very dated cultural reference) by reminding me that there is a "RadioMirror" mode in the fldigi suite, specifically flamp (PDF). 

D'Oh!

Grokking fldigi
In my initial encounters, I had a hard time "grokking" what exactly the fldigi suite is, and what it does , and how it works. (Yes, that's the author's preferred capitalization - all lower case).

Wikipedia's article on fldigi has a reasonable intro paragraph:

Fldigi (short for Fast light digital) is a free and open-source program which allows an ordinary computer's sound card to be used as a simple two-way data modem. The software is mostly used by amateur radio operators who connect the microphone and headphone connections of an amateur radio SSB or FM transceiver to the computer's headphone and microphone connections, respectively.

So to save readers at least some of my grief at figuring out the fldigi suite, here's my capsule explanation.

• The fldigi suite is a self-contained suite of sound card modes and applications that are coupled / integrated with those modes. You don't need any additional "sound card drivers", "protocol engines", etc.
• fldigi was written in portable code, and is open source. Thus there are interoperable implementations for Windows, Mac, and Linux (and BSD, etc.). Thus it is "universal"; "Mac fldigi" can communicate just fine with "Raspberry Pi fldigi".
  
• fldigi is the primary application, and the other applications in the fldigi suite are "helper" applications such as flamp (discussed here) and flrig which controls radio settings (on radios that have that capability).
• fldigi is designed primarily for operation on the narrow channels of the Amateur Radio high frequency (HF) bands 30 MHz and lower, and HF modes (single sideband - SSB). fldigi has some accommodations for the wider channels of using frequency modulation (FM) (and thus, theoretically higher data rates) on the 50 MHz and higher bands.
• fldigi is not packet radio. There is no implementation of the AX.25 protocol in fldigi. There is no real "networking" in fldigi, though there are some "helper" capabilities. One example is that in the "fsq" mode of fldigi, you can specify a station to use as a relay for your transmissions.
• The applications in the fldigi suite use TCP/IP socket 7322 to communicate between the applications. Thus, fldigi can, theoretically) be used as "transport" by applications (that can transmit to, and read from, TCP/IP sockets) that are not included of the fldigi suite. As I (very imperfectly) understand it, the only applications that are compatible with fldigi's TCP/IP socket implementation are those applications in the suite, and those that are written expressly to interoperate with fldigi.

flamp - "RadioMirror" Hiding in Plain Sight
flamp (again, the preferred capitalization from the author is all lowercase) is innocuously described on the fldigi web page as:
Amateur Multicast Protocol - file transfer program; apparently the name is derived from FLdigi suite Amateur Multicast Protocol. The last update of flamp is 2015; it's like the authors of flamp pre-thought about my RadioMirror ideas more than five years ago.

Multicast is the game changer word here. flamp isn't just another "packet radio file transfer application". Rather, flamp implements a single transmitter, unlimited receivers paradigm; there's no "handshake" required to receive files transmitted with flamp. Other than not being based on AX.25 packet radio, flamp implements all of the criterial I outlined in my descriptions of RadioMirror. Here's the description from the excellent flamp manual:

FLAMP is a program for AMP or Amateur Multicast Protocol. An FLAMP session will transmit one or more files with one or more iterations of the transmission. Each file is broken into blocks, each of which has a check sum. The receiving station saves the blocks that pass check sum. Successive transmissions will fill in the missing blocks provided that the new blocks pass the check sum. After the transmission sequence, the entire file is assembled and may be saved. “Fills” may be provided by retransmitting the entire file or by the sending station only sending the missing blocks.

You want X? It's In There!
As I browsed through flamp's excellent documentation, it became apparent that flamp goes considerably beyond my expectations hopes for "RadioMirror 2021":

• Like RadioMirror, you create a queue of files to be transmitted in flamp.
• Optionally, a specific station for the transmission (and presumably, other stations will ignore the transmission / file) can be specified. The default is "QST" (any station).
• File compression capability is built into flamp so transmission time can be reduced on large files.
• After adding a file to the queue, you can add an optional file description such as "Whatcom County Repeater List 2021-07-01".
• flamp's transmit parameters (block sizes, etc.) are highly configurable.
• "Hamcast Multimode" is a capability to retransmit files using multiple modulation methods to maximize the potential for all the file blocks to be received without error (or requesting a "fill"). Again, fldigi is designed primarily for HF, not the VHF/UHF FM usage that I'm contemplating.
• There is some provision for recipients to request "fills" rather than just await another transmission. It's not apparent to me (yet) if that's a function a receiving station.
• On receiving, no setup is required other than having both fldigi and flamp running. fldigi and flamp "auto configure" based on the transmitter station.
• Last but not least, fldigi / flamp includes some well-considered options for using flamp over a repeater, such as transmit (TX) delay, and interval timer which allows the repeater to reset between transmissions.

One minor limitation is that flamp will transmit a file a maximum of ten times. (RadioMirror can transmit continuously and will retransmit a file infinitely each time it comes up in the queue.) Given that the fldigi suite is designed primarily for HF usage, the limit of "10 transmissions" is a reasonable feature.

Other "features" of fldigi / flamp:

• fldigi / flamp is open source and has been ported to all the major operating systems, so there's no dependency on Windows (legacy RadioMirror)... though, of course, if you want to, you can. The huge advantage of this is that fldigi / flamp can be implemented on an inexpensive Raspberry Pi.
• fldigi is its own "protocol engine" thus no dependency on a Terminal Node Controller (TNC), either a hardware TNC, or software TNC such as Dire Wolf. It only requires a radio, sound card, and computer.
• For receive only, fldigi / flamp can use a computer, simple software defined receiver (RTL-SDR) (and required software, of course), simple sound card, and fldigi / flamp. Crudely, audio from the computer's standard audio output can be cabled to the input of the sound card, but there are probably more elegant virtual audio cables that can be used.
  Update - apparently integrating an RTL-SDR as a receiver, working with fldigi, on a Raspberry Pi is a solved problem.
• Especially on Linux and similar operating systems, fldigi suite apps can be highly scripted. flamp has a number of scripting capabilities built-in, thus "somewhat easy" to configure rather than resorting to "shell scripts" (in Linux and similar operating systems). Thus it's conceivable to implement an automated system for fldigi / flamp to automatically control the radio (using flrig, changing channel and modes, such as changing from monitoring a simplex channel to a repeater channel), and transmitting (and receiving) files on a schedule.

Higher Speed Modes for VHF / UHF FM and Repeaters
fldigi includes some higher-speed modes intended for use on VHF / UHF FM:

The 8 PSK modes are intended for use on VHF/UHF FM systems. They provide a very high data rate suitable for use with both flmsg and flamp and the transfer of digital data.

The fastest mode listed in the documentation is "8PSK1200F" with "baud" of 1200 and "WPM" of 4170. The interplay of modulations, TX delay, and the many other parameters will require considerable experimentation for use on a repeater.

Again, one of the absolute gems of flamp is the excellent documentation. All my questions were answered browsing though the documentation. I'll be doing a much more careful read of the documentation as I implement a test system.

Nexus DR-X - flamp Is In There!
It's a separate article to discuss the Nexus DR-X (originally in use in Whatcom County, Washington, USA but now used all over the world), but one of the most encouraging aspects of all of the above is that everything about fldigi / flamp above is that I already own, and have on the air, a Nexus DR-X. flamp is already implemented in that system - see the screenshot in the link.

As the saying goes, fldigi / flamp is a "fertile area of research". Stay tuned! Since I will be conducting personal experimentation rather than just discussing "big picture of Amateur Radio", I'll be cross-posting my results of experimentation with fldigi / flamp here on SuperPacket, but also my personal Amateur Radio blog (N8GNJ.org).

RadioMirror 2021? Probably Not Needed
The grand takeaway of this article is that if fldigi / flamp works even half as well on VHF / UHF FM (and perhaps, repeaters) as I'm explaining here (with absolutely no experience with it as I write this article), then there's little need for recreating (or creating from scratch) "RadioMirror 2021".

That said, there may be some utility to recreating the "RadioMirror" techniques for use in a system capable of faster speeds, such as VARA FM, but it's equally possible that faster modems can be ported into fldigi. Again, "a fertile area of research".

* With this particular contribution instigation, building on a long history of such contributions instigations, W7NWP has earned a new title - Zero Retries Instigator In Chief. The significance of this title will become apparent in coming months.

Thanks for reading!

Steve Stroh N8GNJ
Bellingham, Washington, USA
Portions Copyright © 2021 by Steven K. Stroh

 

More Thoughts on RadioMirror

Original article - Revisiting RadioMirror

The nice mention of Revisiting RadioMirror by KE9V spurred this update. I'd been gathering notes since the Revisiting RadioMirror waiting for a good excuse for an update. Thanks Jeff!

The Use Case for RadioMirror
One of the Seven Habits of Highly Effective People that has become ingrained in my thought experiments such as this is Begin With The End In Mind. How do you want the idea you're trying to present to turn out in the end? Thus, with any new system, It's totally appropriate to ask "What problem does RadioMirror attempt to solve? What itch does RadioMirror scratch?" These are my answers.

• In my area, one of the primary Amateur Radio websites (no, I won't name it) that should be a primary reference for Amateur Radio activity in my area is horribly out of date. Websites for "amateur" organizations (those that don't have skilled / paid / motivated staff to maintain them) just... drift out of date, and out of relevance. Such sites are worse than useless - they detract from what they intend to help because the information they provide is inaccurate. Putting up one's own site is possible, but that's also not easy to maintain (and secure).
• The great hope of Automatic Packet Reporting System (APRS) was that it can (theoretically) be a universal guide to resources in an area. But that depends on resources to be constantly advertised via APRS. My (admittedly limited) experience is that APRS never quite lived up to this potential. But, maybe it could with the addition of RadioMirror being advertised. Imagine a RadioMirror Server advertised on APRS - "Tune 224.76 every evening from 12:00 - 3:00 for N8GNJ RadioMirror Update".
• We're Amateur Radio Operators - shouldn't we figure out a way to use Amateur Radio for distributing information?
• Disasters do happen, including widespread disasters can take down communications infrastructure. Despite my pessimism about the relevance of traditional Amateur Radio emergency communications, I think there can be a role for Amateur Radio to solve unique problems.
• A meeting I attended recently discussed two things that were conceptually inter-related. One emergency communications group is planning to update their master list of communications facilities - repeaters, simplex frequencies, net schedules, DMR talk groups, etc. A later discussion was "what to do about the group's communications van"? How often does the information in a comm van get updated? Wouldn't it be useful if a communications van had a RadioMirror receiver, constantly receiving updates, and if the comm van has to be activated in a hurry, wouldn't it useful that all the necessary information onboard was updated the previous evening?
• Ditto personal Go Kits. How many times have you grabbed the Go Kit, transported it, set it up to use it, and discovered that the last time you updated the info in the computer was way too long ago, impacting your ability to communicate? Add a RadioMirror receiver to the Go Kit and power just that unit while the Go Kit is in standby.
• RadioMirror allows each Amateur Radio Operator to contribute information into the community, to the limits of their ability and willingness to aggregate and present data.
• RadioMirror would be a great way to improve the utilization of our Amateur Radio bands, and especially make voice repeaters relevant again. Individuals (see line above) who don't have stations that can be heard simplex can use repeaters to make their information more widespread.
• There's ample room for innovation. One of my personal experiments with RadioMirror will be to experiment with transmitting simple HTML files so that the information I want to transmit will be easily accessible.

RadioMirror's Time Has Come?
As I discussed in my first article about RadioMirror, I think it's a concept whose time has come. In 2021, we have all the elements necessary to implement RadioMirror:

• Ample available channel time on our bands above 50 MHz, including unused time on repeaters.
• Inexpensive computers that we can dedicate to the task (Raspberry Pi). I'll discuss why dedicated computers are important for RadioMirror to work.
• Inexpensive "all band" receivers such as the well-designed, but inexpensive ($27!) RTL2832U software defined receiver. With such a receiver we can use any band above 50 MHz, including our underutilized 222-225 MHz, 420-430 MHz, and 430-440 MHz bands for RadioMirror.
• We have powerful software for both packet radio and the receive function. In particular, we have the Dire Wolf packet radio engine and it has three primary capabilities right now that lends itself to RadioMirror:
  • 4800 bps speed (which reportedly works well even with radios that don't have "flat audio" input / output such as the FT-2980R mentioned below.
  • Keep It Simple Stupid (KISS) interface that is a software bridge to the legacy RadioMirror implementation (necessary for prototyping "RadioMirror 2K")
  • Implementation of FX.25 which is a Forward Error Correction (FEC) extension of the usual packet radio AX.25. Using FX.25 with RadioMirror would add additional robustness with little overhead, especially if higher speeds like 4800 bps were used.
• We have powerful radios (especially on 144-148 MHz). For example the Yaesu FT-2980R has a maximum transmit power of 80 watts (and uses a large heatsink rather than a fan). Ham Radio Outlet sells this radio for $149 at the moment. Yes, duty cycle would be an issue - I'll address that.

More than one RadioMirror is a good thing.
There's no reason to have only one RadioMirror system in an area. It would actually be a good thing to have more than one to avoid the "BBS SysGod Effect" that we endured in the Packet Radio Bulletin Board System (BBS) era where some BBS Sysops tended to censor (delete) any content that they didn't personally like from passing through their BBS (even "private" messages).

Federation
I can envision several RadioMirror systems in a given area, each with a focus. For example, my RadioMirror system would focus on data communications. Another might focus on Emergency Communications information. Another might be the files for a particular Amateur Radio club. There's no downside (that I can imagine) in receiving files from each one. Each night my RadioMirror receiver can tune to a different one to update my file system for each one.

RadioMirror and Bulletin Board Systems
I haven't yet discussed Bulletin Board Systems in the 2020s (a future article, likely to be a long one). RadioMirror is a perfect complement to BBS systems as it's an efficient method to distribute files widely into BBS systems. The nature of RadioMirror is that it's not a fast way way to retrieve a particular file (you have to wait for it to be transmitted in turn), whereas if you needed to quickly view a file, a BBS would be a better method of doing so.

RadioMirror as a First Project for new Amateur Radio Operators
Conceptually, a RadioMirror receive station can be as simple (and inexpensive) as a Raspberry Pi, an RTL-SDR software defined receiver, and a simple wire antenna such as a twin-lead J-pole. A (better) addition to the station would be a USB flash drive to store the received files. Everything else is a "simple matter of software". Because such a station is receive-only, you wouldn't even need to be a licensed Amateur Radio Operator to use such a system.

Duty Cycle
Despite the seeming robustness of the Yaesu FT-2980R mentioned above (large heat sink), in my experience, and what I've been told by much more experienced Amateur Radio Operators, is that any radio specifically made for Amateur Radio use is just not built for continuous duty cycle (no matter what the manufacturer says). It's simple - Amateur Radio Operators are price-sensitive. Thus radios manufactured for the Amateur Radio market are primarily optimized for cost. Thus, if you're going to use an Amateur Radio unit for transmitting RadioMirror, it would be best to not use it at 100% duty cycle (transmitting 100% of the time). If you do, the radio will inevitably fail. There are two solutions for this issue:

• Don't operate at 100% duty cycle. Perhaps transmit for one minute, wait one minute, then transmit for another one minute. Even on a radio like the FT-2980R, use a fan on the heat sink (use a bigger, slower one so that the noise isn't objectionable)
• Instead of a radio built specifically for Amateur Radio, use a radio designed for commercial use that can withstand a 100% duty cycle. Repeater Builder is an excellent reference for using (converting, adapting) such radios for such use.

My spring and early summer 2021 has been pretty full with personal travel, so I haven't had much time to do the many experiments and projects I have planned. RadioMirror is one project that I will be working on soon. Stay tuned!

But wait... there's more! Perhaps "RadioMirror 2021" isn't quite so conceptual after all! See my next article -  RadioMirror, Meet flamp.

Thanks for reading!

Steve Stroh N8GNJ
Bellingham, Washington, USA
Portions Copyright © 2021 by Steven K. Stroh

 

Nice Discussion about RadioMirror by KE9V

I've admired the writing of Jeff Davis KE9V for some time. Jeff "thinks different" and his long-time blog reflects that. I particularly enjoyed Jeff's (fictional) audio series "Cornbread Road" (now, unobtanium, as Jeff stated; you won't find mention of it on Jeff's blog. Jeff is remarkably unsentimental about his previous writings.)

Jeff heaped some praise on my article about RadioMirror:

I’m interested. Very interested. Nothing about this concept is outside current amateur radio capabilities. It doesn’t require some pie-in-the-sky new geo satellite or yet to be imagined software. It could be implemented right now in 2021 if the idea caught some fire…

Thanks for your interest Jeff!

Thanks for reading!
Steve Stroh N8GNJ
Bellingham, Washington, USA
Portions Copyright © 2021 by Steven K. Stroh

 

Revisiting RadioMirror

(This was originally published on N8GNJ.org, and copied here; SuperPacket is now my "big picture of Amateur Radio" blog for articles like this - see About SuperPacket.)

The genesis of this idea was a discussion I overheard during a local radio club's (virtual - Zoom) meeting. The club wanted to implement a way to keep all members of their Emergency Communications (EMCOM) group up-to-date with a set of files - maps, lists of personnel, frequencies, etc. continuously updated so that when a communications emergency occurred and Internet connectivity was lost, all of the information they needed to respond would be up-to-date. The method they chose was an non-centralized Internet file replication system. I checked in with one of those who was named as one of the leads for implementing this idea, and he had not heard about the idea. I think the idea was a good one, but it requires installation of software and some sophistication to make it work, and perhaps the organizational skill to remember to keep the replicated files on a USB flash drive so that in a communications emergency, the USB flash drive (which hopefully doesn't get corrupted in a sudden power failure) can be taken with the up-to-date files and used in another system such as a laptop.

Update: A friend reminded me that the Pacsat Broadcast Protocol concept in 1990 predates (and is specified more rigorously) than RadioMirror. Thanks Larry!

Out of the deep recesses of my packet radio experience, I thought of a better way to accomplish this that didn't require Internet at all - RadioMirror. RadioMirror is a concept originated by John Hansen W2FS that's been around since the early days of packet radio. In a nutshell:

• A RadioMirror server broadcasts file blocks with checksums .
• Multiple RadioMirror clients receive broadcasted file blocks and (if the checksum is valid) reassemble the blocks into files.
• There is no handshake between the server and client.
• The RadioMirror server broadcasts blocks continuously. When the last block of the last file is transmitted, the RadioMirror server starts over.
• Any new or changed files are added to the RadioMirror server's queue, and they are transmitted.
• When a RadioMirror client receives all of the blocks (with valid checksums) of a file, the file is written to its received files queue.
• The RadioMirror client is responsible for (optionally) deleting, renaming, moving, or versioning files that the RadioMirror server is no longer transmitting.

Here is the original documentation: Thank goodness for Internet Archive's Wayback Machine!

General article explaining RadioMirror

One person's vision of RadioMirror usage

John's original article explaining the RadioMirror concept.

RadioMirror Technical Documentation

RadioMirror was created at a time when the dominant paradigm for packet radio was 1200 bps data rate and the method of getting a file was for each user that wanted the file to connect to a Bulletin Board System (BBS) and individually download the file. Doing so used up a huge amount of airtime sending the same file over and over. RadioMirror solved those issues by broadcasting files on a dedicated channel, freeing up the BBS channel for more user traffic.

To my knowlege, RadioMirror never caught on. I think it was an idea a bit ahead of its time, and the BBS paradigm was firmly entrenched in packet radio. In addition, not only did you have to dedicate a (then expensive) computer, Terminal Node Controller (TNC) and a radio, as a RadioMirror server, every RadioMirror client had to dedicate a (then expensive) computer, TNC, radio to receive RadioMirror files.

The brilliance of RadioMirror is that the files it broadcasts can be anything - images, maps, text files, codeplugs, spreadsheets... even HTML files.

I think RadioMirror could easily be reinvented to take advantage of the technology for current era.

• Computers are now cheap (for server and client). The Raspberry Pi 3+ is $35 and easily has sufficient compute power for RadioMirror server and client.
• Radios suitable for RadioMirror server are now inexpensive. Surplus land mobile radios are ideal - no fancy front panel needed, and are rugged enough for long duty cycles (continuous transmission).
• Radios suitable for RadioMirror clients are now very cheap. Either a inexpensive portable radio can be used, or a Software Defined Receiver dongle can be used.
• The TNC function that RadioMirror requires is now split between a simple audio Input/Output (I/O) interface (the modulator / demodulator in the TNC) and software such as Dire Wolf (the CPU and embedded software). I say "simple" audio I/O interface because there is no need for Push To Talk (PTT) hardware for the audio I/O interface, so the audio I/O interface can be nearly anything - as little as $8 (seach Amazon for "USB Sound Card".

What really elevates the potential of RadioMirror in this era are a combination of factors:

• There's a lot of shared information in Amateur Radio that is hard to keep in sync between individual Amateur Radio Operators. Two examples are Digital Mobile Radio (DMR) code plugs, and DMR ID/callsign tables as new Amateur Radio operators get on DMR with a new DMR ID. This is especially critical if DMR is to be used for EMCOM.
• FM repeaters now have ample unused airtime available, especially in the early morning hours.
• If a RadioMirror server is transmitting through a repeater, it can easily be scripted to only transmit during early morning hours.
• Direwolf can easily achieve speeds of 9600 bps Frequency Shift Keying (FSK), but it can also operate at 2400 and 4800 bps, which is universally usable with every radio using the microphone input and speaker output.
• Direwolf can be configured to use FX.25 - a variant of AX.25 that adds Forward Error Correction (FEC) while remaining compatible with AX.25. FX.25 wouldn't be needed if a repeater is used, but it would be highly useful if a RadioMirror server was not using a repeater.
• For example, a RadioMirror server could use Direwolf to transmit 4800 bps through a repeater. 
• For example, a RadioMirror client could also use Direwolf to receive the repeater's transmissions and be left on continuously. Voice transmissions on the repeater would be ignored (any decodes would fail the checksum).
• RadioMirror and the Raspberry Pi could be configured to save RadioMirror files to a plugged in USB flash drive. When an emergency occurs, grab the USB flash drive and go.
• Web browsers are now ubiquitous. Imagine if documentation such as a club's entire website, file directory, etc. could be distributed via RadioMirror as HTML. Just point the browser at file:///index.html in the RadioMirror client "received files" directory to view the documentation.

Lastly, to address those Amateur Radio operators who cringe in horror at the use of the word "broadcast" and immediately want to point out that "broadcasting" on Amateur Radio spectrum is prohibited... think about it. RadioMirror is a file transmission mechanicsm... just without the requirement of acknowlegements. If I wanted to transmit a series of files to another Amateur Radio operator, and that exchange took hours... that would not be considered broadcasting. RadioMirror just makes that same process much, much more efficient. Not to mention, Amateur Radio VHF / UHF spectrum has a lot... a lot... of unused channel time these days.

In summary, I consider "RadioMirror 2021" to be a "fertile area of research" for Amateur Radio.

Thanks for reading!
Steve N8GNJ in Bellingham, Washington, USA

Post Publication Followup:

More Thoughts on RadioMirror

RadioMirror, Meet flamp