2026-05-08 - Rhizomatica Releases Mercury, a Fully Open-source Modem for Digital on HF, Networking, Networking, Networking, APRS Messaging 36 Miles with Two HTs, tncd: Keeping Packet Radio on Linux
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 fifth year of publication, with 3500+ subscribers.
Substack says this issue is too big for email clients (especially mobile devices). Thus, it might be easier to read in a web browser - www.zeroretries.org/p/zero-retries-0250.
It’s easy and free to subscribe for your own copy of Zero Retries every week:
My thanks to Victoria Yanovich K8VSY for three years of being a Paid Subscriber to Zero Retries as of this past week!
Financial support from Zero Retries readers is a significant vote of support for the continued publication of Zero Retries.
No Zero Retries Next Week
Zero Retries will not be published next Friday 2026-05-15.
The next issue of Zero Retries - 0251 will publish on 2026-05-22 (or shortly after). I will be attending Hamvention 2026 on 2026-05-15 thru 17, and I know from previous experience that the Hamvention experience is “full saturation” and there is no “spare time” to sit down and write Zero Retries. Not to mention that this year, I will be staffing the first ever Zero Retries (shared with DLARC) booth at Hamvention, and I expect that will keep me fully occupied for the length of the entire event. I will also be doing some personal travel the following week.
May 2026 — Rhizomatica is pleased to officially launch Mercury, a completely open-source Digital Radio OFDM protocol for HF broadcast and peer-to-peer ARQ connections with compatible TCP interfaces, built for reliable store-and-forward email and file transfer over HF radio links. Mercury is the newest element of the HERMES software suite, actively developed by Rhizomatica since 2017, with generous funding from ARDC and others.
Mercury is written in C, released under a GPL-3.0 license, and features a modular architecture with per-direction mode selection, hybrid SNR + delivery feedback-based gear-shifting, split control/data channel design, and uses field-proven FreeDV digital data modes, with each mode kept resident in a pool, eliminating codec re-initialization overhead. Pre-built binaries are available for Windows and Debian operating systems and Mercury is suitable for use with most HF transceivers and completely compliant for amateur use.
In early tests, compared to the commercial alternative, Mercury has performed well and is nearly at parity in optimal SNR conditions and outperforms the alternative in poor SNR conditions.
“Not only has Rhizomatica developed a fully open-source software modem, they have done so to empower communities in need of their own communication infrastructure. We are proud to have supported Rhizomatica in this work, and very excited to see it now available to the amateur community and others around the world using HF for critical communication.” — Rosy Schechter (KJ7RYV), Executive Director of ARDC.
“I am very pleased to see Rhizomatica using the FreeDV data modes combined with their own custom ARQ protocol to send data over low SNR HF channels. It is great to see Rhizomatica embracing those waveforms, and spreading the use of open source in HF Data.“ — David Rowe (VK5DGR), inventor of Codec 2 and FreeDV.
More information can be found from the following sources, or by contacting Rhizomatica directly using the Contact information provided below.
Dr. Rafael Diniz (PU2UIT) - HERMES Lead Developer & Project Coordinator. [rafael@rhizomatica.org]
ABOUT
Rhizomatica Communications is a US-based non-profit with the mission to support communities to build and maintain self-governed and owned communication and energy infrastructure. [https://www.rhizomatica.org]
HERMES is an open-source software stack created by Rhizomatica to make it easier to use HF/shortwave radio for digital communications. Since 2017, together with social organizations and remote communities around the world, Rhizomatica has been designing, building and testing HERMES to create reliable, secure, long-range, autonomous voice and digital communications. [https://hermes.radio/]
Editor’s Postscript
For good reasons, Rhizomatica’s press release references “the commercial alternative” as a point of comparison. I’m under no such constraints. “The commercial alternative” is, of course, VARA HF. But it could also apply to the similar capabilities of PACTOR 4 from SCS.
I first saw Mercury demonstrated at Hamvention 2025, and it was impressive then.
In my opinion, this development is a very big deal in the evolution of data communications in Amateur Radio. Mercury now offers a well-engineered data communications system for use on the Amateur Radio HF bands. HF is a “hostile environment” for data communications - it’s noisy (with highly variable types of noise), with fading, distortion, and significant interference (it’s a shared resource, worldwide - every frequency is already in use, somewhere on the planet).
But the real significance of Mercury is that it’s an open source project, and has already been ported to Linux.
Prior to Mercury, open source data communications systems for HF were generally lower performance, and not very robust, such as 300 bps Audio Frequency Shift Keying (AFSK) packet radio.
I applaud the Mercury developers for their savvy choice to implement the Orthogonal Frequency Division Multiplexing (OFDM) subsystem that was developed and proven out by FreeDV. Being able to use the FreeDV OFDM subsystem is one of the many benefits of open source development.
Mercury’s development was made possible by grants from ARDC (2021, 2023, 2025) which enabled the developers to apply significant time and resources to Mercury. The success of Mercury wonderfully illustrates ARDC’s fundamental role in Amateur Radio of the 2020s and beyond - providing financial support that enables the creation of new technologies in Amateur Radio. It’s notable that the OFDM subsystem used in Mercury, originally developed by FreeDV, was also the result of ARDC grants.
I hope… expect… that Mercury will eventually become the primary data communications mode in use on Amateur Radio HF. For a while, FreeDATA seemed promising as an offshoot of FreeDV (it repurposed FreeDV’s OFDM subsystem to transmit and receive data rather than digital voice), but there doesn’t seem to be much development activity on FreeDATA of late. There has also been some continuing development on Amateur Radio Digital Open Protocol (ARDOP).
I also hope that Mercury will eventually become embedded into Amateur Radio HF radios as a mode selection in the same way that RTTY is a mode selection. Such integration is beginning to happen now with FreeDV in with FlexRadio’s current generation products. This seems a reasonable extrapolation - Mercury offers fast, robust data transfers, it’s open source (and thus, free to implement in a wide variety of systems, projects, and products), and the only significant competition on Amateur Radio HF is VARA HF and PACTOR 4; both are commercial, proprietary products.
Like VARA HF and PACTOR 4, Mercury is just the “bit transport” portion of a data communications system, much like Ethernet is just “bit transport”. It’s applications that make such “bit transports” useful. To enable applications to easily use Mercury, I’ve seen references on email lists that Mercury’s developers have provided the same software and network interfaces as VARA HF, thus hopefully enabling Mercury to be used with the same applications that make use of VARA HF.
One of my hoped-for use cases for Mercury is that we will be able to use the very popular and very capable VarAC application with Mercury to do personal email, bulletins, file transfers, text chats, and much more over HF.
Credit Due to EA5HVK for VARA HF and VARA FM
While this story is about Mercury, I think it’s useful and relevant to reference VARA HF and VARA FM for context for why Mercury is such a big deal for Amateur Radio.
Prior to the development of Mercury, and at least part of the inspiration for Mercury, Jose Alberto Nieto Ros EA5HVK deserves credit and kudos as the developer of VARA HF and VARA FM. EA5HVK was the first (that I’m aware of) to provide a modern HF data communications system for Amateur Radio - adaptable, reliable, and fast, implemented in software running on an affordable (Windows, in this case) computer1. It’s especially notable that EA5HVK pioneered the use of “Audio band OFDM” making VARA HF and VARA FM incredibly robust. EA5HVK has chosen to only offer VARA HF and VARA FM as a commercial and proprietary product running on Windows2. VARA HF and VARA FM have become the basis of many successful Amateur Radio systems, such as Winlink, VarAC for personal (and some Emergency Communications), The Packet Radio RF Forwarding Network (TPRFN), and VARAtrack (APRS over HF using VARA HF).
We’ve been doing data networking on Amateur Radio spectrum for more than four decades now. We’ve actually gotten pretty good at it. But we haven’t been very consistent about it, being interoperable, or publicizing what we’re doing or how to get in on the fun.
Not consistent about it as in there are islands of good Amateur Radio network connectivity, amidst an ocean of lack of good Amateur Radio network options.
We know how to create good connectivity. We do a great job of providing ubiquitous access to Amateur Radio voice repeaters. But we don’t have the equivalent for of ubiquitous Amateur Radio networking.
I posit that we should have ubiquitous access to Amateur Radio networking at least on par as coverage of voice repeaters.
Many Amateur Radio Network Technologies
We have no shortage of Amateur Radio network technologies to choose from. And choose, we have (from many different network technologies):
AREDN in Northern California has a great network operating on 5 GHz. It’s pretty much the ultimate of ideal Amateur Radio networking connectivity - it’s pretty much equivalent to Internet connectivity - 10+ Mbps, any app that works via TCP/IP, etc.
I predict there will soon be “AREDN-900” advocates (AREDN operating on the 902-928 MHz band)…
There are Amateur Radio Packet Radio advocates, both 1200 bps and 9600 bps…
There are Amateur Radio Packet Radio advocates, both 1200 bps and 9600 bps that use FX.25 or IL2P Forward Error Correction (FEC)…
There are APRS / APRS messaging advocates…
There are Winlink advocates…
There are Eastnet advocates…
There are TCP/IP over Packet Radio advocates…
There are (at least a few) IPv6 over Amateur Radio advocates…
There are Meshtastic / MeshCore / MeshCom advocates…
There are LoRa advocates (using LoRa other than MeshX) advocates…
There are MMDVM Radio Hotspot advocates…
There are Amateur Radio Over Internet advocates…
There are M17 Data advocates…
There are VarAC-as-a-network advocates…
There are “cheap Standby tier” Starlink experimenter advocates…
There are Net/ROM / TheNET / Kantronics K-Node advocates…
There are TARPN advocates…
There are fsq (and other fldigi modes) on VHF / UHF FM advocates…
There are QO-100 (generically Amateur Radio GEO satellites) advocates…
There are HamWAN advocates…
There are “pure Part 15” (unlicensed spectrum) microwave network advocates…
There probably will be IP400 advocates…
There probably will be Mesh Operations Protocol (MOP) advocates…
There were Broadband Hamnet / HSMM-Mesh advocates…
There were WA4DSY 56k RF Modem advocates…
There were ROSE network advocates…
There were TEXNET network advocates…
There were PacketCluster network advocates…
You get the point.
All of those different types of networks have (or had) their valid points, advantages, and existing communities.
But in the big picture, Amateur Radio networking is too fragmented.
What makes the Internet work is the consistency of connectivity. Recall that prior to the creation of the Internet (and the ARPANET before that) we had data networking connectivity - but islands of it. We had IBM SNA, DECNET, ARCNET, NETBIOS, and gazillions of others. But they could not interoperate except very painfully, very expensively, and very limited and inflexible. If one detail about a data networking protocol changed, all the built-for-purpose bridges between, say, DECNET and SNA broke until the change was added into the bridges.
Amateur Radio is in roughly in the same situation now. We have lots of successful implementations of data networking connectivity over Amateur Radio. There are good reasons for this situation. Amateur Radio is under no economic or efficiency imperative to consolidate its disparate networks to be more interoperable or efficient. It’s also the case that Amateur Radio Operators (and groups) are encouraged to experiment. And sometimes, an unusual network is just fun to play with.
But none of the current Amateur Radio networks are big enough, successful enough to be considered the data networking solution for Amateur Radio. Thus, Amateur Radio can’t really cite a “success story” for Amateur Radio networking.
Straw Figure Test - What Network System Would You Recommend?
Not convinced? Here’s a simple straw figure test:
Imagine a bright first year high school student - let’s call her Shelly Jones. Shelly is a techie, and curious about radio, and hears about Amateur Radio. She likes the challenge of getting her license and gets her Technician license. She wants to figure out some way to create an Amateur Radio data network in her small town so she can chat with, and experiment with her fellow students via Amateur Radio.
What Amateur Radio data networking system would you recommend to Shelly and her friends?
The easiest system to recommend is Meshtastic / MeshCore / MeshCom. There’s ample enthusiasm, peer support, a wide variety of hardware, and there are options for Amateur Radio 420-450 MHz band and the 902-928 MHz band.
But that’s limited to what can be done with LoRa, and generally low power. MeshCore and MeshCom are reportedly more stable and scalable. But MeshX is limited in what it can do because of the low bandwidth.
AREDN is what first comes to my mind, but it has the dual handicap of requiring at least one high profile node, and the most usable AREDN radio hardware operates at 5 GHz which requires an optical clear line of sight. AREDN-9004 is promising, but there are only a few such units that AREDN has been ported to.
For those that cannot access a node at 5 GHz, there is the option of an Internet tunnel, and that’s been made more feasible with 44Net Connect.
There are tradeoffs for all of the systems listed above. And, there’s the community / local support factor. There’s a strong disincentive for Shelly and her friends to create a new AREDN-900 network if there is an existing VARA FM + VarAC network already in existence in their town.
So… what to do… and again, what to recommend to Shelly and her friends? And in the larger perspective, what can those advocates for Amateur Radio - to prospective Amateur Radio Operators, and regulators, and the general public, point to as a success story for Amateur Radio Networking?
I don’t have the answer for those questions. Perhaps for now, AREDN is a good enough success story, especially if AREDN-900 becomes more widely used. It’s very Internet-like, can run an impressive range of apps and use cases.
AREDN Equivalent for VHF / UHF
But in my opinion, we need an equivalent to AREDN that can operate on VHF / UHF bands. Blending some of the elements from above:
Use our “awesome transmit power” levels, like 25 / 50 watt transmit power
Use our ability to operate on multiple bands simultaneously, such as 50-54 MHz, 144-148 MHz, 222-225 MHz, and 440-450 MHz.
Mesh networking, especially cross-band, such as MOP, IP400, and Net/ROM.
Use repeater technology and coverage, such as SuperPeater.
Achieve reasonable speeds for narrow channels such as VARA FM, up to 100 kbps such as New Packet Radio.
Use TCP/IP (IPv4 initially, and eventually IPv6) to interoperate with AREDN.
Universally implement AX.25 Version 2.2.
In suggesting all of the above, it seems to me that Amateur Radio needs at least one coherent, consistent, interoperable “network strategy” in the mid-2020s and beyond.
I’m going to call it ARDNET - Amateur Radio Data Network.
This is a new official website for VARA, including downloads of the latest versions of EA5HVK VARA-related software, and a direct link to purchase a VARA license. Official because of the copyright notice:
This is a welcome development as this website is streamlined and modern-looking. In my opinion it’s’ much easier to navigate to quickly find what you’re looking for. It’s welcome that this website doesn’t spam you with irrelevant advertisements, and the Downloads section redirects to winlink.org rather than the (slightly spammy) mega.nz website.
Another promising feature of the new website is that a Blog tab is present (currently linking to posts on the previous website), perhaps hinting that EA5HVK will use that for discussing VARA “straight from the source”.
Documentation doesn’t seem to be available on this new website at the moment.
Lastly, it was interesting to see this mention of the non Amateur Radio users of VARA:
In use across many services as Department of Homeland Security SHARES, USCG Auxiliary, TNSG (Tennessee State Guard) , Canadian CFARS, FNRASEC, OEM (Oregon Department of Emergency Management) Austrian Armed Forces (CIS & Cyber Security Centre) and the amateur radio Service.
Lastly, the maximum speeds on this new website for VARA HF and VARA FM WIDE are different than what I’ve seen stated in VARA documentation. (VARA FM NARROW is the same.)
VARA HF’s maximum speed, on this new website, is stated as 8489 bps. The speed tier chart in VARA 4.7 quick guide.pdf states the max speed for VARA HF (2300, Standard) as 7050 bps.
VARA FM WIDE’s maximum speed, on this new website, is stated as: VARA WIDE (Max 19200 bps). The speed tier chart in VARA FM 4.0 Features.pdf states the max speed for VARA FM WIDE as 25210 bps.
SafecomLink is the only platform that fully meets all hamradio operational and emergency communication (EmComm) needs for HF/V/U base data management. Its comprehensive features deliver unmatched versatility, reliability, and performance for hamradio operators worldwide.
SafecomLink for SCS Pactor Modems
Rediscover your Pactor modem and turn your past investment into a powerful, modern communication tool with SafecomLink.
Supports both legacy and modern SCS Pactor modems:
This is an interesting development. SafecomLink is a rebranded version of VarAC. Apparently the VarAC developers decided to make SafecomLink available to Amateur Radio Operators that want to use a Pactor modem rather than VARA HF with VarAC. Pactor 4’s maximum data rate is 10.5 kbps on HF (and 9600 bps on VHF / UHF). One big difference between VarAC and SafecomLink is that VarAC is free for use by Amateur Radio Operators and CB operators. SafecomLink is requires an annual paid subscription, which is understandable given it’s intended for commercial / public safety organizations.
Apparently this is the week for VARA related website updates.
This is the source code of the MMDVM firmware that supports the D-Star, DMR, System Fusion, P25, NXDN, POCSAG, and FM modes.
It is currently used with the SXceiver Pi hat or similar running on a Raspberry Pi. All of the development work is done on a Pi 4 as there are reports of incompatibilities with the Pi 5. It uses the SoapySDR interface that can be found at https://sxceiver.com/
Two subtle things about this development. First, “-IQ” designates that this is a new version of MMDVM that uses hardware that operates using I+Q interfaces. This is significantly more capable than “classic” MMDVM.
Second, for the first time, Frequency Modulation… yes, classic FM, is now supported in MMDVM (using the more capable hardware being developed in conjunction with MMDVM-IQ).
The most significant aspect of this work is that with the new hardware, and software, MMDVM will be able to do on-device, realtime transcoding between digital voice modes, such as D-Star in, DMR out and vice versa.
Some of this will be on display (though working demonstrations may not be displayed), but much information will be available at the MMDVM booth (1609) at Hamvention 2026.
My thanks to Jim Mclaughlin KI6ZUM for bringing this development to my attention for inclusion in Zero Retries.
Island Magic Products Update
Image courtesy of Island Magic
Email update from Island Magic / Georges Auberger WH6AZ (unfortunately, no web page version):
RadioMail
I’ve been working on version 1.6, focusing on bug fixes and quality-of-life improvements. One of the bigger usability win is bulk message editing.
There’s also experimental emoji support. Winlink limits the character set to ISO-8859-1, so emojis can’t be transmitted as-is, but they will display when sending messages from RadioMail to RadioMail. Not exactly standards-compliant, but good enough to have a little fun 🤪.
The most significant addition is a built-in ARDOP modem for HF.
Supported interfaces include:
Digirig Lite
AIOC (All-In-One Cable)
ICOM IC-705 (USB audio + Bluetooth for CAT control)
If you’d like to help test you can download the Beta on TestFlight
RadioMail 2.0
The longer-term goal is still to offer a proper Winlink experience on Mac. Getting there means supporting you across all your devices, which in turn means syncing messages across applications.
The path forward I choose is as follows:
Updated UI with a first-class iPad experience (multi-column layout, keyboard support, better use of space)
iCloud sync for mailbox content
Make iPad version available on Mac
To make this happen, I ended up rewriting the app from scratch. It wasn’t the original plan, but it gives me a much cleaner foundation using modern SwiftUI.
It’s a large effort. I’m fairly far along, but there’s still a lot of surface area to cover. I got a bit distracted by other things and travels. Expect a beta sometime this summer.
VARA On-a-Stick
Some of you might remember my earlier attempts at building a portable, headless “VARA appliance.”
That effort led to varanny, a small command-line daemon that lets RadioMail orchestrate VARA on a remote machine.
That setup relied on a small 12V BeeLink computer, which was compact, but still had a fan. Also the Windows variation was finicky to say the least.
More recently, I’ve been experimenting with stick PCs which provide a much smaller form factor, are fanless and can be powered over USB-C PD.
The key breakthrough was getting everything to run on a minimal Linux distribution without a desktop. It boots quickly and runs comfortably even on a 4GB RAM device.
The experience is simple: power it on, connect from RadioMail, and you’re on the air. Hard to describe how liberating this is.
A set of scripts will install everything and provide support for:
VARA FM and VARA HF with Digirig Lite and AIOC audio interfaces
Full IC-705 support, including CAT control
Built-in WiFi access point for easy pairing in the field
Possibly the world’s smallest portable VARA FM station.
At this point, I no longer want to think about Windows or wrestle with VARA just to reach Winlink gateways. That alone makes it worthwhile.
Note that if you run into issues, you’ll need to troubleshoot on your own. I’m not planning to spend more mental cycles on that stack. And hopefully in the not too distant future, we eventually will get proper protocol documentation, which might open the door to broader interoperability.
Radio Messenger
This is something I’ve been thinking about for a long time and finally started building an app to see if that made sense.
The core idea is simple: messaging over amateur radio works, but it doesn’t feel like modern messaging.
APRS already gives us a global, resilient network. But most software treats messaging as a secondary feature behind maps and tracking.
This project flips that. Messaging is the primary experience and conversations come first.
Of course, radio has real constraints. You’re not always in range, radios are often off and APRS doesn’t store messages you miss.
The approach here is pragmatic. RF delivery is always the priority, but internet delivery can serve as a fallback. If a message doesn’t get through, it can be held briefly and delivered later via push notifications.
The goal isn’t to replace radio with the internet, just to make the experience less brittle.
The app also supports so-called AX.25 UNPROTO messaging, which was a frequent request for Packet Commander. It simply didn’t make sense to build that into a connection-oriented app.
With UNPROTO, there is no acknowledgments, no retries, just packets sent on the air. In practice, this creates a lightweight, shared-frequency chat experience. This opened the door for some early experimentation with message signing (inspired by Chattervox). No encryption, just a way to verify that a message came from who it claims to be.
The app works best with Bluetooth HTs that have built-in packet modems, like the UV-PRO or the Kenwood TH-D75 with the B.B. Link adapter.
If you have these radios and would like to provide feedback, message me and I’ll send you a TestFlight invite.
I’m looking forward to using RadioMail, especially RadioMail 2.0 that will sync on my iPhone, iPad5, and Mac(s) via iCloud sync. We Apple ecosystem users are admittedly spoiled from the overall Apple experience of our info generally staying in sync across devices without us thinking about it. It’s jarring when we don’t have that experience, and kudos to WH6AZ for bringing that experience to Amateur Radio on Apple devices.
APRS messaging as a primary function app is something that I previously discussed in Zero Retries as an unmet need in Amateur Radio. I’m glad WH6AZ, with demonstrated talent in doing IOS apps and good user interfaces, has decided to step up to that challenge with Radio Messenger. I’m looking forward to that experience also.
Open up aprs.fi and most of the traffic you’ll see is position based. I’ve spent many years playing around with that aspect of APRS but recently had an opportunity to play with the messaging side. With the rise of Meshtastic, I’ve become more curious about what APRS messaging is capable of considering availability of greater transmit power and a long established network of Igates and digipeaters. I’ve successfully received messages over RF from an internet connected source such as APRS Graffiti Wall and APRS WX Bot. What I really wanted to see was a true RF to RF message setup.
I run an igate here in Murfreesboro with both receive and transmit capability, so one side of the RF based messaging equation has already been complete for some time. It’s a modest station powered by Direwolf and a lowly Quansheng UV-K5 5 watt HT. But it’s connected to a large dual-band vertical about 20 feet off the ground which provides excellent reception and decent transmission to local digipeaters.
A few months ago I had the chance to set up a temporary APRS station in the Nashville Metro Center area. This station was very similar, a 5 watt Kenwood HT powered by Direwolf, but connected to a j-pole set up on a 4th story balcony practically with line of sight to one of the most powerful digipeaters in the area, W4CAT-1. W4CAT-1 sits at about 1,000 feet atop Music Mountain.
This is an interesting experiment with the too-often-neglected APRS Message capability that’s been a feature of APRS and APRS infrastructure practically since the creation of APRS.
It was fun to discover this article the same week as reading about Island Magic’s upcoming Radio Messenger. The two articles bookend nicely together.
Near vertical incidence skywave (NVIS) fills in the gap between local communications and DX and is one of the most under appreciated forms of HF radio.
What is NVIS?
It is probably better to start by talking about what NVIS isn’t. It’s not a specific mode. Any operator can apply the principle to voice, code, or data. You do not need specific equipment. You can use whatever HF radio you’ve already got. As for antennas, a simple wire antenna will do. There is no need for towers, beams, or specialty hardware.
NVIS is simply sending a signal deliberately intended not to “skip” great distances. To send an effective DX signal, one must transmit at low wide angle to the ionosphere. In NVIS, the signal is sent at a very sharp, acute angle, almost ninety degrees. That’s where the “near vertical” part comes from.
Think of it like throwing a ball while inside a large building. In the first attempt, you throw the ball at an angle nearly parallel to the floor, like pitching a baseball. The ball will hit the ground, then bounce off the ceiling, and travel a fairly long distance. For the second attempt, you slam the ball on the ground in front of you at nearly a ninety degree angle. The ball will bounce many times between the floor and the ceiling but not travel very far from where you threw it.
Ever since I read about the use of NVIS techniques by The Packet Radio Forwarding Network (TPRFN) for achieving reliable regional communications via HF, NVIS made complete sense to me as a “middle” between local communications using VHF / UHF and continental and intercontinental communications with typical HF antennas.
My thanks to Amateur Radio Weekly Issue 419 for bringing this development to my attention for inclusion in Zero Retries.
Let’s not kid ourselves: The Raspberry Pi is a brilliant little machine and pretty much indispensable for our hobby nowadays. But getting the hardware and software to play nice together is rarely plug-and-play. If you’ve ever spent half the night wrestling with error messages, you know exactly what I mean.
That’s why many people grab pre-built images. The catch? They are usually outdated before the download even finishes. And ready-made install scripts? One minor update to a Linux package or the operating system, and boom—the script throws errors and you’re dead in the water.
From the trenches, for the trenches, the real best practice is this: Build your system yourself and compile the software exactly for your specific needs. You’ll find plenty of practical, hands-on examples on my blog at dl1gkk.com.
After countless hours at the keyboard, today, in April 2026, I’m giving you the absolute basics to ensure your Pi actually runs smoothly in the shack.
Hardware: Which Pi should you use?
Operating System & Display Server: The right foundation
Troubleshooting: Your digital co-pilot
Backups: The safety net
On the Air: RF is a beast
Each of those five points contain additional detail of solid, well-considered recommendations. DL1GKK put a lot of thought (and evident experience) into each of them. I almost missed his graphic at the bottom of the post that distills his recommendations:
For many years, wireless communication technology has faced a trade-off between achieving long transmission ranges and supporting high data rates. Semtech’s LR2021, the first radio in the LoRa Plus™ line, incorporates 4th Generation LoRa® IP with an innovative Fast Long-Range Communication (FLRC) modulation, enabling data rates of up to 2.6 Mbps on both sub-GHz and 2.4 GHz frequency bands. This advanced modulation supports diverse applications, including reliable image transfer over extensive distances with strong penetration through materials, all while maintaining the low power requirements necessary for battery-powered devices.
The Range-Speed Trade-off in Wireless Communication
The Technology Behind FLRC
Fast Long-Range Communication (FLRC), featured in the LR2021, offers an enhanced link budget and significantly higher data throughput. By utilizing coherent Minimum-Shift Keying (MSK) modulation, FLRC achieves long-range transmission with notable spectral and energy efficiency. Unlike LoRa, FLRC does not employ spread spectrum methods; consequently, the raw bit rate is equivalent to the channel bandwidth prior to the application of Forward Error Correction (FEC). This direct mapping enables FLRC to deliver higher throughput while maintaining the extended range that long-range applications require.
Key Advantages of FLRC
High Data Throughput: Supporting data rates up to 2.6 Mbps, FLRC enables applications requiring significant volumes of data transfer, including images, audio, extensive data logging, Firmware Updates Over-The-Air (FUOTA), and Edge AI model training.
Extended Range: FLRC offers 8–10 dB improved sensitivity compared to Bluetooth Low Energy (BLE), effectively doubling operational range at comparable bit rates. While BLE typically reaches 100 meters, FLRC extends this to 200+ meters in outdoor environments. Sub-GHz operation delivers superior material penetration, ideal for deep indoor deployments.
Low Power Consumption: Optimized for battery-powered platforms necessitating prolonged runtime. Typical security camera deployments achieve 2+ years of battery life with periodic image transmission.
… enabling data rates of up to 2.6 Mbps on both sub-GHz and 2.4 GHz frequency bands.
I’ve been seeing mentions of MeshX beginning to take advantage of “new LoRa capabilities” for higher speeds, but the mentions I’ve seen only make reference to doing so on the 2.4 GHz bands. But now… this looks interesting for those speed tiers perhaps being able to be used on spectrum below 1 GHz. Yes, but… read on.
To date, using LoRa has been a tradeoff between reliability and range, at the expense of speed (bandwidth). LoRa works great for use cases such as text messaging and position / telemetry (it’s original use case). LoRa is especially useful and relevant in Amateur Radio because there are options for LoRa to operate on 433 MHz (unlicensed in Europe).
After a bit of reading, I noted:
“Sub GHz” is restricted to 868 MHz (unlicensed in Europe) or 915 MHz (unlicensed in North America). There doesn’t seem to be an option for FLRC on 433 MHz as there is with “traditional LoRa”.
FLRC has little or nothing in common with “traditional LoRa”. FLRC modulation is Minimum-Shift Keying (MSK). “Traditional LoRa” is Chirp Spread Spectrum (CSS). There’s no explanation for not using CSS for FLRC.
There’s no mention of the bandwidth used - probably buried in the application notes.
I didn’t understand why “LoRa” was even mentioned on this page until I saw this:
About Semtech LR2021
The LR2021 transceiver integrates LoRa, FLRC and other modulation protocols utilized in low-power wireless designs, offering developers exceptional versatility in communication system engineering.
Aha! This new LR2021 chipset offers a choice of modulations in the same chipset - LoRa, or FLRC, or “other modulation protocols” (not stated). But, again, only for 868 / 915 MHz or 2.4 GHz, not 433 MHz. Bummer!
Lastly, this interesting mention in this article:
FLRC Compared to Other Wireless Technologies
Data Rate: Traditional LoRa - 50 kbps
I’ve never seen LoRa described as having 50 kbps bandwidth. At most, I’ve seen ~20 kbps.
In conclusion, FLRC sounds neat, but we have a lot of other existing options for Amateur Radio data communications and networking for data commutations in 902-928 MHz and 2.4 GHz, with reasonably long range and bandwidth such as Wi-Fi HaLow / 802.11ah. While FLRC doesn’t sound like “LoRa on steroids”, it would be interesting to see how it stacks up for Amateur Radio use on the 902-928 MHz / 33cm band.
When Linux 7.1 ships, the native AX.25 kernel networking stack goes away. The AF_AX25 socket family is being removed. Tools like ldsped that depend on it will stop working. PAT will lose its AX.25 transport. Xastir will go silent. Anyone running a current distribution will eventually face this, and “don’t upgrade your kernel” is not a long-term answer.
I wrote tncd to fix this before it becomes everyone’s problem.
What it does
Most packet software speaks AGWPE — a TCP-based protocol that lets applications talk to a TNC without needing kernel socket support or direct serial access. On Windows, AGWPE itself handles everything. On Linux, the kernel’s AX.25 stack has traditionally done the heavy lifting, with tools like ldsped sitting between the application and the kernel.
KISS TNCs — everything from a classic Kantronics KPC-3 (in KISS mode) to a modern Mobilinkd or BTECH UV-Pro — are dumb modems. They encode and decode packets over the air but do not implement AX.25 Layer 2. The handshake, the sequencing, the acknowledgements have always lived somewhere else. tncd moves that somewhere else into userspace.
tncd handles the full AGWPE protocol surface — version negotiation, port enumeration, callsign registration, UI frames, raw KISS passthrough, and monitoring events — and runs a complete AX.25 v2.0 Layer 2 state machine on the KISS side: SABM/UA handshake, I-frame sequencing with a mod-8 window, RR acknowledgement, duplicate detection, T1 retransmit, flow control, and clean DISC/DM handling. Serial (including USB), TCP, and Bluetooth RFCOMM TNCs are all supported.
KU0HN also mentioned in passing two applications I wasn’t familiar with that seem worth an expanded mention:
ldsped - “expanded” to the next item.
paracon - a packet radio terminal for Linux, Mac and Windows. It is focused on simplicity and ease of use, and incorporates the core functionality that most packet users need without trying to include all of the bells and whistles that few would use.
This is the first of three semi-related stories. I’m in awe of the creativity and energy of Amateur Radio software developers such as KU0HN that work to make Amateur Radio data communications better.
As a radio-amateur, I’m mainly busy experimenting with APRS (when I’ve some time left ...).
I’m a linux-user and a registered user of UI-View. But these two do not communicate the way I’d like to.
Of course, I can use Xastir. But my linux computer was at the time, an old PII@266 MHz, running headless in a closet. Running Xastir (remote) is not what you can use ‘fast’.
The ‘workstations’ are windows PC’s or dual boot (Linux/windows) PCs.
As mentioned, I wanted to use UI-View. You may comment on my project, of course, but do not try to convince me to use any alternative. The project is just about running UI-View.
But what started as a wish to use the TNCs on my linux box from the windows computer(s) running UI-View, became a more and more mature linux daemon acting as an agwpe replacement.
Eventually I even added functions, not present in agwpe !
At this moment, a lot of client programs (windows and linux) can work without problems with ldsped. Among them are UI-View, Xastir, Outpost, Radio Mobile, Paclink, AGW*, UISS, ...
How I came to the result can be found on this site.
AGWPE is AGW Packet Engine, one of many Amateur Radio Packet Radio o applications by George Rossopoylos SV2AGW. Packet Engine has been a fixture of Amateur Radio Packet Radio for nearly four decades. As I understand it, the older version of Packet Engine (AGWPE) is freeware (for Amateur Radio) but not open source. The newer version - Packet Engine Pro is shareware.
This is the second of three semi-related stories. I’m in awe of the creativity and energy of Amateur Radio software developers such as ON7LDS that work to make Amateur Radio data communications better.
If you just want the most minimal-effort setup guide on how to run ethernet and IP over packet radio TNCs, skip down to the section: “One to Many, Many to One”.
The Old Ways
Running IP applications over packet radio TNCs and similar hardware has traditionally been possible, albeit in a somewhat limited form, using the Linux AX.25 kernel modules and utilities like kissattach. Recent bugs have prevented this method from working correctly in new versions of Debian (and derivatives), and there is even a discussion about removing kernel AX.25 support altogether.
While the kissattach method of IP networking over packet radio traditionally worked relatively well, it also has the drawback of having to encapsulate everything in AX.25 frames, and thus not supporting standard ethernet, while incurring overhead that is entirely unnecessary for IP networking.
A Cleaner Solution
With all that in mind, I found it was probably time to offer an alternative, so I wrote tncattach. It’s a small program that replaces the functionality from kissattach, and doesn’t require any special kernel modules.
With tncattach you can attach any KISS-compatible TNC as a fully ethernet-compatible network interface in Linux. It also supports more “lightweight” tunnel interfaces, for point-to-point links (where you don’t need the overhead of ethernet). And it of course fully supports both RNode and OpenModem.
After writing tncattach, I optimized the buffering and queues in the device firmwares, so be sure to update your RNode to at least version 1.16, and your OpenModem to version 1.05 or above for the best results.
This isn’t a new development (2022-01-25), but perhaps more relevant with the “recent unpleasantness” of Amateur Radio utilities being removed from the Linux kernel.
This is the third of three semi-related stories. I’m in awe of the creativity and energy of Amateur Radio software developers that work to make Amateur Radio data communications better.
Connect Systems - What Is New In M17
Email from Connect Systems (unfortunately, not available on web):
New Release of M17 Firmware
OpenRTX just released a new version of the M17 firmware. A complete list of the changes are below. However, there are only two significant changes:
Ability to send text messages between two radios
Improved voice quality by oversampling
For those interested, a users manual that shows how to use these features as well as the new firmware for the CS7000 M17 and the CS7000 M17 PLUS can be found by pressing one of the buttons below
Added
gfx: support for on-screen QR code generation
M17: metadata text transmission and reception
M17: packet transmission and reception
NVM: driver for STM32 internal flash
platform: API for vibration motor control
codec2: noise reduction of mic input via oversampling
Welcome to the Open Source in Amateur Radio wiki! This resource is dedicated to providing information about open-source software and hardware as well as free home-brew projects for amateur radio enthusiasts. The idea of this website or wiki is to give a (future) radio amateur an overview of all available open source projects. The aim is to promote the use of open source software and hardware in amateur radio. Depending on personal requirements, it is now possible to set up an amateur radio station whose main components are open source.
This was an ambitious project, which I hoped to participate in… but I didn’t, so I’m one of the guilty parties this statement refers to:
Help!
This wiki cannot be filled and maintained by one person alone, which is why I call on people to register on the wiki in order to correct errors, add information, translate articles and/or create new content.
Despite the title of this issue, the 250th issue of Zero Retries probably passed a couple of months ago as I have occasionally published special issues that weren’t numbered.
That said, each of these significant anniversary and issue number milestones amaze me. When I started Zero Retires, I never imagined that it would continue for more than five years, reach more than 3500 email subscribers, or that there would be enough source material to justify a new issue nearly every week. But Zero Retries is largely a virtuous cycle - the more issues are published, the more readers, the growing exposure all “widen the net” in finding technological innovation in, and adjacent to Amateur Radio, and then trying to report out some of those findings. It’s arguable if I’m just reporting on what’s happening, or that Zero Retries is playing some small part in growing that technological innovation. But, largely, thank you Zero Retries readers. If there wasn’t a substantive reader base, there would be little point in continuing to publish Zero Retries.
Thanks very much to the financial supporters of Zero Retries - the paid subscribers - Founding, Annual, and Monthly. There are significant expenses in publishing Zero Retries, and the financial contributions really, really help keep Zero Retries viable.
Burnout on Open Source Projects
In my research for this issue, I came across this sobering reminder - Carrier Switch, that for all the glories of creating open source hardware, software, documentation (and newsletters, and podcasts, and videos…), while those might be free to us users, creating them comes at a cost. Sometimes significant cost, as “Carrier Switch” explains.
It’s hard to understand why some open source projects seem sustainable, and others spark, burn brightly, and then eventually burn out. I wish someone could do a systemic study of that phenomenon. I certainly don’t have any answers, but I do have some observations.
Open source creators really need to maintain significant balance in their lives and be careful not to let their open source projects consume too much of their time and energy. I know - easier said than done. Really, I get that point, and I try to apply it to my life, and Zero Retries. Sometimes there are urgencies that need to be addressed, but long term, an open source project “isn’t your life”.
Forming a community seems to be a long term buffer against burnout, especially when you can distribute the load, especially the support load, amongst trusted others supporting the project.
If the open source project becomes significant enough that it does seem worth investing a significant portion of your time and energy (equivalent to at least a part time, if not full time job), then consider trying to get a financial grant such as those available from ARDC to “lighten the load” financially.
Similar to getting a grant, getting the help of an incubator organization like Crowd Supply lightens the load. Such organizations have much greater scale to expose your project to a wide audience, they can provide fulfillment services (especially critical in this era of complex tariffs, etc.) and they can just generally offer advice and support because they’ve seen many other projects before yours and know where the pitfalls are.
This might seem self serving given how often I mention this it in Zero Retries, but many open source projects “self sabotage” by not publicizing and promoting the project with a public website that supports and promotes the project. It’s not enough for information about your project to be exclusively on Facebook, or Discord, or LinkedIn, or X, or YouTube, or Groups.io (though that has a decent Wiki that can function as a website). A few of my favorite examples of project support / promotion websites are M17 Project,DigiPi, FreeDV, and AREDN.
Hamvention Ho!
1 week until Hamvention 2026 in Xenia, Ohio, USA... Zero Retries / DLARC booth 1506 in Building 1 / Maxim
Cale Mooth K4HCK in Amateur Radio Daily 2026-05-01:
Members of the Fediverse are invited to join fellow users at Hamvention 2026. An informal meet-up will take place Saturday, May 16th at 11:00 AM. We’ll meet in front of booth 1506 in Building 1, aka the Maxim building. Thanks to KB6NU for helping to organize!
(Booth 1506 is home to Zero Retries and DLARC. Thanks to Steve and Kay for allowing the use of their booth as a rendezvous point!)
I’ll be at the meet-up with stickers. Hope to see you there!
What is the Fediverse and how does it relate to ham radio? The Fediverse is a collection of social networking sites that communicate with one another in a decentralized way. It’s an open source alternative to centralized social networks such as Facebook and X. There are several ham radio themed Fediverse instances with thriving communities of radio amateurs:
I’m @n8gnj on mastodon.radio. Mastodon, and especially mastodon.radio7 is the only social media that I attempt Zero Retries to be involved with8. Mastodon has a reasonable number of Zero Retries Interesting techies that share interesting info there. I’ve been a poor participant of late, but I’m going to be working on that, and may try to post brief updates there from Hamvention 2026.
No Demos at Zero Retries / DLARC Booth
I’ve received several suggestions about doing demos of Zero Retries Interesting projects at the Zero Retries / Digital Library of Amateur Radio & Communications booth at Hamvention 2026.
It’s just not feasible to do so, at least this year.
The goal for Hamvention 2026 is to widen the exposure to Zero Retries within the wider Amateur Radio community that otherwise wouldn’t encounter Zero Retries. Another goal I had with the Zero Retries booth was to make half of it available to DLARC for it to have some exposure at Hamvention 2026 (commercial, indoor booths are very hard to get on short notice - there’s a considerable waiting list).
I suspect that I’ll be explaining Zero Retries until my voice is hoarse, and shaking hands to the point of hand cramps (per a friend who’s a veteran of many Hamventions as an exhibitor.
I was gratified to receive personal invitations to meetups on Friday and Saturday evenings from groups that I admire and follow in Zero Retries.
Michael Kalter W8CI via Amateur Radio Daily 2026-05-04 had an interesting mention:
Amateur Radio in 2026: A Hobby Transformed
…
The hobby has evolved dramatically in recent years. Digital modes like FT8 rewrote what “weak signal” communication means, allowing operators to make transcontinental contacts with just a few watts of power. Experimental modes like FT2 are already being discussed in labs and forum threads. Software-defined radios (SDRs) have put sophisticated spectrum analysis tools in the hands of anyone with a laptop. Mesh networking on VHF and UHF bands is enabling hams to build their own internet-independent communication infrastructure. Machine-learning-assisted decoders are pushing the boundaries of what the human ear — or any radio — can resolve from noise.
I found this a refreshing, and accurate, if incomplete nod that by Hamvention that Amateur Radio is being transformed in the 2020s with such technologies. I hope those technologies will actually be substantively featured in the exhibitors and forums at Hamvention 2026.
We’re traveling over this weekend, and when we return we will be in frantic preparations for exhibiting at Hamvention 2026. But after my return… N8GNJ / Zero Retries Labs is literallyfull (almost to burstin’) of deferred projects.
The weather here in Whatcom County, Washington this late Spring is about as perfect as it can be with mild temps and ample sunshine, which means the Labs big shop doors can be open to the fresh air and sunshine.
Three urgent projects are to get systems on the air for MeshCore (thanks again to Steve Monsey N0FPF for the loan of that unit), 1200 bps AX.25 Packet Radio, and VARA FM, as there are now folks on the air in this area to interoperate with on those modes.
A connection to HamWAN, and 44Net Connect are also near term projects. As you read above, Connect Systems just made a new firmware update for my pair of CS7000 M17 PLUS portable radios, so that’s also on the near-term list.
Lastly, I have several review units that have been sent to me that I have not yet taken the time to review.
Have a great weekend, all of you co-conspirators in Zero Retries Interesting Amateur Radio activities!
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 financially:
Founding Member 0000 - Steven Davidson K3FZT (Renewed 2025, 3rd year!) Founding Member 0001 - Randy Smith WU2S (Renewed 2025, 3rd year!) Founding Member 0002 - Chris Osburn KD7DVD (Renewed 2025, 3rd year!) Founding Member 0003 - Don Rotolo N2IRZ (Renewed 2025, 3rd year!) Founding Member 0004 - William Arcand W1WRA (Renewed 2025, 3rd year!) Founding Member 0005 - Ben Kuhn KU0HN (Renewed 2025, 3rd year!) Founding Member 0006 - Todd Willey KQ4FID (Renewed 2025, 3rd year!) Founding Member 0007 and 0010 - Merik Karman VK1DF / VK2MKZ (Renewed 2025 x2, 3rd year!) Founding Member 0008 - Prefers to Remain Anonymous 08 (Renewed 2025, 3rd year!) Founding Member 0009 - Prefers to Remain Anonymous 19 (Renewed 2025, 2nd year!) Founding Member 0011 - Rick Prelinger W6XBE (Renewed 2025, 2nd year!) Founding Member 0012 - Ryan Tolboom N2BP (Renewed 2025, 2nd 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 (New 2025) Founding Member 0016 - Prefers to Remain Anonymous 77 (New 2025) Founding Member 0017 - Phil Karn KA9Q (New 2025) Founding Member 0018 - Prefers to Remain Anonymous 95 (New 2025) 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)
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.
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.
I have no issues with EA5HVK choosing to offer VARA as a product (purchase of a license key for full functionality), not releasing the source code, and only releasing a version for Windows.
I’ve long needed a new iPad. My current “big iPad” that I inherited from my late Mother In Law continues to work great… but it’s now aged beyond Apple’s willingness to provide all but the most critical security updates, so a lot of cool apps cannot be loaded onto it.
