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