Zero Retries 0006

VARA FM Deep Dive - Part 2

Steve Stroh N8GNJ

Aug 20, 2021

Steve Stroh N8GNJ, Editor

Jack Stroh, Late Night Assistant Editor

In this issue:

Intro to VARA FM Deep Dive - Part 2
VARA FM Use Case
More on Experimenters vs Communicators
Something of a Plan for Creating RAMA
A Brief, Imperfect Specification for RAMA
VARA FM on Raspberry Pi
One VARA License Per Computer?
A Primer on OFDM Technology
ZR > BEACON (Brief Mentions)
Request to Send
Feedback Loop
Closing The Channel

Intro to VARA FM Deep Dive - Part 2

Before we get started, RAMA is now the name I’ll be using for the (potential, at this moment) Open Source equivalent of VARA FM that I proposed in Zero Retries 0004. My thanks to Greg Hancock AE7EL for a better name for that potential project. See “Something of a Plan for Creating RAMA” for details.

Request To Send, Zero Retries 0004 - VARA FM Deep Dive:

I felt that [in Zero Retries 0004] I had said all that I could about VARA FM until I get some hands-on experience with it. But you readers had more than a bit of thought-provoking and informative feedback. Thus there will be a VARA FM Deep Dive, Part 2 within a few weeks. That one will require more study, and apparently I’ve been called out on my somewhat cavalier offer to write a “spec” on what VARA FM does as a basis to begin “Pointy Stick”. I’ll do my best.

Other than the next article that would have been logical to include in Zero Retries 0004, I pretty much “left it all on the field” about my (then) understanding of VARA FM. The additional information about VARA FM in this issue is the result of great feedback from Zero Retries readers.

VARA FM Use Case

I’d like to correct a glaring omission that I should have covered (though I don’t know what I would have left out in Zero Retries 0004 to make room for it) -
What is the use case for VARA FM?

In my research on VARA FM, I never saw a formally stated use case for VARA FM, but there was ample anecdotal evidence that the widest use of VARA FM is to replace the use of packet radio, and especially TNCs, as a faster, more reliable transport for Winlink Radio Mail Servers (RMS’) on VHF and UHF, generally using Winlink’s RMS Express software.

Introduction to Winlink
For context in this article, it might be useful to offer a brief introduction to Winlink Global Radio Email for those that are new to Amateur Radio. Winlink is, essentially, an integrated system of software, radio-to-Internet gateway stations, and Internet servers that provide bidirectional email communications between Internet email and Amateur Radio stations using Amateur Radio HF and VHF / UHF spectrum. Email messages can be sent from Internet to an Amateur Radio station running Winlink software, and email messages can be sent from an Amateur Radio station running Winlink software to any Internet email address. (There are limitations as to content, size, etc.) Winlink relies on the “Edge of a Disaster Communications” theory that most disasters are limited in scope, and emergency communications are most needed within the “disaster zone”. Once a communications link can bridge to outside the disaster zone, messages (such as email) can be handed off to normal communications systems such as Internet email. VARA FM is simply a better “radio transport” between individual Winlink users (such as a Amateur Radio Operator using a “Go Kit” and a Winlink Radio Mail Server (RMS). Winlink hands off an email message to its Internet servers at the earliest point possible - Winlink is not (necessarily) used as “radio-only” email (but it can be used that way).

As primary evidence of this, I’ll refer again to an informative video I mentioned in Issue 0004:

MicroHAMS Digital Conference 2020 - Vara Digital on Winlink (2020-05-11) Randy Neals W3RWN. Randy is authoritative with ample hands-on experience with VARA FM, contrasting it directly with use of Packet Radio in an EMCOM organization and why some organizations he works with decided to retire Packet Radio in favor of VARA FM.

I don’t have a lot of experience with EMCOM, but what little experience I do have, especially with newcomers to Amateur Radio, dealing with a TNC in a Winlink system is often relegated to “hope it works”. TNCs are largely unknown technology to most new Amateur Radio operators. There are the vagaries of multi-modal command line interfaces. Then there are the vagaries of RS-232 ports and USB to RS-232 adapters.

But, mostly, there’s the speed issue. Everything about using a Winlink RMS over 1200 bps packet radio is about the the seemingly glacial speed. For example, you don’t send a spreadsheet over 1200 bps packet radio - the files are just too big and thus take too long. Instead you export the spreadsheet data to a comma delimited file (.csv), and send that, and then import it into a spreadsheet. Ditto forms - you create an HTML form, and send that, instead of .pdf files. Etc. Nearly everything is compromised by the slow speeds.

Within hours of writing the above, I was made aware of a video from DEFCON 29 (2021) - Amateur Radio Mesh Networking: Enabling Higher Data-rate Communications. In the video, a report from the 2017 Cascadia Rising exercise in the Pacific Northwest was referenced. This excerpt (Page 7, bottom) is directly applicable to the speed issue:

Existing auxiliary amateur radio processes are slow and not capable of handling the large volumes of traffic expected during an event of this size, mostly due to radio bandwidth issues.

This from an official report of the usefulness of Amateur Radio in emergency communications. So, the speed issue is not merely academic - it speaks directly to the usability of Amateur Radio communications.

The focus of the video above is high speed networking via microwave - Amateur Radio Emergency Data Network (AREDN). I view AREDN and VARA FM as complementary technologies, but that perspective is a hard sell to a lot of individuals and organizations who focus on one or the other. A discussion of AREDN is out of scope for this article, but it will be discussed in depth in a future issue of Zero Retries.

Keep in mind that in contrast to typical Amateur Radio operations where experimentation and learning is generally part of the “fun” of the experience, in EMCOM, you’re trying to communicate, not experiment. In a real EMCOM situation, you generally don’t have the luxury of “figuring it out”.

What about 9600 bps packet? As one of the biggest boosters of 9600 bps packet I know… I can state with certainty that 9600 bps packet radio using Frequency Shift Keying (FSK) is “fraught with peril”. One of the issues (especially with 9600 bps TNCs) is that there were many slight variations of 9600 bps FSK (G3RUH, TAPR, K9NG, Kenwood TM-D710A, etc.) that ended up as “kind-of works”. I told the story of how we made 9600 bps FSK work well using repeaters in The Puget Sound Amateur Radio TCP/IP Network (Circa 1995). Because the repeaters did bit regeneration and reclocking, and the repeaters provided excellent signal-to-noise ratios to all users within range, we were able to interoperate well at 9600 bps.

Unfortunately, absent a truly heroic crusade, the days of getting a data-only repeater online are gone. For example, from WWARA Coordination Policies – December 2017, here is the Western Washington Amateur Relay Association (WWARA) policy on data repeaters:

Section 21: PACKET RADIO COORDINATION
The following is the WWARA policy regarding Packet Radio Systems:
The WWARA shall not issue a Certificate of Coordination to any Packet Radio system, except when the proposed system requires the use of a standard repeater pair or link frequencies. Modulation type and bandwidth shall be considered in frequency pair selection.
The WWARA may require measures to protect existing coordinated co-site and/or adjacent frequency repeater from the effects of system performance degradation caused by Packet Radio Systems. Conventional FCC interference criteria will be used to determine degradation.
The WWARA shall work with the ARRL, regional coordination organizations, as well as local and regional Packet Radio organization in the development of band plans that will set out specific bands for Packet Radio communications.
Nothing in this section shall be construed to apply to digital voice repeaters.

Such policies relegate data communications to a distinct disadvantage versus repeaters used for voice - even when “digital voice repeaters” are effectively, data repeaters - just with the data format “hard coded” for voice.

Thus, with things such as this, 9600 bps FSK is effectively, a dead end technology.

Caveat to the above - the one technology that has the potential to bring 9600 bps back from obscurity into usability is Dire Wolf Software TNC. Dire Wolf implements an excellent version of 9600 bps FSK, and the recent addition of FX.25 makes it even more usable and reliable. We just don’t have many people taking advantage of Dire Wolf at 9600 bps (and potentially faster).

Suffice it to say that using Winlink with 1200 bps or even 9600 bps packet, especially using legacy TNCs, isn’t a great experience. It works acceptably if only simple text emails are being sent, and the occasional HTML form or .csv file. But for what is considered normal use of email in 2021, Winlink via 1200 bps and 9600 bps packet is, increasingly, unacceptable.

VARA FM Use Case Summary
My conclusion is that the defacto primary, current use case of VARA FM is to replace 1200 bps (and 9600 bps packet) for Winlink RMS use with a faster, more reliable radio system.

VARA FM is a faster, more reliable radio system for Winlink that enables the sending of larger files, thus making Winlink easier and more effective to use.

As I explained in Zero Retries Issue 0004, I think there are other use cases for VARA FM, including experimentation, but those are secondary to improving Winlink operations.

More on (VARA FM) Experimenters versus Communicators

A reader who preferred not to be quoted provided some interesting feedback. Because they didn’t want to be quoted, I’ll paraphrase:

In my opinion, the concerns about VARA FM being not being open source are much ado about not much. Such concerns are similar to the concerns about (not open source) Specialized Communications Systems (SCS) Pactor. In short, SCS Pactor has proven reliable, and reliable communications is more important (to me) than experimenting. In the end, worrying about an open source version of VARA FM comes down to… Do you want to experiment? Or do you want to communicate?

Reader - Valid points! You have the argument nailed. EMCOM wants to communicate. The experimenters want to experiment. But, I think what’s different in your allegory is that SCS has scale and stability. EA5HVK with VARA FM seems to be a one man band subject to heart attacks , errant buses, earthquakes, etc. And, being Windows software, the platform underneath VARA FM is constantly shifting sand. Apparently all Windows 10 systems will soon be Windows 11 systems, like it or not. So you need EA5HVK to keep developing. If EA5HVK decides not to keep developing, your investment in a network of VARA FM systems will eventually age out as Windows 10 has proven, and I’m sure Windows 11 will prove, remarkably capable of auto-upgrading despite user’s desires that it not do so.

There’s also a gotcha about VARA that emerged recently. There may to be interoperability issues between different versions of VARA software, as in “not guaranteed”. Perhaps not even between minor updates in VARA software. So there’s a constant pressure to upgrade to the latest versions to preserve compatibility with new VARA FM users.

Another concern is that Amateur Radio can be a very fickle market. More than one developer of Amateur Radio software that many have come to love and depend upon has simply walked away (or passed away) from maintaining said software, and thus it inevitably ages out into unusability because it doesn’t get updated.

Something of a Plan for Creating RAMA

Greg Hancock AE7EL:

Another interesting issue. Thanks! Two thoughts and two questions:
1. Reverse engineering VARA from only over-the-air waveforms should be doable given no encryption is involved. I have experience doing this sort of work for simpler ISM-band protocols (utility metering AMR), and I agree that the tools are available. In addition to GNU Radio, python (numpy, scipy, matplotlib) and octave are quite useful. MATLAB with signal processing add-ons could be helpful, and the hobbyist license is affordable.
2. My suggested name for the open source version of VARA: "RAMA". It means "stick" or "branch" in Spanish. The first definition of vara in my Diccionario esencial de la lengua española is "rama delgada" (slender stick). RAMA also has some interesting meanings in Hindi/Sanskrit.
And my questions:
A. Is there a thorough written disclosure of the design of VARA that would accelerate the reverse engineering process (this is required by the FCC, right)?
B. Are there any pending patent applications related to VARA that would prevent use of an open source implementation due to patent infringement issues?
A mini project plan, as I see it:
Step 0 is checking the software license to make sure it doesn't preclude attempting to reverse engineer the signal.
Step 1 is digging up ALL the relevant technical documentation, even if it's in Spanish or other languages and getting it collected in one place.
Step 2 is getting a good selection of high quality (high SNR), high resolution ADC captures, along with the corresponding decoded data, posted to a Wiki or similar.
Step 3 is picking the easiest/simplest or most universal modulation and data rate as the first one to reverse engineer. (Get some traction, show that it's possible.)
Step 4 is documenting the mode in detail so it can be implemented using any of several possible platforms (GNU Radio being one).
Step 5 is creating a demodulator that works on recorded samples.
Step 6 is creating a demodulator that works on real-time audio or RF.
Step 7 is creating a modulator...etc...
Once that much is done, it should be easier to recruit people to keep working on other modulations and data rates and more portable implementations. Implementing RAMA would make a nice project for an EE student or student group.
(I bet someone at the NSA or an NSA contractor has already done all this work.)

Greg - Other than the VARA FM Use Case discussion that opens this issue, I pretty much “left it all on the field” in Zero Retries 0004 about my understanding (then) of VARA FM. I simply don’t know about patents, “design disclosures”, software license, or any additional technical details. (I welcome the help in researching this.) The only additional technical detail I found (but not previously mentioned) was “VARA Protocol Native TNC Commands”. I suspect that there isn’t much published technical detail as VARA is the creation of a single individual.

Yes, it is a FCC requirement to disclose details of new modulations not specifically mentioned in the FCC Part 97 regulations, but A) the FCC isn't watching Amateur Radio much any more, B) EA5HVK, being in Spain, isn't subject to such requirements, and C) EA5HVK isn't the one operating in the US - that's left to individual operators or groups. Thus, I’d guess that EA5HVK can comfortably ignore the FCC disclosure requirement.

As I tried to make clear in raising the possibility of “RAMA” (I like that name! Done, adopted from now on!), I think RAMA is doable, but I’m personally not equipped to attempt it, except helping at the edges such as documentation and testing.

Your steps sound like a real plan.

In creating RAMA it may make more sense not to try for compatibility with VARA FM, but rather “merely” to meld the same technologies that EA5HVK used (OFDM, different modulations, etc.) into a open source system with equivalent performance - up to 25 kbps (or more) in a 20 kHz FM channel on VHF or UHF.

It's become obvious that I need to create a best guess functional spec of what VARA FM is doing - see next article.

A Brief, Imperfect Specification for RAMA

Again, RAMA is now the name I’ll be using for the (potential, at this moment) Open Source equivalent of VARA FM that I proposed in Zero Retries 0004.

The inspiration for RAMA is VARA FM, which is “shareware” software for Windows that achieves up to 25 kbps data communications on a 20 kHz FM channel using a “wide channel” audio adapter and radio with “flat audio” input and output.

Here is a brief, preliminary, imperfect, incomplete list of what I think RAMA should include:

Open source; RAMA’s specifications, source code, and all other technical data must be made publicly available.
RAMA’s source code should be written to be portable to Windows, Mac, and Linux, including Linux for Raspberry Pi computers
There is no requirement for backwards compatibility with previous Amateur Radio data communications systems such as Packet Radio, 1200 bps AFSK, 9600 FSK, AX.25, etc.
RAMA should be implemented as a “Audio Interface” mode.
RAMA should assume the use of a 20 kHz channel on an FM radio.
RAMA should operate acceptably with computation resources available in a Raspberry Pi 4 computer with 4 GB RAM or equivalent unit (this specific unit mentioned only as reference hardware).
RAMA should make maximum effective use of “wide channel” audio adapters such as Masters Communications DRA-50 or equivalent unit (this specific unit mentioned only as reference hardware).
RAMA should make maximum effective use of VHF / UHF radios with “flat audio input and output” such as the Kenwood TM-V71A with 6-pin MiniDIN "DATA" connector, or equivalent unit (this specific unit mentioned only as reference hardware).
RAMA should make maximum effective use of VHF / UHF radios that have only speaker and microphone connections (versus “flat audio” connections).
When establishing a connection to another station, RAMA should “handshake” (negotiate) with the other station to determine the maximum number of parameters they have in common for reliable communications.
For file transfers, RAMA should (transparently) compress a file to minimal size before transmission, and decompress a file back to normal upon receipt.
RAMA should compute and transmit a checksum to insure that the file that is received does not have errors.
RAMA should determine when a transmission would benefit from use of Forward Error Correction (FEC), and when it would not benefit from FEC. When FEC would be beneficial, it should be applied.
RAMA should include the ability to be a relay node for other RAMA units (digipeat).
RAMA should include optimizations for use over FM voice repeaters, including issues such as long hang time of the repeater (several seconds before dropping carrier), transmission of CTCSS to access the repeater (notch out low frequency OFDM carriers), transmission of CTCSS by the repeater (mute speaker), and other optimizations necessary to use voice repeaters.
RAMA should incorporate Carrier Sense Multiple Access / Collision Detect (CSMA/CD) techniques. If another RAMA station is already transmitting, RAMA should not transmit and thus cause interference.
RAMA should “self calibrate” itself with the assistance of another system on frequency, including parameters such as transmit delay (TXdelay), minimum turnaround time, audio levels sufficient for optimum deviation of the FM radio, etc.
RAMA should support the maximum possible methods of asserting Push To Talk, including supporting the maximum number of audio interfaces and various methods of asserting Push To Talk.
RAMA should use TCP/IP sockets to allow interoperability with other applications.
RAMA should incorporate networking to create a “router” where RAMA communications can transition from one RAMA system to another RAMA system via TCP/IP. Example - A RAMA transmission on 144-148 MHz is received by a gateway system that has another RAMA system on 440-450 MHz, and the RAMA transmission can be seamlessly “routed” between the two networks via the gateway.
RAMA should be compatible with Winlink software and methodologies to seamlessly connect to various Winlink software.
RAMA should incorporate a scripting system that can initiate communications and other actions using a script and scheduling (“cron” tasks).
RAMA should incorporate control over radios as is feasible, and this capability should be part of the scripting system. For example, flrig (part of the fldigi suite of applications).
RAMA should incorporate “pre-set parameters” such as TXdelay and other settings. Example - when switching to a repeater frequency under script control, RAMA should change its behavior to work optimally over that particular repeater. Previous testing should determine optimum parameters so data communications can proceed efficiently without requiring individual RAMA systems to “sound out” the use of the repeater each time it’s used.
RAMA should incorporate “queuing” for data communications that are not time-sensitive.
RAMA should incorporate a “file broadcast” system for efficient distribution of files to all stations. For example - flamp (part of the fldigi suite of applications).

Reader’s inputs to this specification for RAMA are most welcome!

VARA FM on Raspberry Pi

In Zero Retries 0004, I said in passing:

There are some reports that a Linux computer, even a Raspberry Pi, running the WINE compatibility layer on Linux, can be used for VARA FM, rather than an X86 PC running Microsoft Windows.

I was questioned on that statement by more than one reader. Yes, I understand that the Raspberry Pi, using an ARM processor, is a completely different instruction set than what Windows (usually using an X86 processor) is written for. The following points, from my research, are the basis for my statement:

Tom’s Hardware - How to Install Windows 10 on a Raspberry Pi 4
GitHub - Winelink - A Winlink (RMS Express & VARA) installer Script for the Raspberry Pi 4. This script will help you install Box86, Wine, winetricks, Windows DLL's, RMS Express, & VARA. You will then be prompted to configure RMS Express & VARA to send/receive audio from a USB sound card plugged into your Pi. This installer will only work on the Raspberry Pi 4B for now (support for earlier Raspberry Pi models is planned for later).
VARA-MODEM@groups.io list, Message 1712:
Re: VARA FM Under WINE? - Ivan Valentin - Jun 15 #1712:
Currently I have Windows 10 Pro installed running on Raspberry Pi 4 with RMS, VARA HF and VARA FM installed.
I also have another Raspberry Pi 4 with the Ham Radio Build v3.0 linux installed from the friend KM4ACK in which I have installed and functional the RMS and VARA HF using Wine with the instructions that I published in the previous Email.
VARA-MODEM@groups.io list, Message 1715:
Re: VARA FM Under WINE? - Ivan ValentinJun 16 #1715
I use Raspberry Pi 4b 8gb, MicroSD 64GB, & External USB Drive 250GB Running Windows 10 Pro. [See two YouTube videos below.]
YouTube - Easily Install Windows 10 On The Raspberry Pi 4 or Raspberry Pi…
YouTube - Windows 10 Desktop on a Raspberry Pi 4!!!

It’s news to me too that Windows 10 on Raspberry Pi is apparently feasible. I had no idea that open source instruction set translation / emulation - Box86 - was this capable. That said, see More on (VARA FM) Experimenters versus Communicators above. Still, it would be a hoot to see Windows 10 running passably on a $50 or so Raspberry Pi 4.

One VARA License Per Computer?

A reader brought up this issue. When he installed VARA FM, this statement is in the License.rft file:

This software (VARA HF Modem) is SHAREWARE. This means you must register your copy in order to you can use the SOFTWARE without license restrictions.
“Jose Alberto Nieto Ros” grants you a license to use one copy of the version of this SOFTWARE on any one system for as many licenses as you purchase.

In the VARA HF 4.3 QUICK GUIDE Rev, December 29th 2020 (filename VARA 4.3 quick guide.pdf), under VARA LICENSE, there is this statement:

The VARA license is valid for the callsign and his 15 suffixes:
CALLSIGN, CALLSIGN-1, CALLSIGN-2.......CALLSIGN-15 and CALLSIGN-T, CALLSIGN-R and CALLSIGN-X.
There is not hardware restrictions. You can use your VARA license in several computers. In the case of Gateway operation, no license is necessary to get full speed.

I brought up this apparent conflict with a knowledgeable source, who contacted EA5HVK, who agreed that the statement in the “Quick Guide” is correct. EA5HVK stated that the statement in the VARA FM software will be updated to be compatible with the statement in the “Quick Guide”.

Also, I need to clarify that a VARA License is usable for up to 16 systems (not 15) on the same frequency (within range of each other, including digipeaters / repeaters). As in:

N8GNJ, N8GNJ-1, N8GNJ-2, N8GNJ-3, N8GNJ-4, N8GNJ-5, N8GNJ-6 … N8GNJ-15

There are no limitations on repeating these callsigns / SSIDs on a different frequency, such as setting up separate VARA FM systems on 50-54 MHz, 144-148 MHz, 222-225 MHz, and 440-450 MHz (or on multiple frequencies within the same band).

The ability to create multiple stations using the same license will be highly useful to me as I will be creating multiple VARA FM stations as loaner systems to try to generate some interest in VARA FM in my local area.

A Primer on OFDM Technology

Bob Witte K0NR is a fellow volunteer on the Grants Advisory Committee of Amateur Radio Digital Communications (ARDC). Bob mentioned to me that he wrote an article about OFDM (which is one of the modulation techniques used in VARA FM) last year. K0NR’s article - The basics of 5G’s modulation, OFDM (Orthogonal frequency-division multiplexing has become the standard modulation format for 5G New Radio. Learn how OFDM works and how it’s used.) is written to explain OFDM’s use in cellular communications, but it’s general enough to help understand the basics of OFDM.

ZR > BEACON (Brief Mentions)

TAPR’s Packet Status Register (PSR) Newsletter #149 (Summer 2021) is now available.
RTL-SDR.com has a good roundup of radio-related videos from the recent DEFCON 29. I’m particularly enjoying Amateur Radio Mesh Networking: Enabling Higher Data-rate Communications.
SDRPlay - The SDRplay sponsored 11-hour teaching module “Understanding Radio Communications – using SDRs” created by Sapienza, University of Rome has been updated to include improvements and additional materials.
AMSAT Strategic Plan 2021-2035 (PDF)
Johan Maas PA3GSB has created RadioBerry V2.0 - A HF Radio HAT for Raspberry Pi computers. These are available assembled from Amazon and “the usual Asian sources”. The TechMinds YouTube channel reviewed the RadioBerry’s receive function. PA3GSB is already working on amplifiers for RadioBerry.

Request to Send

Apologies for no Amateur Radio In Orbit article this week - the “VARA FM effect” of crowding out other content struck again.

I’m pleased to report that Zero Retries’ readership is (as I do a final proofread) now 116 strong. Prior to Zero Retries 0000, I “seeded” Zero Retries’ subscriber list with less than 20 email addresses of family and friends (some of which have aparently never read Zero Retries), and mention of Zero Retries on two mailing lists. All subscriber growth since then is organic. Thanks for continuing to spread the word about Zero Retries.

One of the benefits of a weekly publication schedule is that it’s possible to “pivot” when it seems merited. Judging by the “engagement” of Zero Retries 0004 - VARA FM Deep Dive, discussion of VARA FM was the most popular topic I’ve written about in Zero Retries to date. And there was more, and more substantive, feedback about VARA FM than other topics to date.

With this issue of Zero Retries, I’ll probably defer writing any further about VARA FM (and RAMA) until I get my VARA FM test systems set up here in N8GNJ Labs and can report some hands-on experience. I now have an offer of a co-conspirator to test VARA FM over a challenging simplex path here in Whatcom County, WA, and that person’s offer is most welcome. As you can see in AE7EL’s article Something of a Plan for Creating RAMA, perhaps there is hope for this wild idea of creating RAMA. Since publication of Zero Retries 0004 on 2021-08-06, there have been other expressions of interest in creating RAMA. Sometimes, it does help to put one’s ideas out there, no matter how speculative.

The Digital Group of the Mount Baker Amateur Radio Club recently elected me as President for the coming year. My “reign of terror” will be 2021-09-01 through 2022-08-31. Wish me (and them) luck as we try some new and interesting things, including using voice repeaters for data modes, a weekly net to discuss all things data communications, and regular guest speakers at our monthly (probably virtual) meetings.

I’m considering options for discussion of common topics of interest in Zero Retries. I’m considering regular virtual meetings using Zoom, and a mailing list. Please let me know your thoughts.

de N8GNJ

Feedback Loop

It’s an indication that I’ve been mostly heads-down writing Zero Retries, rather than exploring all the nooks and crannies of the Substack platform, that Phil Karn KA9Q’s comments on the web version of Zero Retries 0005 caught me by surprise. I knew the comments capability existed, I had just forgotten about it. Go to the link (for any issue), then scroll down to the bottom, where you’ll find an easy-to-use comments section, either to post your own, or read other’s comments.

Other reader feedback for this issue was incorporated above.

Closing The Channel

A commenter in Reddit pointed out that I should disclaim that the views I express in about Amateur Radio in Zero Retries are mostly about Amateur Radio in the US. He’s correct, thus consider it disclaimed that Zero Retries is focused on Amateur Radio in the US. I do my best to think of “rest of world” Amateur Radio in my writing, but I’m not there in other parts of the world, so if I say something blatantly inaccurate, please call me out.

If you’re enjoying Zero Retries, please tell your friends and co-conspirators. For the immediate future, Zero Retries will remain an experiment in progress. Feedback is easy if you’re reading Zero Retries in email - just hit Reply and I’ll get your email. Or you can go to the web version of any Zero Retries issue, scroll to the bottom, and post a comment on the web version of a Zero Retries issue. I’m especially interested in content ideas about things that you’d like to see discussed in Zero Retries. If you know of “Zero Retries Interesting” projects, groups, activities, etc. please let me know. I do reply to every Zero Retries email I receive.

Email issues of Zero Retries are “instrumented” by Substack to gather basic statistics about opens, clicking links, etc. There is no “text only, no instrumentation” version of Zero Retries available. I don’t use such information in any way other than (in the absence of much feedback) getting some satisfaction that the data shows that people actually do read Zero Retries.

All previous issues of Zero Retries are available without restriction (no paywalls). For some background on Zero Retries, Issue 0000 was The Introduction Issue.

Contributors this issue:

Greg Hancock AE7EL - Something of a Plan for Creating RAMA
Several readers that preferred to remain anonymous

Thanks for reading!
Steve Stroh N8GNJ
Bellingham, Washington, USA
2021-08-20
If you’d like to reuse an article in this issue, for example for club or other newsletters, just ask. Please provide credit for the content to me and any other authors.
Copyright © 2021 by Steven K. Stroh

Below is a much more complete “footer” that has evolved over 30+ issues of ZR.

Join the Fun on Amateur Radio

If you’re not yet licensed as an Amateur Radio Operator, and would like to join the fun by literally having a license to experiment with radio technology, here are some pointers:

Ham Radio for Dummies by Ward Silver N0AX is a great overview of Amateur Radio. N0AX is a gifted writer and HRFD is now in its 4th edition.
My two favorite YouTube channels for a good overview of Amateur Radio are AmateurLogic.TV. and Ham Nation (part of Ham Radio Crash Course). These folks just seem to have so much fun!
Radio Amateur Training Planning and Activities Committee (RATPAC) offers weekly presentations on general Amateur Radio topics (Wednesdays) and emergency communications in Amateur Radio (Thursdays).
Dan Romanchik KB6NU offers a free No-Nonsense Study Guide for the Technician test (PDF).
HamExam.org Amateur Radio Practice Exams offers good Flash Card and Practice Exams.
When you’re ready to take an Amateur Radio examination (Tech, General, or Extra), W1MX - The MIT Amateur Radio Society offers remote exams, free for students and youngsters. There are apparently many other remote exam options.

Bonus - with an Amateur Radio license, you’ll be more attractive on dates 😀

Closing the Channel

In its mission to grow Amateur Radio and make it more relevant to society in the 2020s and beyond, Zero Retries is published via email and web, and is available to anyone at no cost. Zero Retries is proud not to participate in the Amateur Radio Publishing Industrial Complex!
My ongoing Thanks to Tina Stroh KD7WSF for, well, everything and Bill Vodall W7NWP as Zero Retries Instigator in Chief.
My ongoing Thanks to pseudostaffers Dan Romanchik KB6NU and Jeff Davis KE9V for continuing to spot, and write about “Zero Retries Interesting” type items, on their respective blogs, from Amateur Radio and beyond, that I don’t spot on my own.
Southgate Amateur Radio News consistently surfaces “Zero Retries Interesting” stories.
The Substack email publishing platform makes Zero Retries possible. I recommend it for publishing newsletters.

If you see something interesting mentioned in Zero Retries and would like to search all the Zero Retries “Back Issues”, that’s now easy - just click:

Search Zero Retries

If you’re reading this issue on the web and you’d like to see Zero Retries in your email Inbox every Friday afternoon, just click:

If you’re a fellow smart person that uses RSS, there is an RSS feed for Zero Retries.

Zero Retries is on Twitter @ZeroRetries - just click:

Zero Retries on Twitter

Please tell your friends and co-conspirators about Zero Retries - just click:

Share Zero Retries

Offering feedback or comments for Zero Retries is equally easy; yes, you guessed it… just click:

Zero Retries