(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: