Zero Retries is an independent newsletter promoting technological innovation in and adjacent to Amateur Radio, and Amateur Radio as (literally) a license to experiment with and learn about radio technology. Radios are computers - with antennas! Now in its sixth year of publication, with 3700+ subscribers.
Steve Stroh N8GNJ, Editor
Tina Stroh KD7WSF, Business / Conference Manager
Zero Retries is usually truncated in some email clients (especially
mobile devices). Thus, it’s easier to read in a web browser:
www.zeroretries.org/p/zero-retries-0269
It’s easy and free (choose the free option) to subscribe
to receive your own copy of Zero Retries every week via email:
In This Issue:
VARA vs xara - The Bigger Picture
Steve Stroh N8GNJ
Once Upon a Time, It Was Possible to “Obscure” Communications Via Radio By Using…
In 2026 and Beyond, We Have Much Better Technology for Amateur Radio HF and VHF / UHF Data Communications… Besides VARA
Supporting Info For VARA vs xara
Steve Stroh N8GNJ
Zero Retries Guide to Amateur Radio HF Data Communications Updated
Aether HF: open-source, AI-coded HF modem with a VARA-compatible host interface
Founding Members Who Generously Support Zero Retries
Comments on This Issue (Redirects to Comments Page)
I-Frame
By Steve Stroh N8GNJ
Brief notes about this issue of Zero Retries.
Founding Members and Paid Subscribers Update
Optional Paid Subscriptions, and especially Founding Member subscriptions to Zero Retries not only help offset various expenses incurred in publishing Zero Retries, but also were a significant portion of the “seed capital” we needed to host Zero Retries Digital Conference (ZRDC) 2026, and future ZRDCs. Thank You!
Our thanks to Prefers To Remain Anonymous 08 for renewing as Founding Member 08 to Zero Retries this past week (4th year)!
Founding members are listed in every issue of Zero Retries!
Our thanks to Prefers To Remain Anonymous 15 for renewing as an Annual Paid Subscriber to Zero Retries this past week (4th year)!
Our thanks to Prefers To Remain Anonymous 102 for renewing as an Annual Paid Subscriber to Zero Retries this past week!
Our thanks to Remain Anonymous 146 for upgrading from a free subscriber to Zero Retries to an Annual Paid Subscriber this past week!
Our thanks to Remain Anonymous 147 for upgrading from a free subscriber to Zero Retries to an Annual Paid Subscriber this past week!
Our thanks to Jason McCormick N8EI for one year of being a Paid Subscriber to Zero Retries this past week!
Financial support from Zero Retries readers is a significant vote of support for the continued publication of Zero Retries.
Please direct comments / feedback about I-Frame to the Zero Retries email list with the hashtag #ZR0269. Paid subscribers can comment directly on the web version of this issue.
VARA vs xara - The Bigger Picture
By Steve Stroh N8GNJ
There are numerous “moving pieces” in the story about VARA “vs” xara1, and many subtleties. The situation is nowhere as simple as the “click baiters” are saying. It’s also quite fluid. What follows is a Zero Retries “deep dive”.
Disclaimers
I am not a lawyer. I have no expertise in software development or intellectual property issues.
I have no involvement with Jose Alberto Nieto Ros EA5HVK (author of VARA) other than occasional correspondence involved in researching articles relating to VARA. At one time, EA5HVK provided me with a gratis paid registration code for use with VARA to access the higher performance capabilities of VARA.
While I have downloaded and stored VARA software (installers), I have never actually installed or used VARA (or EA5HVK’s other software) for use on the air, including the gratis paid registration.
Everything stated in this article is my personal opinion and my best understanding of the related issues, and is offered “without warranty” of accuracy.
Bottom line - In this story, I’ll do the best I can, as fairly as I can.
Once Upon a Time, It Was Possible to “Obscure” Communications Via Radio By Using…
… unusual frequencies. But then we developed universal receivers and transmissions on all frequencies became easy to receive.
… unusual modulations such as signals too wide, or too narrow, or below the typical noise threshold to be detected. But then we developed wideband receivers, and could receive such transmissions and often see them on a spectrum scope.
… very brief transmissions so that casual observers, even with a spectrum scope, might not notice such transmissions. But then we developed “spectrum recorder” capability - the entire I/Q bitstream from a software defined receiver was “just bits” and could be recorded and played back (typically to a computer) with perfect fidelity to decode obscure communications.
… unusual, or unique waveforms that weren’t part of a typical “suite” of digital modes and thus could be received, but not decoded / understood. But then we developed AI tools that could use brute force / rote approaches to decode transmissions to try to discern the actual communication.
And, most relevant to this story, once upon a time, it was possible to “obscure” communications via radio by using proprietary software to encode and decode transmissions.
But then we developed AI tools…
that could analyze the public elements of using proprietary software.
Stage 1A: Map the Inputs:
The various unique settings that you enter (your data) into the proprietary software, such as callsign,
A text string or data file (your data) input into the proprietary software.
Stage 1B: Map the outputs:
Commands sent to the radio,
The unique waveform generated for transmission as a result of inputting your data.
Stage 1C: Iterate
Iterate Stage 1A and 1B at previously unimaginable speed and scale to create a “map” of commands and data to the resulting waveform.
Stage 1D: Generate a “map” of all conceivable inputs and resulting outputs
Stage 2: Generate a Specification
Create a detailed specification of how an application that is written from scratch can accomplish the above.
Iterate at previously unimaginable speed and scale until the specification is 100% accurate for all the inputs and outputs.
This isn’t the software (that’s the next stage). This is the “guide” for how the software should work.
Stage 3: Create the software
Have a software engineering AI write software in portable code that can be ported to the three (arguably four) big Operating Systems - Windows, Linux, MacOS, and Raspberry Pi OS2.
The resulting software should be “workalike” and interoperable with the original application.
Stage 4: Test the software
Test for interoperability between the original application and the newly developed application.
Ideally, test it on all target OS variants.
Stage 5: Ideally, develop some documentation.
This is where most open-source software falls down. Just as AI has automated software development, and AI can “write”, it just makes sense to create AI-assisted software documentation.
Stage 6: Release the newly developed software.
If it were me, I’d set up an email inbox “complaint / suggestion” department and have an AI process the received emails and generate automatic replies.
The above is “it seems to me”. As a not-a-software-developer nor even availed myself of vibe coding, this may not be an actual process flow. But it could be. That’s the way I’d (attempt to) design it.
Note that at no time in the process I describe above was the proprietary software “decompiled” or otherwise analyzed - only the inputs and the outputs. Confining such a process to just “seeing” the inputs and the outputs might seem excessively tedious and time-consuming… and you’d be right. But AI-assisted software development is now exponentially more powerful, at scale, and makes such an approach practical (again, in my opinion).
This is akin to a human software developer creating a workalike radio mode using educated guesses and fine-tuning and repeated testing… but having a human(s) in that loop may require many person-years of focused work by a human(s). Now that same process can take as little as hours, or at most days (given sufficient access to AI tools).
This approach is referred to as the Clean Room Approach, and as usual, Wikipedia is our friend: Clean-room design for a more thorough explanation than my inexpert description above.
My Appreciation for VARA’s Contribution to Amateur Radio
I’m on record that my primary interest in Amateur Radio is being able to experiment with data communications via radio. I have always been fascinated by data communications. I became involved in Amateur Radio in the 1980s when Amateur Radio Packet Radio was introduced. At that point, Amateur Radio was interesting to me and I immediately began using Amateur Radio Packet Radio.
For most of my Amateur Radio career I was content with maintaining a (US) Technician class license as that license class gave me every Amateur Radio operating privilege on frequencies 50 MHz and above which was where the most progressive Amateur Radio Packet Radio activity was occurring (including space / satellite operation). HF operation has never appealed to me as much as VHF / UHF operation appeals to me, mostly because the available technology for digital communications on HF wasn’t very impressive or technologically sophisticated.
I decided to upgrade my US Amateur Radio license to General only when data communications on HF frequencies became sufficiently interesting and approached the same level of sophistication as Amateur Radio Packet Radio on VHF / UHF.
The development, sophistication, and utility of PACTOR and VARA HF, developed specifically to deal with the vagaries of the HF bands was part of my motivation.
Data communication over Amateur Radio has generally been “stuck” with packet radio technology that hasn’t significantly progressed much from the mid-1990s. I began writing Zero Retries in 2021 because there were some “bright spots” emerging in Amateur Radio data communications, but weren’t “packet radio” and thus, little known, and not widely understood. I wanted to make those “bright spots” more widely known, and Zero Retries seems to have caught on.
One of the brightest spots in my evolution of Zero Retries was learning about VARA FM and writing about it (pretty extensively). VARA FM was unique, and uniquely effective, in Amateur Radio data communications, for a number of reasons:
VARA FM did not attempt to be backwards-compatible with Amateur Radio Packet Radio - it was a clean sheet of paper approach.
VARA HF and FM was the first data mode for Amateur Radio (that I’m aware of) that made use of Orthogonal Frequency Division Multiplexing (OFDM) techniques in the audio bandwidth of a typical HF or VHF / UHF Amateur Radio,
VARA FM could achieve, with ideal conditions and ideal equipment, up to 25 kbps on a 12.5 kHz VHF / UHF channel. The best available speed using packet radio was 9600 bps, and that was problematic.
VARA FM layered many techniques in addition to OFDM to achieve robust, reliable, and fast data communications, including Forward Error Correction (FEC), negotiation of highest common capabilities between sending and receiving station, and most impressively to me, ability to share VARA FM’s higher performance (Wide) mode and lower performance (Narrow) mode on the same channel. Amateur Radio Packet Radio had never been able to accomplish that.
VARA FM could take full advantage of radios that had flat-audio (“9600” / “data” connections) and higher performance audio interfaces, if available.
For radios that did not have flat audio connections, only microphone and speaker connections, VARA FM could still exceed 9600 bps (approximately 12 kbps) with all the other advantages of VARA FM such as FEC, etc.
VARA HF and FM were easy to interface with other software from the use of a published set of TCP/IP sockets and simple command set.
Most impressively, for hardware, VARA HF and FM required only a typical Windows computer, and was even able to run on small, relatively inexpensive “appliance” PCs (albeit which still had multiple cores and GHz clock speeds).
The price for full performance / full feature VARA HF and VARA FM license key was less than a new “TNC-like” device, and a small fraction of the cost of a Pactor 4 modem.
One example of the price / performance of VARA FM is that I’ve read of a number of emergency communications organizations’ members converting from using 1200 bps Packet Radio to VARA FM. They purchase a new audio interface such as a SignaLink USB and a VARA license. Then they used their existing Windows computer and existing radio, and were able to achieve 10x the data speed of 1200 bps Packet Radio, with much greater reliability.
VARA was one of the first data communications modes for Amateur Radio to demonstrate how much Amateur Radio data communications could be improved by taking advantage of new technology, such as inexpensive and powerful compute power to implement technologies such OFDM and FEC.
VARA HF and VARA FM are now widely implemented and in active use in Amateur Radio for casual communications and access to Winlink Radio Mail Servers (RMS). Communications using VARA HF and VARA FM are generally faster, more robust, and more reliable than Amateur Radio Packet Radio.
I’m grateful to Jose Alberto Nieto Ros EA5HVK for the work he put into VARA HF and FM to demonstrate, with a working system, how much better Amateur Radio could be doing data communications beyond Amateur Radio Packet Radio.
I’m also grateful to the many other Amateur Radio Operators who developed effective documentation, presentations, and demonstrations to help the rest of us to familiarize ourselves with how to understand, set up, and use VARA HF and VARA FM.
I’m especially grateful to several Amateur Radio Operators who worked individually with me to help understand VARA FM and explain it in Zero Retries.
What Doesn’t Work So Well With VARA HF and VARA FM
VARA HF and VARA FM are distributed as a “crippleware” Windows application. You can install and use VARA HF and VARA FM immediately on its lowest performance tier. To “unlock” the higher performance tiers and all features requires payment to EA5HVK for a unique “license key”.
Beyond that factor, these are the primary complaints about VARA HF and VARA FM that I’ve heard:
It’s only available as a Windows app. Thus it’s problematic to run on Linux and small dedicated computers such as Raspberry Pi only through the use of a Windows emulator layer such as WINE. There is also no version for Mac computers, other than using WINE or other Windows emulators.
The issue with Windows is not solely “I don’t like Windows” (for whatever reason). It’s that Windows has become problematic for use in systems that need to be reliable and unattended. Windows now has a “mind of its own” with no influence by the user about when (or if) to attempt updates, when to phone home, updates breaking compatibly or settings (like audio settings critical to VARA).Windows requires significant resources on a host computer.
It’s not open source - you cannot “dive inside” VARA HF or VARA FM to understand the internals of how it works, or change it.
It’s the product of one person, and at the whim of that person, VARA can be changed, or discontinued, or whatever else the author chooses to do.
The VARA 2027-01-01 Poison Pill Update
That last point is amply illustrated with the release of updates for VARA apps dated 2026-11-04.
Reportedly, the only change in these new versions is a “poison pill” that on 2027-01-01, breaks backwards compatibility with any earlier version of VARA.
After the release of the newest version, the “poison pill” has been demonstrated independently by establishing communications between a system with an earlier version of VARA and a system with the most recent version of VARA. Then, advances the latter system’s clock to 2027-01-01 or later, and the two systems can no longer communicate.
While such a “feature” can perhaps be defended as “forcing common versions”, the timing of the release of that newest version is… curious.
In the end, it’s the right of VARA’s author to do with VARA whatever they wish to do. It’s their creation. They do not need to care about effects to the user base (their one-time fees have already been collected).
But, in my opinion, the release of the updates for VARA apps dated 2026-11-04 surrendered any “moral authority” by VARA’s author. While, again, it was their right to do so, doing so broke the trust of the user base that trusted VARA’s author to not do such things, especially attempting to do so as “secret sabotage” (my terminology).
I’ve seen evidence of significant irritation within the VARA user community about the VARA apps dated 2026-11-04. In previous years, such irritation wouldn’t have amounted to much.
But… what’s different in 2027 and beyond is there are now many viable alternatives to VARA HF and VARA FM… and I’ll explain that it’s easy and effective to use those alternatives in 2027 and beyond.
In 2026 and Beyond, We Have Much Better Technology for Amateur Radio HF and VHF / UHF Data Communications… Besides VARA
There’s now a reasonably long list of alternatives to VARA FM and VARA HF in 2026 and beyond. Here’s just the ones I know about. For links on most of these, refer to Zero Retries Guide to Amateur Radio HF Data Communications - Systems for “Advanced” Data Communications on Amateur Radio HF.
Aether HF (see mention in this issue’s ZR > BEACON)
Amateur Radio Digital Open Protocol (ARDOP)
Data2G (brand new to me, discovered in research for this story)
FreeDATA
Hush
Ion HF (brand new to me, discovered in research for this story)
Modem73
NinoTNC
Rhizomatica Mercury
Robust PACKET
VardeFM (brand new to me, discovered in research for this story)
And…
xara. Much more detail on xara below.
Still in development:
All of those other data communications systems have various features, data speeds, modulation methods, maturity, licenses for use, support for various operating systems, etc.
Like VARA, they all use normal Amateur Radio radios, using the audio channel to transmit data. The point I’m demonstrating is that unlike when VARA HF and VARA FM debuted, there are now (arguably) equally “advanced” data communications systems, (arguably) technically equivalent to VARA in speed, performance, etc.
Arguably, because we don’t really know quite yet. Some of these systems are quite new such as Aether HF, Hush, and Modem73. Unlike VARA, all of these systems are considered still under development, at least to some extent. It will take time to conduct reasonably rigorous comparisons, such as using a HF simulator that can replicate HF conditions from test to test to ensure that there’s no handicapping of one system from a bad day on the HF bands.
So… What Happened With xara? Why Did x0rro Delete It?
Honest answer - I don’t know.
Careful readers will note that I’m not referring to xara in the past tense. That’s because xara does… and will continue… to live on.
It’s no secret that VARA’s creator wasn’t happy that xara came into existence. What follows is speculation… guesses… my personal opinion.
VARA’s creator didn’t like “competition” for VARA and felt their income stream was threatened when xara didn’t enforce the requirement to buy a VARA license for xara “full performance mode”.
VARA’s creator was embarrassed that xara is so good. It used modern techniques, modern libraries (rather than VARA’s old deprecated libraries), it didn’t require an app for HF operation and a different app for VHF / UHF operation. It didn’t help that xara ran so efficiently on Linux that it worked pretty well on a Raspberry Pi computer.
VARA’s creator felt threatened that although xara was released solely as running on Linux, xara as open source code could quickly be ported to other operating systems, including MacOS… and (uh oh…) Windows. And, it was.
xara’s creator has not revealed, definitively, how xara was created other than AI software development was used. Without “full disclosure”, it will never be known exactly how xara was actually developed.
Worst of all for VARA’s creator, xara was released as open source. It was immediately, widely downloaded and forked on GitHub and other platforms, including privately.
In Internet-based intellectual property disputes, the tool of first resort for software authors that feel aggrieved is to assert a DMCA Takedown Notice against platforms that are distributing “accused” software. Wikipedia - Notice and take down. It’s instructive on the Wikipedia article - …in response to court orders or allegations that content is illegal. As I understand it, once a DMCA Takedown Notice is asserted, the burden of proof is on the accused entity to refute the allegations in the DMCA Takedown Notice.
In this case, the DMCA Takedown Notice would have been filed against GitHub who, I’m guessing, notified x0rro with a deadline3.
Again, guessing, x0rro may have “done the math” and realized he wasn’t going to win a DMCA dispute, asserted on GitHub without a lot of work. I’ll guess such a thing is routine for GitHub, and they want to be seen as responsive to DMCA Takedown Notices… to not get sued and keep the attention on the accused entity rather than GitHub.
Given that xara was a hobby project by x0rro, it just didn’t make sense to consume significant time and (legal $$$) resources to defend xara and likely eventually be required to “go public” about their identity.
Thus, x0rro chose to proactively shut down their xara repository on GitHub.
To be crystal clear transparent, the above is my guess / opinion. I don’t know that the process I describe was used, but in my (inexpert) opinion, it’s possible.
So, VARA’s Author “Won”… Right?
Well, VARA’s author definitely won the battle against x0rro to stop their distribution of xara.
But xara was widely downloaded, forked, quickly put into use on the air. Inevitably there are many copies of xara out there in the world, perhaps using other names - sara? tara? uara? wara? yara? zara?
Hereafter, I’m going to refer to the software in the xara ecosystem as ?ara. When I’m referring specially to xara, I’ll use that name.
And I’ll guess that there’s little to prevent proficient… or perhaps just average software authors… with help from AI software development, from figuring out what changes in VARA on 2027-01-01 and re-establishing the interoperability of their ?ara with VARA.
But I can also imagine a potential “won the battle, but might lose the war” scenario…
What would happen when VARA breaks compatibility with earlier
versions of VARA on 2027-01-01… and ?ara…
forks (splits) into “before 2027-01-01” and “after 2027-01-01”?
Let’s play out this scenario a bit.
One of the most interesting aspects of the emergence of xara is that the “VARA ecosystem” almost literally overnight, got significantly bigger. That’s because a lot of experimenters use Linux and prefer open source, and VARA being neither, wasn’t of interest to that community.
But when xara emerged, the barrier to entry for VARA for the Linux / open source folks was removed. Download it, recompile it for full speed operation, install it, and use it, study it. The scenario explained by Craig Lamparter KM6LYW is typical of the xara activity that I observed:
So… why would the ?ara users stop their fun…
just because they can no longer communicate with VARA? As I argued in Zero Retries 0268 last week, that crowd would never have been a user / paid customer for VARA.
And, if the ?ara users want to communicate with friends who are Windows (or Mac) users, apparently there will be variants of ?ara for Windows and Mac (and Android, and iPhone / iPad.
Think that unlikely? Consider:
VARA (for full performance) is expensive; ?ara is free.
VARA is only available for Windows4; ?ara can be run on everything.
VARA requires lots of resources (CPU, RAM); ?ara is very efficient.
VARA is proprietary / closed source; ?ara is Open Source.
VARA can only be changed by its author; with access to the source code of ?ara can be experimented with endlessly.
VARA is hard to integrate into other systems because it requires its own instance of Windows; ?ara is small, portable, efficient and thus can be integrated into other systems - like has been done with DigiPi, where it’s just one data mode option of many.
VARA is used by emergency communications, generally to communicate with Winlink Radio Mail Servers; ?ara can be used casually.
My guess?
The VARA ecosystem and the ?ara ecosystem will, in fact, begin to fork on 2027-01-01.
But (probably) contrary to the intent of VARA’s author, to “bring everyone back into VARA”. Instead, the network effect begins to work against the VARA ecosystem.
Instead of VARA being the preferred software to communicate via data communications (especially on HF), the ?ara ecosystem will continue on its merry way and leave compatibility with “New VARA” behind… and not miss it.
When / if that happens, the network effect begins to work against the VARA ecosystem because the barrier to entry for ?ara is simply lower than using VARA.
The Major VARA Self-Own - VARA Protocol Native TNC Commands
One of the most interesting things about VARA is that it’s very easy to communicate between an application and VARA with the use of the publicly documented VARA Protocol Native TNC Commands.
What many of the new data communications systems listed earlier in this article have done was simply emulate the VARA Protocol Native TNC Commands. Thus 50% of the major issues of establishing a new data communications system are instantly solved. Any application that can make use of VARA… can use any of those other systems that support the VARA Protocol Native TNC Commands. To pick a few applications endorsed by Winlink as examples:
MacWinlink can easily use VardeFM5 instead of VARA FM
Winlink Express can easily use Mercury6 instead of VARA HF
VarAC7 can easily use… well, nearly anything (I’m looking forward to that).
I could go on, but I trust the point is made.
Thus interfacing existing apps with any of the new data communications systems that implement the VARA Protocol Native TNC Commands is a non-issue. No new apps are needed - the existing ones work fine. Any new apps, land any new data communications systems will likely adopt the VARA Protocol Native TNC Commands as a baseline.
This situation has a strong precedent - the Hayes AT command set. Hayes (landline modems) created the “AT Command Set”… and it was so well documented that it became the defacto command set of every other landline modem, resulting in any software (that implemented the AT Command Set) worked with any modem.
The Other 50% of Using New Data Communications Systems
Now things get really interesting and I think you’ll really start to see the problem that VARA’s author has inflicted upon themselves.
One of the most interesting things I’ve seen lately with these new data communications systems is that the majority of them are implemented to be native Linux. When they are supporting operating systems other than Linux, it’s generally a port from Linux.
Recall this bullet point from earlier:
VARA requires lots of resources (CPU, RAM); ?ara is very efficient.
So, what has happened already (I’m not postulating this) is that some users on HF have already implemented their stations to run multiple data modes, simultaneously under Linux.
Want to have your HF system able to accept connections from VARA, or Mercury, or Ion HF? You might have certain friends that are using all of those, or you want your Winlink RMS to be a Winlink “SuperRMS8” and able to connect with “legacy VARA”, but also these newer, more robust, better performing data communications modes like Mercury and Ion HF. Or maybe the Aether HF user group wants to do a weekend stress test of a new build. Or maybe the creator of Modem73 decides to sponsor a contest for using APRS for “worked the most Love’s truck stops”.
In all of those cases, because these new data communications are Linux, generally “command line only” (often with an optional display), efficient, and free… it’s a minor issue to load them onto your system and configure them to operate simultaneously, with all of them talking to your favorite app. They’re all decoding from the same (virtual) audio channel, and whichever app gets a decode from someone connecting to your station with a system that you’re running, that’s the one that takes control of your favorite app’s interface and you just communicate seamlessly.
But… but… but… you don’t want to give up on VARA, but you don’t want the hassle of trying to run VARA on Wine on Linux to be able to use VARA plus the others?
You don’t have to. A Windows app like VARA → WINE → Linux is only one way to accomplish this.
But another, equally valid solution for this is to run Linux on Windows9:
Linux Apps → Windows Subsystem for Linux → Linux → Windows.
Putting These Disparate Pieces Together Into Conclusions
xara was just one facet of a technical evolution of new data communications systems that, like VARA, use the audio channel of existing Amateur Radio radios.
In many ways, xara was a better implementation of VARA - more efficient, ran on Linux, could be ported to other systems such as MacOS (yay!), and x0rro, xara’s author attempted to offer homage to VARA and VARA’s author.
VARA’s author badly overreacted in the opinions of (some? man? VARA users by (likely, in my opinion) instigating a likely DMCA Takedown Notice on x0rro’s xara GitHub repo.
VARA’s author forcing a realignment of VARA software (and users) to the one true version of VARA on 2027-01-01 may backfire and cause resentment.
xara is dead; long live ?ara! With xara being released and quickly downloaded and forked… the “?ara genie” is well and truly out of the bottle.
With the poison pill versions of VARA now released (and, I’ve seen references that they will be required by Winlink), backwards compatibility with VARA by ?ara is likely a dead issue, or will be on 2027-01-01. The ?ara / Linux crowd won’t care - they have lots of new toys to play with that (provably - open source) don’t have poison pills or authors with ill intent towards their users.
If ARSF10 (Winlink) wants to distance itself from the VARA “poison pill” instigated by VARA’s author and move forward with newer, more capable technology, it can begin testing these new systems and encouraging Winlink RMS stations to support multiple systems while retaining backwards compatibility with VARA (as I explain above). Doing so can tap into the much wider user base that will inevitably emerge from Linux experimenters enthusiastically getting on the air with these new systems.
The Opportunity Cost of VARA vs xara
If Winlink doesn’t quickly begin to support other data communications systems, it’s feasible that a new network of Internet email via Amateur Radio might emerge with a looser structure, and using newer techniques like better client apps, IPv6 or 44Net or Starlink, and more peer-to-peer email handling. This is happening:
VarAC supports peer-to-peer email for forwarding Internet email.
See the (really nice) Island Magic apps for Mac / iPhone / iPad; there is now an experimental version of RadioMail that supports Mercury.
DigiPi has demonstrated experimental support for Mercury, Modem73, VardeFM… not just xara.
I remember seeing a post (too many bookmarks on too many systems) where a Winlink RMS, or a station on the TPRFN was already implementing multiple simultaneous new data systems as an experiment.
The mention of DigiPi and the efficiency of xara is an example of the opportunity cost to the VARA ecosystem and Winlink. There are thousands of DigiPi stations in the world… and none of them could connect with Winlink via VARA because that’s not an option on a minimalist Linux system like DigiPi11. But xara was compatible with DigiPi, and until this kerfuffle, xara might have been a standard feature of DigiPi, growing the VARA ecosystem, and potentially traffic on Winlink, by hundreds or thousands of new stations and users.
Another opportunity cost of VARA vs xara is radios like HF Signals sBitx and zBitx radios that are based on Raspberry Pi embedded computers and run Linux internally. xara could probably have been added as a feature and, again, grow the VARA ecosystem and traffic on Winlink by hundreds or thousands of new stations and users.
Neither DigiPi nor HF Signals radios would ever have been potential users of legacy VARA (running on Windows). So there was never any lost revenue to xara running on those platforms - only potential new (paid) users that were grateful for VARA’s author’s great work in creating the ideas of VARA.
But… not now. Winning a battle is not the same as winning a war when the opposition has more, and better logistics like Linux based technology.
Personal Conclusions of VARA vs xara
Those like me who like to experiment with all things Digital and Fun data communications in Amateur Radio will now move on from VARA.
I can’t wait to experiment with any of the new data communications systems that position themselves as equivalents of VARA FM in making use of wider channels than 2.8 kHz on VHF and UHF, such as VardeFM:
linux_arm64.tar.gzRaspberry Pi 3/4/5/Zero 2 W, 64-bit Raspberry Pi OS (Bookworm or newer)
darwin_arm64.tar.gzMac with Apple Silicon (M1 or newer), macOS 11 or newer
Woo hoo - a Raspberry Pi image and Mac version!
Mode Radio connection Audio band Net rate (7 speed levels)
narrowmic/speaker, any FM radio ~420–2670 Hz 0.7 – 7.4 kbit/s wide
9600 data port (flat audio) ~280–6000 Hz 1.9 – 18.7 kbit/s
Woo hoo - provisions for faster data using a radio with a flat audio12 port!
What I won’t be doing is experimenting with VARA FM (or VARA HF). I would have, especially after xara became available for use on a Raspberry Pi. I bought a stack of surplus Windows 10 laptops expressly to set up multiple test systems to experiment with VARA FM as an advanced audio OFDM platform in Amateur Radio VHF / UHF as part of my planned interoperability testing in N8GNJ / Zero Retries Labs.
But after the VARA poison pill of 2027-01-01, I no longer have any interest in VARA. That void will be filled with the other interesting stuff out there.
Now those laptops will be probably repurposed for Linux13, with at least one reserved as Windows for running VarAC with other data communications systems, communicating via…
VARA Protocol Native TNC Commands
which lets me set VarAC to connect to “VARA FM” and it will work just fine with… whatever.
Or… maybe not?
Video - VarAC Rust - Linux / macOS port underway
This morning Iraq, VaraC developer, made an important announcement regarding the project. He has ported to RUST and is working on a Linux and macOS version!
Wow… I completely missed that! Now I’m even more enthusiastic about VarAC!
…
I’ll probably try out xara out of curiosity and keep it available as an option. From what I’ve read, it’s the same on-air performance as VARA FM, so it may make a nice benchmark.
It’s still in my plans / potential budget for the “last big new HF rig” sometime in 2027. The current HF rig of choice is a FlexRadio Aurora, and most of my HF operating will be semi-automated data communications.
If there are Winlink RMS stations that support newer data communications systems such as Mercury, then getting active on Winlink is a possibility. But if Winlink sticks with VARA… meh.
It’s their loss.
Please direct comments / feedback about this article to the Zero Retries email list with the hashtag #ZR0269. Paid subscribers can comment directly on the web version of this issue.
Supporting Info For VARA vs xara
By Steve Stroh N8GNJ
This article is a collection of other perspectives / analysis of the VARA vs xara situation.
Direct email from x0rro Introducing xara
Included for background. My exchange with x0rro appeared in a previous issue of Zero Retries.
greetings, i am the author of xara, the VARA-compatible HF/FM modem for linux. someone on reddit said you might be covering xara in your next newsletter. if so, that's fantastic. i wanted to reach out and offer to answer any questions you might have about the project. let me know.
x0rro’s Initial Post on Reddit about xara
introducing xara, an open source sound modem for linux fully compatible with VARA HF 4.9.0 and FM 4.4.0.
it runs on desktop linux and will run on a raspberry pi model 3b+ or better. listens on KISS and other TCP ports, and has a web UI. release yourself from the shackles of proprietary windows software.
https://github.com/x0rro/xara
binaries provided on the releases page
As always with Reddit, lots of follow-on discussion. In those discussions you can see the stark divide that there is with Linux enthusiasts towards VARA, and their enthusiasm for the development of xara.
Direct email from x0rro:
effective immediately xara is discontinued. i will be focusing my efforts on other projects for the betterment of ham radio as my time has now opened up :)
https://www.reddit.com/r/amateurradio/comments/1xqutu9/vara_breaks_compatibility_on_20270101/
x0rro
Disclaimer
I have chosen not to engage with x0rro in reply to this email. At this point, given that I’m very publicly discussing this issue, irrevocably in text that I’ll never be able to retract… it’s probably better that I don’t ask and thus don’t know any actual details (that aren’t made public) about exactly how legal issues (if any) happened, who said what, and who did what, etc..
VARA breaks compatibility on 2027-01-01
This is the opening article on Reddit that x0rro referenced.
The VARA wars have officially started.
Presumably as a reaction to xara and other open sourcing efforts of VARA, EA5HVK has released a new version of VARA a few days ago. This version doesn’t contain any significant changes except for breaking compatibility with previous versions at a pre-defined date of 1st Jan 2027.
The date VARA decides upon is taken from the computer’s configured datetime.This is not communicated from EA5HVK so far, presumably hoping that open source hackers wouldn’t notice (really?), and so VARA users are left in the dark except for a nondescript note in the changelog of the HF version that is available only once you install it.
Overall this seems like a strange move. This is unlikely to hinder open source implementations in any way, support for the new standard is unlikely to be difficult to add and presumably will be done in a matter of days and it seems not difficult for open sources to simply support both versions. Meanwhile VARA users receive no communication and previous versions will simply fail to connect without much explanation after the end of the year.
It seems to me this hurts VARA users more.Strange times.
In that discussion, there was a great informative post by Andrew Rodland KC2G:
Please consider checking out Data2G if you have to go through the pain anyway! It’s not reverse-engineered from VARA, and it’s not on-air-compatible with VARA (but hey, neither is VARA now!), but it’s open-source, cross-platform, faster and better than VARA (if I may say so myself).
It’s compatible at the TNC level with apps written for VARA (including pat for Winlink), but it also has some really nice new features that VARA doesn’t, and there are already apps for it. In particular my friend AG7EW wrote Ragtime which is roughly in the same ballpark as VarAC but nicer to use, supports both broadcast and connected chat, broadcast and connected file transfer with fill-ins (think bulletins, or FLAMP if you’re familiar with that), small images and even “voicemail”.
Probably one of the next things we’ll be working on is some nice things for conducting nets over Data2G, including a check-in mode that looks like FT8: everyone talks at once in their own narrow slice of the passband and net control decodes everyone within a round or two. But what I’d really like is more users and to find out what they want.
Cool mention of flamp!
But even cooler is that I discovered…
Data2G
I discovered more about it - someone had already alerted me to it - apologies for not remembering who.
Data2G is an HF data modem designed to foster fun and experimentation in amateur radio. You get state-of-the-art speeds and error correction (up to 6400 bits per second net throughput on a good channel), a flexible programming interface (compatible with apps that expect the VARA HF TNC, but extended), and most importantly it’s open-source and free to use without speed restrictions.
And did I mention it’s fast?
Both connected (hybrid ARQ) and broadcast (FEC) modes are available.
A 2400Hz channel is required for full speed but Data2G can be configured for a maximum bandwidth of 500Hz to fit within narrowband segments of the bandplan.
And I also discovered…
Ragtime
A plain, friendly chat and file-transfer client for Data2G, the HF data modem by Andrew Rodland, KC2G. Ragtime is a sibling of Glissando, Jeff Baitis’ (AG7EW) chirp-mode chat app, and is named for the same musical family and for the ragchew.
Ragtime helps you keep in touch. Every burst it hears teaches it when, and on which band, each of your friends gets through, so it can tell you who is likely around now, and the best time of day to check in to the D2G net to find them.
Both are definitely now on my RADAR to explore as an interesting HF data communications mode, and corresponding app.
x0rro’s xara GitHub Repository - current:
development and distribution of xara is discontinued effective immediately [5 days ago]. sharing xara with the world proved one thing: there is demand for a lightweight, high-performance HF and FM modem that runs on open platforms. i encourage people who found xara useful to try the following modems:
mercury
openmodem
new modems as they come out
He’s out.
XARA discontinued
New thread on Reddit, and even more “vigorous” discussion ensued.
Looks like XARA, a reverse engineered version of VARA, got discontinued by the creator. Not surprised given how it's been so closely guarded but it's still surprising to see.
https://github.com/x0rro/xara
Here's what it was just a few days ago https://web.archive.org/web/20261030005908/https://github.com/x0rro/xara
It’s a fantasy from the 20th century to think that invoking “legal” can make something completely disappear in the 21st century. My biggest problem with a 64 GB MicroSD card is to not sneeze while I’m holding it for fear it will disappear and I’ll never see that 64 GB of data ever again.
xara discontinued effective immediately
Great informative post on the Zero Retries email list by Ben Kuhn KU0HN (one of many such posts by KU0HN and others):
I haven’t tested myself, but by my reading it has been confirmed. Users are able to simulate the breakage by simply changing the date/time on one PC involved in a connection past the January date and restarting VARA on both ends.
Regarding the “legitimacy,” that’s armchair lawyering, and the first question is “what makes it illegitimate?” It’s completely different software, written in a completely different programming language. You can’t natively run VB6 code on Linux, so it’s very clear it’s a totally different “Product.”
If you are concerned about how it was produced, most jurisdictions allow reverse engineering to varying degrees to achieve interoperability. X0rro also claims to have used over-the-air transmissions to achieve interoperability which is not reverse engineering the software at all. The simplest explanation for why it was discontinued is he received a cease and desist from Jose. There is no concept of “innocent until proven guilty” in civil matters, so they would be likely looking at tens of thousands of dollars in legal fees to prove they did nothing wrong. Since there is no profit associated with xara, that would be a very burdensome out-of-pocket expense.
All that aside, now that vara’s “spec” is out there in the xara code, any implementation based on that spec would be a clean room implementation. I’m guessing that’s why the poison pill is being inserted.
Jason Johnson K3JSJ via email:
An update on the XARA project and a VARA update that will break stations in 2027.
The VARA developer released an update on 11/4/2026 (VARA HF 4.9.1 and VARA FM 4.4.1). There were no details given on the reason for the update and no details on what was updated. Discussions on Reddit and VaraHF Facebook group indicate the VARA developer has introduced a change to force an incompatibility with previous versions of VARA - and in turn the XARA modem (as it currently exists).
Jason Johnson, K3JSJ, tested and confirms the new VARA version (HF 4.9.1) will work with existing versions until midnight local time on December 31, 2026. Starting at 12:01 AM on January 1, 2027 (local time) the VARA modem (HF 4.9.1) will NOT connect to prior versions. Reference: post 11/11/226 on the WINLINK Program Group on Google groups.
X0rro shutdown the project around 2300 UTC Sunday November 8th with a statement encouraging operators to consider Mercury, openmodem, and other modems.
This is leading to a lot of discussion and debate in the community. More information and continued coverage can be found on K3JSJ’s blog and the “Ham Radio Community” YouTube channel
http://k3jsj.net/xara-project-shuttered/
http://k3jsj.net/vara-breaks-compatibility-2027/
https://www.youtube.com/@K3JSJ
Jason Johnson
I wasn’t previously aware of K3JSJ’s Ham Radio Community YouTube channel and blog, but I’m now subscribed to both. Both are refreshingly free of spin and clickbait - just solid content and analysis.
re: xara discontinued effective immediately
Me on the Zero Retries email list:
ALL the FCC rules say about a data mode that’s not specifically named in Part 97 (such as RTTY) is:
Documented publicly (or publicly documented).
That’s it.
VARA’s author has posted documentation for VARA that is publicly available.
Thus VARA’s author has met the letter of the FCC regulations (for a data mode that’s not named in Part 97).
Everything else that we hams load onto any modulation that we happen to use on Amateur Radio - that we need to be able to replicate it, that we need to be able to understand its inner operations, that we need to be able to interoperate with it… that’s all in our collective imaginations or preferences or mores.
…
VARA has become popular because it works and it’s affordable to use (even free if you’re willing to operate on the basic tier), and it’s understandable.
It answered a need. HF data communications on Amateur Radio sucked for reasonably fast, reasonably reliable data transfers, at a reasonable price. Pactor 4 (modems) work well, but are expensive and thus relatively rare on Amateur Radio. Lower tiers of Pactor worked, and were free or bundled into various devices, but still weren’t that great. RTTY sucked. Packet Radio (300 bps) sucked.
This issue was foreseen by the Winlink folks, and they labored mightily to create something that didn’t suck - ARDOP - https://winlink.org/content/ardop_overview. Unfortunately, for whatever reason, it didn’t progress very well… and VARA came along about the same time and VARA HF didn’t suck - it worked pretty well.
…
Fast forward to now. We have a number of choices for HF data communications other than VARA / xara as I discuss on my updated page - Zero Retries Guide to Amateur Radio HF Data Communications - https://www.zeroretries.org/p/hf-data.
…
Whatever WE think about the changes in VARA, they’re within the rights of the author.
Whatever WE think about x0rro “ceasing” xara, that’s within the rights of the original author.
What’s different about xara vs VARA, xara got forked and I’m sure that there will be other versions of xara (yaxara? zara? altxara?).
Among other opinions that I will opining in Zero Retries, I suggest that the Winlink Foundation, who is the primary distribution point of VARA software, once they are fully aware of this “poison pill” in the newest version of VARA, and verify it with VARA’s author, and they continue to push out that version as recommended for Winlink, then they’re complicit.
Also since I enjoy a bit of “armchair lawyering” as much as every other ham, here’s mine. If there was legal recourse from VARA’s author that would have been effective, that probably would have happened. But it (apparently) didn’t. Thus VARA’s author decided to “poison pill” a VARA update and (apparently) hope it would slip through unnoticed, for months, then boom.
In the meantime, if you don’t want to play this game with VARA on your system, either don’t update, or reinstall VARA using the previous version, which is available on the Internet Archive’s Wayback Machine - https://web.archive.org/web/20260722032108/https://downloads.winlink.org/VARA%20Products/. And if you’re grateful for this option… just for situations like this… then I recommend setting up a recurring donation to the Internet Archive, as I have done.
Internet Archive is an absolute underserved gift to every one of us that use the Internet regularly.
Video - VARA Breaks 2027 - Part 1
The fallout from the VARA vs XARA modem saga continues. The VARA developer has pushed an update that will break compatibility with current VARA HF and FM modems on January 1st, 2027!
Video - VARA Breaks 2027 - Part 2
The new VARA update breaks compatibility with previous versions. In this video Jason (K3JSJ) demonstrates what happens if one station has upgraded and another has not.
Video - Why VARA Won’t Talk to VARA Anymore
A new VARA modem release is out, and it is not backwards compatible with older versions. For Amateur Radio Emergency Service (ARES) and EmComm groups that rely on Winlink and VARA, a version mismatch can stop stations from connecting at the worst possible time.
If your ARES or RACES group, served agency, or local Winlink gateway hasn’t coordinated an upgrade plan, some stations will update and others won’t. Nobody finds out until a real activation or drill. The fix isn’t hard, but it does take planning: check which version each station is running, coordinate with your gateway sysops, keep a copy of the installer that works for you, and test before you need it.
Despite the clickbait on this opening screen, KM4ACK makes some substantive points about the coming disruption that will be inevitable with the VARA 2027-01-01 poison pill update.
Video - Will VARA 4.9.1 Break Compatibility on January 1, 2027?
In this video, I test VARA HF 4.9.1 to demonstrate how the January 1, 2027 protocol changes break backward compatibility with older versions of VARA and the open-source Xara modem, and discuss the potential impact on Winlink RMS gateways, bulletin board systems, and emergency communications.
Apologies…
I know I’ve dropped some balls in this reference article, but it’s really hard to keep track of so many moving parts of this story. When I rediscover them, or folks remind me, or point out other info that’s relevant and reasonably authoritative, I’ll do a followup article in the next issue of Zero Retries.
ZR > BEACON
By Steve Stroh N8GNJ
Short mentions of Zero Retries Interesting items.
Zero Retries Guide to Amateur Radio HF Data Communications Updated
I recently updated this document, and it’s already out of date from some of the discoveries gleaned from researching the two big articles in this issue.
Aether HF: open-source, AI-coded HF modem with a VARA-compatible host interface
Email from Facundo Fernández KK4ODA:
Your xara coverage in ZR 0267 and 0268 finally prompted me to write. I have been building a project in the same space with a different approach, and I think it would interest Zero Retries readers.
Aether HF is an open-source HF data modem for ARQ links, dual-licensed MIT or Apache-2.0:
https://github.com/KK4ODA/aether-hf
It does the same job as VARA HF: reliable connections for Winlink Express, Pat, VarAC and similar programs over noisy, fading HF channels.
Aether has nothing to do with VARA’s internals. It does not reverse engineer VARA, and its frames do not interoperate with VARA over the air. Compatibility is at the host interface instead: the daemon implements VARA’s published TCP command set, so Winlink Express and Pat connect without modification.
The waveform is designed from public standards and open literature. It runs at 2300 Hz or 500 Hz bandwidth and adjusts its speed through a ladder of modes. At the bottom are FSK tone frames for very weak signals. Above them is OFDM with 3GPP LDPC forward error correction, from BPSK rate 1/5 up to 64-QAM rate 5/6 (20 steps at 2300 Hz, 15 at 500 Hz). The ARQ is selective-repeat with HARQ soft combining. In simulation, the most robust mode stays usable down to -19 dB SNR in 3 kHz on AWGN (at 36 bit/s), and the slowest OFDM mode down to about -5 dB. On-air tests with other stations over the last couple of months are now checking those numbers against real paths. The entire air interface is publicly documented, so anyone can write an interoperable implementation.
Bench testing took up much of the time. Every performance figure in the repo comes from a committed benchmark curve. The curves are generated against a channel simulator calibrated to ITU-R F.1487, with SNR referenced to a 3 kHz noise bandwidth. Minimum usable SNR is defined as a 10 percent frame error rate under random carrier-frequency and sample-rate offsets. Continuous integration on Windows and Ubuntu regenerates every cross-validation vector on each commit and fails on any drift. Golden vectors require bit-exact transmit output, and a benchmark gate blocks any release that makes the curves worse. Full sessions also run over real 48 kHz audio: two daemons joined by a simulated channel carried Winlink Express and Pat peer-to-peer sessions, and the attachments arrived byte-identical.
It is multi-platform. On Windows, an installer includes a desktop app and a setup wizard that finds the sound card, tests keying, and sets the transmit level. On Linux there are packages and a headless aetherd daemon for Raspberry Pi gateways, with ARM64 builds. There is also an unsigned macOS build for Apple Silicon that hasn’t been tried with a radio yet, as I do not own any Mac hardware.
What may interest Zero Retries most is how it was built. I wrote the code with Claude Code, an AI coding agent, while I directed the architecture and made every engineering decision as the licensed operator. Even so, it has taken months of sustained work. Six development phases are complete, from the core modem through link robustness, application integration, the desktop app, and release infrastructure.
The current build is 0.2.0-beta.137, and we’re currently in field validation. So far we have tested:
peer-to-peer sessions with the app, which has a built-in keyboard-to-keyboard mode for standalone operation
Winlink Express in a simulated “VARA HF-like” exchange
RMS Trimode as a gateway
some VarACFor US operators, it can also check each transmission against the FCC Part 97 rules before it keys the radio. It is not finished yet, but I thought you might be interested in the project. I would welcome testers and any feedback.
I was curious about that last paragraph.
I’m curious about the details of:
For US operators, it can also check each transmission against the FCC Part 97 rules before it keys the radio.
What exactly are you checking? Band segments where data is allowed? Bands where a particular license class is allowed (Technician = few HF bands)?
KK4ODA replied:
Yes to both, and a bit more. Before every transmission, Aether checks, based on your type of license and if you are present at the radio or not,
That the whole signal, using its measured occupied bandwidth rather than just the dial frequency, fits inside a data segment (§97.305(c)).
That the segment is within your license class’s privileges (§97.301). A Technician, for example, gets no HF data except 28.000–28.300 MHz.
That the signal is under the 2.8 kHz data limit.
That an unattended (automatic) station stays inside the §97.221(b) sub-bands.
It reads the dial from the radio over CAT before each transmission. If a check fails, it doesn’t key the radio, and it tells you why. It also sends a Morse ID at the end of each session for US callsigns. The ARRL band plan only triggers warnings. Off course, these checks can be disabled if you check the frequency yourself or if you are not based in the US.
It’s just a safeguard against mistakes, as the rules are a bit complex. At the end of the day the control operator is still responsible.
Details here: https://github.com/KK4ODA/aether-hf/blob/master/docs/user/fcc-regulatory-controls.md
I’m enthusiastic about AetherHF. It seems like a solid project with some good background about a new approach to HF data communications. My apologies to KK4ODA for not digging into it as much as I usually do with such a cool new development… but… xara…
One of my features for my fantasy HF radio is a simple setting:
Country of your license? US
License class? General
Country where the transmitter is located? US
Location in US (Zip Code)? 98226
Why should I have to mentally keep track of the regulatory administrivia? My fantasy radio will have more than enough compute power to manage that administrivia for me.
With that info and the US Part 97 regulations recently updated, the radio only displays the sections of the HF bands where my General license allows me to operate given that I’m in the US within ZIP Code 98226.
If I say the transmitter is in a different country, it adjusts the display.
If I’m about to do something wrong, such as (real scenarios):
Transmitting at too high a power setting in, for example, the 70cm band near a USAF PAVE PAWS RADAR,
Trying to transmit data in a section of a band reserved for CW only,
Transmitting in 420-430 MHz North of Line A,
Transmitting at too high a power in a band segment reserved for low power operation,
… the radio displays a popup warning.
Sounds like KK4ODA and I are of a similar mind about automating regulatory administrivia. Cool!
Please direct comments / feedback about ZR > BEACON to the Zero Retries email list with the hashtag #ZR0269. Paid subscribers can comment directly on the web version of this issue.
Request To Send
By Steve Stroh N8GNJ
Editorial, Commentary, and Occasional Digressions
Gratified For “Anticipation” Messages
I was told a number of times this week:
I’m looking forward to this issue to learn about the “VARA vs xara” story.
That’s humbling. Thanks folks!
HAL, Summarize Zero Retries 0269
Seriously… how much longer do we have to wait for a synthesized Douglas Rain voice for our personal AI?
As I’m in the thick of writing about xara in this issue, going through all the details (that I would like to know about the situation), I’m imagining how many folks are going to look at it, decide it’s TL;DR, and ask their favorite AI to summarize it into a paragraph.
If it’s tedious to digest something like this in text… imagine how tedious it is to be thinking it through in advance in order to explain it in text. 🤨
But declaring TL;DR on this issue is fair… just funny to me.
(Later…) This issue will be even funnier to listen to with an AI narrator. Let me know how that goes.
Apologies for a Shortened ZR > BEACON in This Issue
The two stories about VARA vs xara were real kidney stones of articles to get done despite laboring for most of this week on them, and supporting research and correspondence. I’ll get caught up on many cool new developments in next issue’s ZR > BEACON.
Cool New Feature - AI Summary of YouTube Videos!
Speaking of AI summaries…
On my Apple TV YouTube app, I discovered the little ♦️14 where you can ask a question about the content, and there’s usually a “Summarize this video”. Yay! There are some YouTube creators that have good content, but they don’t provide any description or chapters - just a catchy title trying to draw people in to watch the whole video to get to the part about the clickbait in the title.
I’ve tried skipping around, but you spend more time trying to hit the high points (if they didn’t chapterize) than you do just listening through it, perhaps at 2x speed.
But now… there’s a weapon against that, and I’ve begun using it - I really love it. We’ll probably lose a lot of YouTube creators because of that new feature, but oh well.
On my Mac, to get this capability while watching YouTube in a browser, I had to go to youtube.com/new and enable Premium experiments.
Yes, of course I figured out how to do that on my Mac by asking Claude.ai, my paid AI of the moment.
Weekends Are For Amateur Radio!
Tina’s (too) long-deferred shiny new Apple MacBook Neo for her recent birthday (shhh…) awaits us on Saturday in Lynwood, about an hour South of Bellingham.
We’re going to be investing in some major new Apple tech in the next six months. The AI’s are finally getting seriously good and useful. I’m almost done with the Zero Retries Indexes (only 2023 is incomplete) and as I do them, I create a clean PDF through a new process and then I can cache them on my MacBook Air(s) and run onboard AI queries against them. Gemini Notebook (formerly Notebook LM) has been a significant disappointment and I’ll discontinue it after I get everything back onboard the laptop / iCloud.
But there is this one eerily good feature of Gemini Notebook. In my research I saw this mention:
The “Audio Overview” feature, which turns your sources into a podcast-style conversation between two AI hosts, is the part that really took off.
A friend turned that feature loose on an issue of Zero Retries, and like I said, it was “eerily” good. It was incomplete in places… but pretty Interesting bordering on good. That was months ago and I’m sure it’s even better by now.
…
Have a great weekend, all of you co-conspirators in Zero Retries Interesting Amateur Radio activities!
Please direct comments / feedback about Request To Send to the Zero Retries email list with the hashtag #ZR0269. Paid subscribers can comment directly on the web version of this issue.
73,
Steve N8GNJ
Closing Thanks
My ongoing Thanks to:
Tina Stroh KD7WSF for, well, everything!
Jack Stroh, Late Night Assistant Editor Emeritus
Fiona and Shreky Stroh, Late Night Assistant Editors In Training
Founding Members Who Generously Support Zero Retries:
Founding Member 0000 - Steven Davidson K3FZT (Renewed 2026, 4th year!)
Founding Member 0001 - Randy Smith WU2S (Renewed 2026, 4th year!)
Founding Member 0002 - Chris Osburn KD7DVD (Renewed 2026, 4th year!)
Founding Member 0003 - Don Rotolo N2IRZ (Renewed 2026, 4th year!)
Founding Member 0004 - Bill Arcand W1WRA (Renewed 2026, 4th year!)
Founding Member 0005 - Ben Kuhn KU0HN (Renewed 2026, 4th year!)
Founding Member 0006 - Todd Willey KQ4FID (Renewed 2026, 4th year!)
Founding Member 0007 - Merik Karman VK1DF / VK2MKZ (Renewed 2026, 4th year!)
Founding Member 0008 - Prefers To Remain Anonymous 08 (Renewed 2026, 4th year!)
Founding Member 0009 - Prefers To Remain Anonymous 19 (Renewed 2025, 2nd year!)
Founding Member 0010 - Merik Karman VK1DF / VK2MKZ (Renewed 2026, 4th year!)
Founding Member 0011 - Rick Prelinger W6XBE (Renewed 2026, 3rd year!)
Founding Member 0012 - Ryan Tolboom N2BP (Renewed 2026, 3rd year!)
Founding Member 0013 - Newton White N4EWT (Renewed 2026, 2nd year!)
Founding Member 0014 - Joe Hamelin W7COM (Renewed 2026, 2nd year!)
Founding Member 0015 - Rich Stocking N7OP (Renewed 2026, 2nd year!)
Founding Member 0016 - Chuck Hast KP4DJT (Renewed 2026, 2nd year!)
Founding Member 0017 - Phil Karn KA9Q (Renewed 2026, 2nd year!)
Founding Member 0018 - Prefers To Remain Anonymous 47 (Renewed 2026, 2nd year!)
Founding Member 0019 - Prefers To Remain Anonymous 0108 (New 2025)
Founding Member 0020 - Prefers To Remain Anonymous 110 (New 2025)
Founding Member 0021 - Prefers To Remain Anonymous 111 (New 2025)
Founding Member 0022 - Prefers To Remain Anonymous 112 (New 2025)
Founding Member 0023 - Prefers To Remain Anonymous 116 (New 2026)
Founding Member 0024 - Rob Bowser (SPOOLTENNA) (New 2026)
Founding Member 0025 - Dave Stewart K7XST (New 2026)
Founding Member 0026 - Prefers To Remain Anonymous 32 (New 2026)
Founding Member 0027 - Mitch Hamm N8XS (New 2026)
Numerous Annual and Monthly subscribers who also generously support Zero Retries financially!
You thousands of readers of Zero Retries without which there would be little point in publishing this newsletter.
The Usual Administrivia
Zero Retries About - www.zeroretries.org/about
Zero Retries Digital Conference - www.zeroretries.org/p/conference
Zero Retries (Substack Blanket) Privacy Policy - substack.com/privacy
Zero Retries Reprint / Reuse Policy - www.zeroretries.org/p/reprint-reuse
Fair Use - All excerpts from other authors or organizations, including images, are intended to be fair use and are fully attributed generally by author and link (URL).
Paid Promotional Content - Unless otherwise noted in the article or item, advertisement, or sponsorship notice, Zero Retries does not include paid promotional content. Exceptions:
Advertisements in Zero Retries,
Sponsorships in Zero Retries,
Zero Retries products,
Zero Retries events
Features and content exclusive to paid subscribers.
Zero Retries 2026 Index - www.zeroretries.org/p/index-2026
Zero Retries Archive - archive.org/details/zeroretries?sort=-date
⬅️⬅️⬅️ Previous Issue of Zero Retries | Next Issue of Zero Retries ➡️➡️➡️
Zero Retries 0269 was published on 2026-11-13. This issue was 11594 words. Ouch.
Footnotes For This Issue
To see the relevant sentence for the footnote, just click the footnote number.
The creator of xara, x0rro (note the second character of the creator’s name is a zero, not uppercase O) is a pedant about rarely using uppercase characters. Thus I’ll honor x0rro’s preference and in this article, and all my mentions, it’s xara, not Xara, or XARA.
Raspberry Pi OS isn’t normally considered a primary Operating System, but it’s widely used given the penetration of Raspberry Pi units in use in Amateur Radio.
In discussing a DMCA Takedown Notice “served” against GitHub, I know nothing substantive about the DMCA Takedown Notice process, or how it works internally at GitHub.
Now that ?ara exists, there are very few realistic situations for attempting to run VARA on top of WINE on top of Linux as had been the workaround for running VARA on Linux.
From VardeFM: What is publicly documented is the interface VARA offers to applications: a set of TCP commands on port 8300 and a data stream on port 8301. VardeFM offers the same interface, so programs that talk to VARA FM can talk to VardeFM instead without any changes. The user guide covers setting it up with Pat, Winlink Express and HamBBS.
From Mercury GitHub: VARA-style TCP TNC interface on two sockets (control on the base port, data on base+1), speaking MYCALL, LISTEN, CONNECT, BUFFER, SN, BITRATE, TUNE (a 1 kHz ATU tuning carrier with a hard 60 s unkey timer) and MONITOR (a passive VARA-style monitor that decodes every mode). Existing VARA-aware software can generally talk to Mercury unchanged.
Yes, VarAC is Windows-only… but it’s a really good app, and it’s available free.
SuperRMS is purely an imaginary descriptor (I think…)
Yes, W7NWP, you called this one way, way back. Thanks for educating me on it.
Amateur Radio Safety Foundation is the sponsoring organization of Winlink
There’s also the Intellectual Property issues that KM6LYW won’t venture into.
Finally the terminology of “flat audio” is breaking through!
Well, Raspberry Pi Desktop Linux. I might as well keep it simple for this Linux non-native.
Closest emoji I could find to Gemini’s symbol.