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
Substack says this issue is likely to be truncated by some email clients. Thus, it might be easier to read in a web browser:
www.zeroretries.org/p/zero-retries-0267
It’s easy and free to subscribe for your own copy of Zero Retries every week:
In This Issue:
ZRDC 2026 Update 10/30/2026
Tina Stroh KD7WSF
Zero Retries Digital Conference 2026 - N8GNJ Debrief
Steve Stroh N8GNJ
Breaking: xara - a VARA-compatible Modem for Linux
Steve Stroh N8GNJ
Once Upon a Time, I Imagined an Open Source Equivalent of VARA
The Existence of xara Could Grow VARA Communities and Ecosystem
AnyRadio - Receive AnyFrequency / Receive AnyMode…
Steve Stroh N8GNJ
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 are a large portion of the “seed capital” we needed to host Zero Retries Digital Conference (ZRDC) 2026, and future ZRDCs. Thank You!
Our thanks to Todd Willey KQ4FID for renewing as Founding Member 0006 to Zero Retries in the past two weeks (4th year)!
Our thanks to Merik Karman VK1DF / VK2MKZ for renewing as Founding Member 0010 to Zero Retries in the past two weeks (4th year)! We are doubly grateful to VK1DF / VK2MKZ as he is also Founding Member 0007!
Our thanks to Ryan Tolboom N2BP for renewing as Founding Member 0012 to Zero Retries in the past two weeks (3rd year)!
Founding members are listed in every issue of Zero Retries!
Our thanks to Brian Webster N2KGC for renewing as an Annual Paid Subscriber to Zero Retries in the past two weeks (4th year)!
Our thanks to Prefers To Remain Anonymous 12 for renewing as an Annual Paid Subscriber to Zero Retries in the past two weeks (4th year)!
Our thanks to Prefers To Remain Anonymous 13 for renewing as an Annual Paid Subscriber to Zero Retries in the past two weeks (4th year)!
Our thanks to Jeffrey Komori KH6JUZ for renewing as an Annual Paid Subscriber to Zero Retries in the past two weeks (3rd year)!
Our thanks to Phil Marquis K6HSV for renewing as an Annual Paid Subscriber to Zero Retries in the past two weeks (3rd year)!
Our thanks to Prefers To Remain Anonymous 51 for renewing as an Annual Paid Subscriber to Zero Retries in the past two weeks (3rd year)!
Our thanks to Don Mertz KJ4MZ for renewing as an Annual Paid Subscriber to Zero Retries in the past two weeks!
Our thanks to Prefers To Remain Anonymous 63 for renewing as an Annual Paid Subscriber to Zero Retries in the past two weeks!
Our thanks to Prefers To Remain Anonymous 139 for upgrading from a free subscriber to Zero Retries to an Annual Paid Subscriber in the past two weeks!
Our thanks to Prefers To Remain Anonymous 140 for upgrading from a free subscriber to Zero Retries to an Annual Paid Subscriber in the past two weeks!
Our thanks to Prefers To Remain Anonymous 142 for becoming a new Annual Paid Subscriber to Zero Retries in the past two weeks!
Our thanks to Prefers To Remain Anonymous 143 for becoming a new Annual Paid Subscriber to Zero Retries in the past two weeks!
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 #ZR0267. Paid subscribers can comment directly on the web version of this issue.
ZRDC 2026 Update 10/30/2026
By Tina Stroh KD7WSF
Zero Retries Digital Conference Manager
This is the last in a series of updates regarding Zero Retries Digital Conference 2026.
AND IT’S A WRAP!!! ZRDC 2026 is in the book.
Now that the conference is done, where to begin with all the thank you’s? In no special order…..
Thank you to Don Rotolo, N2IRZ, who graciously volunteered to put the conference proceedings together again for the second year. Don not only receives the papers and the ZRDC presentations but then formats all of the material into a booklet. It is a time-consuming job and one that he does on his own time and expense. Don, you are truly a gift and more than a friend.
Thank you to our speakers, Jeff Scoville AE5ME, Glen Popiel KW5GP, Craig Lamparter KM6LYW, Cale Mooth K4HCK, Mooneer Salem K6AQ, Dave Platt AE6EO, and Martin AlcockVE6VH. Without you all, there would not be a conference. Your presentations were spot on, relevant and all that we hope for to showcase in Zero Retries. Our readers should know, our in-person speakers travel to the ZRDC at their own expense, which further demonstrates their commitment to Amateur Radio.
To our attendees, both in-person and virtual, thank you for supporting the mission of Zero Retries and the ZRDC. To all of you who took the time to personally thank Steve and me, your comments meant so much to us. We are thrilled that you enjoyed the conference and hope to see you at another ZRDC. To Lawrence Bain KO6KCF, thank you for being our number one cheerleader at Pacificon. We had a fair number of people come and ask about the conference. And when asked how they heard about the conference, they replied they heard someone talking about it. So thank you, word of mouth is always the best form of marketing. A very special thank you to David “Zonker” Harris N6UOW who was not only an attendee but who graciously volunteered to monitor the Zoom channel for questions from our virtual audience.
Many thanks to Ren Roderick K7JB for creating our speaker gifts. We loved the ones he made for us and on short notice was able to make individual leather-covered notebooks laser engraved with the Zero Retries logo and the speaker’s callsign. They are totally unique and we hope they will be well enjoyed by all the speakers.
To Shelby Wilson, Sales Manager at the Roundhouse Market and Conference Center, THANK YOU! You were an absolute delight to work with, especially since we were not local to the San Ramon area. The Roundhouse was just an excellent event center for our conference and we look forward to working with you in the future. And to Michael Schuyler from VIP Audio Visual Company, your coverage of our event was exceptional and your expertise was phenomenal. Thank you so much for making us look so good.
As I have mentioned previously, Steve and I felt there was a fair amount of animosity towards us by the Mt. Diablo Amateur Radio Club (MDARC) and the coordinators of Pacificon 2026 for having the ZRDC on Friday, the same day as the Pacificon Antenna Seminar. Steve and I prepared a proposal and presented it to the MDARC Board of Directors but unfortunately our proposal was rejected. Therefore, we elected to move forward with our plans to hold an independent conference. Once we announced the plans and specifics of ZRDC 2026, I did receive some objectionable emails. I only mention this history so that readers have a basis to understand how much we appreciated a number of MDARC members who approached us and offered an apology. Their comments were sincere, kind and most appreciated.
Along the same lines, we were approached by the Pacific Division Director John Litz NZ6Q and Antonis Papatsaras AA6PP and had a frank discussion about the perceived animosity and why our application to be a sanctioned ARRL event and subsequent emails were ignored/not acknowledged. After some discussion, there is a plan in place to determine where the breakdown in communication occurred and we graciously accepted their apologies. It meant a lot that these men sought us out to resolve this issue before we had the opportunity to seek them out. It is our hope that in the future we can work together, regardless of personal opinions as we hope to bring the 2028 ZRDC back to the Pacificon weekend and the 2028 ARRL National Convention.
As I conclude this column, I have made a few mentions regarding future ZRDC conferences. Although I cannot confirm when and where, having a third ZRDC in 2027 is a very real possibility. Thanks to Glen Popiel KW5GP, who was very convincing and offered much guidance that will go into making this decision. We will definitely keep our readers and supporters posted and will have an update likely after the holidays. We need to close the books for ZRDC 2026 and determine if it is financially visible for 2027. In the meantime, I offer my sincere thanks for the opportunity to host and manage another conference and hope I did not miss anyone. Wishing you all the happiest of holiday seasons.
73’s,
Tina
Please direct comments / feedback about this article to the Zero Retries email list with the hashtag #ZR0267. Paid subscribers can comment directly on the web version of this issue.
Zero Retries Digital Conference 2026 - N8GNJ Debrief
By Steve Stroh N8GNJ
Many thoughts and observations about the subjects presented and the overall experience of ZRDC 2026.
Thanks Owed
First, ZRDC 2026 (or 2025) would not have happened without the incredible amounts of work, and the intensity of that work, the quality of that work and attention to detail, and the time it consumed, if it weren’t for my wonderful, and wonderfully competent wife and the brains of the outfit, Tina Stroh KD7WSF. If you enjoyed ZRDC 2026 in any way, please let Tina know.
Proceedings - Don Rotolo N2IRZ
Our thanks to Don Rotolo N2IRZ for lifting the entire weight of managing, editing, and creating the ZRDC 2026 Conference Proceedings document off Tina’s and my shoulders. Don did an amazing job and you’ll agree when the Proceedings are released in the near future.
Sponsors and Door Prize Donors
Our thanks to our generous sponsors. Most in-person attendees got one of the many door prizes donated by our sponsors:
ALLSCAN.INFO
ARDC
CentyLab
GigaParts
NA6D
TAPR
Presenters
Our thanks to all the presenters at ZRDC 2026 for absolutely stellar presentations:
Steve Stroh N8GNJ - Keynote Address, Late 2026 Update on the LinHT
Cale Mooth K4HCK - New Tech Hams
Craig Lamparter KM6LYW - DigiPi
Jeff Scoville AE5ME - M17
Martin Alcock VE6VH - IP400
Glen Popiel KW5GP - Microcontroller Communication Technologies and Protocols for Ham Radio
Mooneer Salem K6AQ - Free DV
Dave Platt AE6EO - OpenTNC
Panelists
Our thanks to the participants of the panel discussion on Encryption in Amateur Radio:
Steve Stroh N8GNJ
Cale Mooth K4HCK
Glen Popiel KW5GP
Craig Lamparter KM6LYW
Paper Authors
Our thanks to the paper authors for contributing new and unique papers relevant to digital communications in Amateur Radio. These papers were written specifically for ZRDC 2026:
An OFDM Data Mode for Amateur Radio by Martin C. Alcock VE6VH and R. Nino Carillo KK4HEJ
AX.25 Version 2.2 by John Langner WB2OSZ
unambilify: a real-time neural post-filter for AMBE and Codec 2 digital voice by Rob Ludwick AJ7HR
A Unique Perspective of the New Tech Ham by Cale Mooth K4HCK
OpenTNC – its development, issues and solutions by David Platt AE6EO
Predicting short radio paths on VHF and UHF using Radio Mobile by Don Rotolo N2IRZ
The Proceedings of the Zero Retries Digital Conference 2026 which includes these papers and some presentations will be made public in the near future.
Demonstrations
Special thanks to Jeff Scoville AE5ME not only for a great presentation that brought us all up to speed on the state of the art on M17, but also for bringing working M17 hardware, including an M17 repeater. He did so with signifiant effort to tote it over to the conference venue and a plane flight.
Special thanks to Alan Johnston KU2Y and AMSAT for the loan of one of AMSAT’s loaner CubeSatSims that we displayed at ZRDC 2026 and the Zero Retries booth at Pacificon 2026. It was quite the conversation starter.
Special Thanks
Special thanks to David “Zonker” Harris N6UOW for monitoring the chat session on the Zoom feed that enabled the virtual attendees to ask questions of the presenters.
Our thanks to Michael Schuyler, our AV technician from VIP Audio Visual Company who provided all of the AV equipment and recorded the many disparate activities going on at ZRDC 2026. The video produced by VIP is professional quality, as you’ll soon see.
Lastly, our thanks to the staff and the excellent venue of the Roundhouse Conference Center in San Ramon, California. The Roundhouse is literally across the street from the venue of Pacificon 2026. We highly recommend the Roundhouse if you need a conference venue in San Ramon, California.
One Failure - No Dedicated Photographer
We didn’t get a volunteer that offered to act as a dedicated photographer for ZRDC 2026, and I failed in that role because I get too caught up in the moment(s) to remember to take good photos of each speaker and the other activities occurring in the room. Fortunately the videos are of such good quality that we’ll be able to extract some screen grabs to serve as photos.
And thanks to all of the attendees at ZRDC 2026.
If You Missed ZRDC 2026…
If you’re a reader of Zero Retries and “you wish you’d been able to attend”, well, we tried 😉 mightily to get folks interested. We publicized ZRDC 2026 as widely as we could and we made it as accessible as we could (pricing, venue, and location). Tina made heroic efforts to get the word out beyond the usual Zero Retries channels, especially to Amateur Radio clubs and schools in the San Francisco Bay Area. To those of us who said “… if you’d held it in the Seattle area again”, or “wish it was someplace in the Midwest or closer to the East Coast…”, well, maybe in a future year, but our budget for ZRDC is pretty lean at the moment, and Tina is adamant that we don’t take out a business loan to finance a really deluxe conference (one of my less helpful suggestions).
As Tina has explained in her ZRDC columns, we weren’t able to get ZRDC 2026 listed by the ARRL as a Specialty Technical Conference, and we know that cost us some potential attendees. We know, because folks came up to our table at Pacificon 2026 and told us that they wish they had known about ZRDC 2026 and would have attended if they had known about it. As Tina explained, we had “productive conversations” about that issue, and we have reason to hope that situation won’t reoccur if we decide to attempt a future ZRDC in conjunction with a future Pacificon.
That said, ZRDC 2026 was mentioned in the Upcoming Conferences section of the July / August 2026 issue of ARRL’s QEX Magazine, and we’re grateful to QEX Editor Ronald Diehl NQ8W for that mention. We’re privileged to be mentioned in such good company as the many other technical conferences mentioned in QEX.
Finally, on Saturday at Pacificon, one ZRDC 2026 attendee pulled me aside for a quick conversation and said “Well… that was fun… but one day isn’t really enough!” As an attendee at a number of ARRL and TAPR DCCs that we held on full days on Friday and Saturday, “break it up at midnight” show, tell, and chat session on Friday, a banquet dinner on Saturday, and an hours-long technical seminar on Sunday morning… I agree. A long weekend version of ZRDC would be ideal. I hope that Tina and I can work towards a longer ZRDC. But… the attendance, and the finances have to support such an ambition. The ARRL and TAPR DCCs had two organizations behind that event, and decades of experience and momentum and resulting expectations of significant attendance. At the moment, ZRDC is just Tina, me, and several enthusiastic volunteer helpers, and the meager finances of Zero Retries and a bit of financial help from ARDC.
If you missed attending ZRDC 2026, the good news is that we’ll soon publish:
Videos,
Slide decks of the presentations as presented (some are different than what is in the Proceedings),
Proceedings of the Zero Retries Digital Conference 2026, including the five unique new papers written specifically for ZRDC 2026,
A bonus is that because we used our Zero Retries Zoom account, we have access to AI-assisted summaries and transcripts of the audio portions of the presentations.
All of that will soon be made publicly available on the Zero Retries website and the Digital Library of Amateur Radio & Communications (DLARC).
Lastly, I have a lot of work to do to clean up ZRDC web page and specifically the particulars for ZRDC 2026, and some leftover cleanup work for ZRDC 2025, and then clear that page for updates on a future (we hope) ZRDC 2027.
Reporting Out on Significant Projects / Products
One justification of the ZRDCs (and the DCCs and other technical conferences) is that they provide a reason… perhaps a catalyst… to “report out” on various projects with “status of the project” presentations, formal technical papers, and the overall higher level of technical perspective than a general Amateur Radio conference, or an online presentation for a general audience.
Apart from ZRDC, I think every significant project or product in Amateur Radio needs that level of detail and exposure. As you’ll see, all of the presentations at ZRDC 2026 were of this quality and served to update the projects / product communities such as DigiPi, FreeDV RADE (one at ZRDC and one at Pacificon), IP400, M17, and OpenTNC. There were also several such presentations at Pacificon 2026 including AREDN, DLARC, and MMDVM.
For example, I think there should be an annual report for significant projects / products in Zero Retries Interesting Amateur Radio, suggested solely as examples:
44Net / 44Net Connect
APRS
Digital Amateur Television
Dire Wolf Software TNC
GNU Radio (related to Amateur Radio)
Hams.com (in 2027)
Meshtastic / MeshCore (mostly related to Amateur Radio) and use of LoRa in Amateur Radio
New Packet Radio
NinoTNC
Packet Radio (again, what’s new… such as in 2026, OpenTNC)
RepeaterBook
VHF / UHF Software Defined Receivers and Transceivers
Winlink
Zero Retries (yes, I think I should do an annual report for ZR)
I would have included AMSAT / Amateur Radio space and HamSCI, but AMSAT recently concluded their 2026 conference (three days), and HamSCI had a two-day conference earlier this year.
ZRDC 2026 Was All Highlights
All of the presentations and papers at ZRDC were directly solicited from developers of Zero Retries Interesting projects, all of whom are readers of the Zero Retries newsletter. Thus all the presenters had had a good understanding of the overall “tone” of ZRDC 2026 - an audience that is fairly technical, but not professional, academic, or engineering.
I’m not going to say that any one presentation was a highlight, because that’s like asking a parent which one is their favorite child. I’m sure you’ll forgive me for that because the ZRDCs are my fantasy conference of some of the most Zero Retries Interesting things occurring in Amateur Radio. I sat in the front row enthralled at each presentation.
ZRDC 2026 was a strong validation of the value of having an in-person conference focused on Digital Communications in Amateur Radio. In between the presentations, I was fortunate to overhear many impromptu conversations, and I overheard several discussions of future collaborations, and I was delighted to be involved in some of those discussions.
All that said, I’m extremely proud and grateful for all of the presentations and papers at ZRDC 2026, but I take no credit for those excellent works - all credit is due to the individual presenters and paper authors for their expertise and willingness to write and present about their projects.
Lesson Learned 1… Again… Prepare Demos a Year in Advance
I had “plans” to do several demos but our departure date for San Ramon kept creeping closer and the urgent tasks kept taking precedence. I way-too-optimistically packed a bunch of projects-in-progress in a big case for the possibility of having “extra” time to work on them. I didn’t… of course, I didn’t.
So for the next ZRDC…
I start working on those demos next weekend and throughout the year. It stings that the cool stuff I want to show off, I couldn’t (didn’t) because I didn’t work to plan my time during the preceding months. I’m particularly “stung” by not having the hinted book ready for ZRDC 2026. That too is now at the top of the Zero Retries priority stack. The good news is that there were very productive discussions about getting some well-qualified help on the book(s) that I’m planning that have considerably lightened my task load for producing those books.
Lesson Learned 2 - Bring Multiple Laptops
Several presenters, admirably, travel light. As in they didn’t bring their own laptops for presentation - “Steve, I emailed you the presentation”. Yes, they did. So I put their slide deck up on my laptop and it worked out OK.
“Big conferences” do this - supply a laptop loaded with all the presentations, pre-tested, complete with remote “clicker”, etc. We will now take that hint and do so in future ZRDCs.
In the following sections about the individual presentations, what you read is just a “glancing blow” description of the richness of detail and the distilled wisdom that the presenters all brought to ZRDC 2026. I can’t do justice to their presentations, and will let the videos and their slide decks do so, to be released soon.
Keynote Address - Steve Stroh N8GNJ
I gave some background about the evolution of Zero Retries over the past five years, and a brief synopsis (too brief, I was told by Tina) of the projects / presentations from ZRDC 2025.
I offered three Technological Innovation in Amateur Radio (TIIAR) trends that I’m now seeing consistently:
NewTechHams are now a noticeable demographic in Amateur Radio, being noticed and discussed by other organizations,
Meshtastic and MeshCore is a serious movement, including driving the adoption of LoRa modulation in Amateur Radio, most notably with APRS over LoRa beginning to displace the use of 1200 bps AFSK,
AI assisted software development - there are now many new apps and entire systems (such as Hams.com) being developed by “vibe coding”, and
There’s a lot of use of AI being embedded into applications and run locally, not online / data centers.
AI assistance is not being limited to software and systems; it’s also being used for 3D design and printing, circuit design, especially RF design, troubleshooting, protocol analysis, “rescue engineering” such as replicating the functionality of a significant system or software when the original specifications or software or schematics are lost. A significant use of AI is to keep a system going when a component has become unobtanium.
I noted that there are new (or newly recognized) data modes being used in Amateur Radio in 2026 including Mercury modem for HF, Modem73, New Packet Radio - Next Generation (NPR-NG), and IP400. The OpenTNC embeds both 9600 Frequency Shift Keying (FSK) and FX.25 Forward Error Correction (FEC) that’s compatible with AX.25.
ARRL’s new book Digital Networking for Ham Radio was a real breakthrough!
I gushed about FreeDV RADE now being available in FlexRadio 8000 and Aurora radios as “just another mode selection”.
One of my last points was that I (continue to) think that there is room in Amateur Radio for a new organization that is focused on what Amateur Radio actually is in the 21st century.
I also provided a separate presentation as a brief update on the LinHT, largely pulling together elements about the LinHT that have been mentioned in previous issues of Zero Retries.
Cale Mooth K4HCK - New Tech Hams
If I do permit myself an “attaboy” for recruiting a ZRDC 2026 presenter, it will be for asking Cale Mooth K4HCK to do a presentation on NewTechHams. K4HCK gave us a stellar presentation about NewTechHams from his perspective of being one, and he also gave us a stellar longer-form explanation in his submitted paper - A Unique Perspective of the New Tech Ham.
K4HCK distilled the primary attributes of a NewTechHam:
Software-first
Data over RF
Simplicity
Creativity
He also pointed out that MeshCore is this generation’s easy and inexpensive entry point into radio experimentation, just as CB radio was to a couple of generations ago. A great illustration of getting the point across about easy experimentation was his illustration of a free app for decoding SSTV transmissions from the International Space Station - just use an inexpensive portable radio to tune in the ISS during an overhead pass, turn up the audio, and then use a free SSTV app on a mobile phone to see the image.
To engage NewTechHams, K4HCK recommends two key points:
NewTechHams attend meetups focused on one topic, including those focused on a particular demographic such as I.T. Girls.
Informal leadership structure - no members, no fees, no legal structure, but some formality such as establishing a Code of Conduct, and meeting in professional work spaces.
Craig Lamparter KM6LYW - DigiPi
For those, like me, who are fans of Craig Lamparter KM6LYW from his YouTube channel KM6LYW Radio, he needs little introduction. He spent the majority of his presentation discussing his primary project, DigiPi which I term a Minimum Viable Amateur Radio Data Communications Appliance. KM6LYW focuses relentlessly on keeping DigiPi simple, lean, and efficient, and thus low-cost. One example is that DigiPi runs only one application (mode) at a time. When you start a new mode, the previous mode is stopped and flushed from memory, thus keeping the memory requirement low and response fast. His original host computer for DigiPi was a Raspberry Pi Zero 2 W, but because those aren’t available at the moment, he recommends using older, trailing edge Raspberry Pi models that are available (Raspberry Pi 4 and 5 are overkill and have gotten more expensive of late).
A DigiPi isn’t intended to be used locally - only a minimal, small “eye candy” status display. You run a DigiPi remotely on any web browser - phone, tablet, or laptop. He showed a minimal DigiPi station that can be put together for $70. Lastly, he demonstrated that DigiPi is actively being maintained and improved with two new data modes - Mercury modem for use on HF, and Modem73 for use on HF and VHF / UHF.
It was brilliant scheduling on Tina’s part to have KM6LYW follow K4HCK’s New Tech Hams presentation as DigiPi is the kind of hardware example to lead with to interest a potential NewTechHam in the (expanded) capabilities of Amateur Radio - accessible (easy to obtain parts), inexpensive, hackable, but highly functional. The only thing I would add to DigiPi stations be built-up up as loaner units for potential NewTechHams would be an inexpensive J-Pole antenna made of coaxial cable that can be taped up on a wall or a window.
Jeff Scoville AE5ME - M17
Jeff Scoville AE5ME’s presentation on M17 is a perfect illustration of why Tina and I decided to attempt the Zero Retries Digital Conferences. I consider myself… not an expert… but reasonably well informed about M17, and easily more than half of the items EA5ME AE5ME1 touched on in his very detailed presentation I was not aware of, such as the amazing number of software defined receiver software packages, and apps such as MSEVEN that natively support M17.
AE5ME also perfectly followed the NewTechHams theme regarding M17 with this bullet point:
A chance to bring Amateur Radio back to the experimenting and hacking roots of the hobby.
There was so much detail in AE5ME’s presentation that it takes a careful study to run down and understand the many references he provided. The totality of AE5ME’s presentation illustrates how much activity there is in the M17 community and ecosystem… and most of it is below the threshold of attention for most of Amateur Radio, thus it merits continual mentions in Zero Retries and other Amateur Radio media.
Martin Alcock VE6VH - IP400
Martin Alcock VE6VH was our sole remote presenter at ZRDC 2026. Martin began with a review of the original goals of the IP400 (Intelligent Protocol on the 400 MHz band) project - built-in mesh networking, faster data than 9600 bps Packet Radio, and the early progress of IP400.
Because of various issues, IP400 was reconceptualized to go beyond mesh networking and faster data rates, to incorporate an enhancement to repeaters to add IP400 capability, and also an option for mobile stations… and use OFDM to make the data path of IP400 more robust, more adaptive, and more capable depending on the radio the user has. That additional scope was enabled by a grant from ARDC.
The IP400 project’s focus in late 2026 is debugging the prototypes of the Advanced Mesh Network Controller (AMNC) which distills the complexities of this new use of OFDM into an appliance that incorporates a capable processor and an Field Programmable Gate Array (FPGA). An ANMC can either be mated with a Raspberry Pi (for networking, remote access, etc.) or operated standalone with a serial connection to a host. The AMNC is the basis of the repeater upgrade to add IP400 capability.
IP400 and the AMNC and the potential to incorporate much better data communications and mesh networking than we can do currently with low powered radios and simple modulation schemes will be a very effective demonstration to NewTechHams of what’s possible with Amateur Radio that isn’t possible solely operating in unlicensed spectrum.
VE6VH released his slide deck as presented - https://ip400.adrcs.org/wp-content/uploads/2026/10/IP400-ZRDC-Presentation-2026.pdf
It is planned that the AMNC will be available for sale in 2027-Q1. VE6VH encourages anyone who would like to participate in beta testing, email VE6VH - ve6vh@ve6vh.org
Glen Popiel KW5GP - Microcontroller Communication Technologies and Protocols for Ham Radio
I had originally invited KW5GP to speak about his recent book Digital Networking for Ham Radio, but he chose to talk about his newest book project with the ARRL, a series of books on how to experiment with low cost microcontrollers such as the ESP32 family.
My mind was blown with just how capable… and how inexpensive… these newest generations of the ESP32 processor line have become. My previous frame of reference is that these are the devices embedded into Internet of Things devices as mundane as light bulbs… but the most capable versions can now run embedded operating systems, and they have been so well characterized, with so much open source software written for them, that they are now the go-to device for vibe coding in Amateur Radio. You start with one of these devices to prototype, and then often discover that you don’t need a more capable device, or if you do, you can just “step up” to a more powerful unit in the same family that can run your existing code.
But what really gobsmacked me about KW5GP’s presentation was the many, many different radio modes that have been developed for these units, some of which are unique (proprietary, but well-understood in the industry) to these processors or companies. For example, when your communication needs are very simple, the overhead of Wi-Fi and TCP/IP is overkill - just discover and communicate between devices with simple broadcast protocol.
And, KG5WP continued the trend of “speaking to the NewTechHams” by illustrating just how easy it is to get started in developing projects based on these inexpensive and capable microcontrollers, which can eventually “graduate” to be used in Amateur Radio.
Mooneer Salem K6AQ - Free DV
In his presentation, K6AQ explained the genesis of FreeDV, and the evolution of FreeDV to FreeDV RADE. In the earliest versions of FreeDV, it didn’t sound (to my ears) much different than other vocoder-based digital voice systems used in Amateur Radio such as DMR and D-Star. That’s because the vocoder used in FreeDV - Codec 2, wasn’t that different. But like M17, the differentiating feature of FreeDV is that it was open source and software-based rather than embedding a digital voice mode into a (proprietary, non-upgradable) chip such as DMR and D-Star.
FreeDV RADE was enabled by a grant from ARDC allowing focused attention from the developers, including hiring contract programmers. The presentation went into detail about how the Radio Autoencoder (RADE) was developed using Machine Learning models.
One of the more interesting bits of information in the presentation was that to get FreeDV RADE to be able to be “installed” into the FlexRadio 8000 and Aurora series of radios as “just another mode”, the FreeDV RADE software had to be “shrunk” to a “reasonable size”. The large size was because a lot of the code was in Python, which required the use of a large library. This was accomplished by using AI software development tools which converted the Python code to C within a reasonable timeframe:
Basically gave Claude the RADE codebase and told it to convert to C.
The result wasn’t perfect, but it saved significant human labor, and eventually made it possible to fit into the Flex radios.
FreeDV RADE, like M17, is natively supported in a number of Software Defined Radio software. FreeDV RADE is now MIT licensed to encourage commercial adoption.
Lastly, K6AQ hinted “but wait, there’s more” that he would reveal at his Pacificon presentation on Sunday.
That turned out to be that version 2 of FreeDV RADE, which is now in advanced testing. V2 not only improves the voice quality of FreeDV RADE (by using a more recent round of Machine Learning analysis), but the occupied bandwidth of FreeDV RADE will be reduced from 1.5 kHz currently, to 850 Hz. V2 will not be backwards compatible with older versions of FreeDV RADE, so it’s expected that there will be a “big switch” at a future date to be announced.
K6AQ released his slide decks from his ZRDC 2026 presentation and his Pacificon 2026 presentation publicly - https://freedv.org/recap-pacificon-zero-retries-digital-conference/.
Dave Platt AE6EO - OpenTNC
AE6EO led off by disclaiming he was one of those dangerous individuals who is a software developer who also uses a soldering iron… and occasionally, an oscilloscope. That’s a perfect description of a NewTechHam, or in given his decades of experience, an OldTechHam.
The OpenTNC has a perfect division of labor with AE6EO having developed the OpenTNC as an open source hardware and software project, and Nigel Armstrong NA6D creating a commercial version of the OpenTNC. AE6EO has no desire to be involved in manufacturing, fulfillment, and customer service and is delighted to see NA6D take that on and make the OpenTNC widely and inexpensively available.
The OpenTNC incorporates a number of advancements beyond “same old, same old” TNC technology such as 9600 bps FSK and 1200 bps AFSK and FX.25 Forward Error Correction. But then AE6EO tackled a pain point of AX.25 Packet Radio that’s existed as long as we’ve had varying speeds, and the resulting inability to share a single channel:
Simultaneous demodulation of signals at multiple baud rates (e.g. 300/1200, 1200/2400, or 1200/9600). Usable combinations depend on CPU cycles available
“Smart” response – TNC tracks data modulation used by peer connections/sessions, transmits responses in the same mode, switches “on the fly” if different connections use different rates
Works in KISS mode, as well as for TNC-based connections
Again, this is incorporated inside the firmware of the TNC - sorting out 9600 versus 1200 bps connections, and exchanging data at the same speed, is a non-issue with an OpenTNC. In my opinion, this capability now sets a new benchmark / expectation of what a modern TNC should be expected to do.
Other new capabilities include compression that is also handled transparently between two OpenTNCs, a “scheduler” which can mitigate some of the issues of Hidden Nodes for a multi-connect station such as a BBS, and the capacity to “translate” nodes that are capable of using AX.25 v2.2 from those that are not capable of AX.25 v2.2. Normally trying to communicate v2.2 to a TNC that isn’t v2.2 results in wasted channel time from timeouts, but the OpenTNC “remembers” which station is which, and switches modes on the fly.
And… AE6EO touched on my three big wishlist items for a future version of the OpenTNC, achieving near-perfection of the TNC in my opinion:
Internal node/BBS/mailbox (needs a board re-spin to support external storage such as SD card)
NET/ROM addressing
IL2P protocol support
The combination of FX.25 and IL2P Forward Error Correction options is a huge win for future Packet Radio development. An internal (personal) BBS, and most impressively, incorporation of NET/ROM functionality (the first capable dynamic mesh networking system in Amateur Radio Packet Radio) really completes my wish list to take AX.25 Packet Radio into the late 2020s.
The combination of the Raspberry Pi Pico / Pico 2 microcontroller, and the embedded Zephyr Realtime Operating System, and perhaps future more powerful microcontrollers means that the OpenTNC can probably be expanded indefinitely to perhaps use new data modulations based on OFDM techniques such as Modem73 and perhaps xara.
In a word, I was jazzed about those new capabilities of OpenTNC. AE6EO’s updates “innovate within the standard” and in communicating with older TNCs, all those new features in OpenTNC remain fully (and transparently, and efficiently) backwards compatible. An assembled and tested OpenTNC being available for only $99 from NA6D is a huge win for Amateur Radio Packet Radio, especially being able to share a channel with 1200 and 9600, Forward Error Correction, compression, and AX.25 v2.2 transparently promises some significant advancements in Packet Radio networks.
And remember… OpenTNC is an open source project so future innovations can build on the work done in OpenTNC. For example, perhaps the “scheduler” can be ported to digipeaters to make their operation more efficient with digipeater users not being able to “hear” each other and causing collisions which reduce channel efficiency.
I am very grateful to AE6EO (and John Langner WB2OSZ of Dire Wolf Software TNC whose work AE6EO built upon) for taking AX.25 Packet Radio out of the “legacy” category into relevance and usability in the 21st century with the OpenTNC and especially the transparent enhancements he has incorporated.
Panel Discussion - Encryption in Amateur Radio
I’m grateful to KW5GP, K4HCK and KM6LYW joining me on a calm, reasoned, public discussion about the possibility of additional use of encryption in Amateur Radio among those of us who are already public-facing within Amateur Radio and thus not afraid to voice our candid opinions on this subject.
We didn’t achieve any solid consensus, but we had a robust discussion, in public, in front of the technical audience of ZRDC 2026. One takeaway was that K4HCK and KM6LYW (the two youngest panelists) do not see any justification for encryption in Amateur Radio, while I and KW5GP (the older two panelists) can imagine some situations where encryption in Amateur Radio may be justified.
This panel discussion justifies a full transcript of the discussion to be published in a future issue of Zero Retries.
A Few Takeaways from ZRDC 2026 and Pacificon 2026
One suggestion that surfaced at ZRDC 2026 is that the phrase Software Defined Radio has been transmogrified into near-meaninglessness. Mostly SDR is associated with the small Software Defined Receivers, so trying to use SDR in conjunction with a transceiver is hard to get the true capacity of SDR technology across. Also, commercial manufacturers state that their radios incorporate SDR, but offer users of their radios no meaningful way to change the functionality of the radio per their preferences. FlexRadio is the sole exception to this. It was suggested that a new explanatory phrase for SDR is needed for Amateur Radio such as AnyMode Radio. That has enough merit for future thought.
Another suggestion mentioned at ZRDC 2026 was that small Amateur Radio manufacturers are increasingly having trouble getting hardware manufactured to be sold in the US, with tariff issues, and now FCC certification issues. It was suggested that perhaps there should be an informal “Small Amateur Radio Manufacturer’s Council” be organized to be able to share best practices and provide peer support, such as sharing which US based electronic manufacturers and fulfillment providers are “friendly” to small Amateur Radio manufacturers. One surprising company that a number of small Amateur Radio manufacturers are using for fulfillment of their products in the US and internationally - DigiKey.
Version 2.0 of FreeDV RADE is in development and the biggest news is that the bandwidth of FreeDV RADE on HF SSB will be < 1 kHz. Currently it’s 1.5 kHz. In addition, it’s expected that the audio quality will be improved.
ScaleRF is in imminent danger of shipping QuadRF tiles to crowdfunding backers, likely in early November. I was given an impressive demo of their first “kit” to “view RF energy”. When it was used to “look down” the long hallway of Pacificon, there was a persistent “bright spot” of 5 GHz RF energy, which turned out to be a working 5 GHz radio at the AREDN exhibit.
Hams.com made its debut at Pacificon. It’s a sprawling project but it has a lot of promise. It is available now for membership. There are so many features that anyone will find something useful and interesting in Hams.com. I plan to join and dive in, and do a full review in a future issue of Zero Retries.
The IP400 AMNC is projected to be available in 2027-Q1.
ARRL announced it will hold its 2028 National Convention in conjunction with Pacificon 2028. As Tina stated, we hope to bring ZRDC back to San Ramon / Pacificon in 2028. We’ve already reserved the same room (Trinity) at the Roundhouse for Pacificon weekend in 2028.
To support foxhunting, Justin Giorgi AI6YM unveiled the Minimum Viable Yagi Kit for $26. You get the idea immediately from the photograph - some tape measure strips, a piece of PVC pipe, and some 3D printed parts. I think it’s genius!
It wasn’t exactly secret, but Glen Popiel KW5GP confirmed and provided details at his presentation at ZRDC 2026 that he’ll be authoring a series of small books (booklets?) on building Amateur Radio projects based on inexpensive, but very capable microcontrollers. Expect a number of such books to be available as fast as KW5GP can write them. The book section at your local Amateur Radio retailer will soon look a lot more Zero Retries Interesting.
Ben Faershtein K06CNT who was a fellow exhibitor at Pacificon 2026 for Bay Area Mesh showed me a Lilygo T-Beam BPF - for 144 - 148 MHz:
LoRa receiving and sending SX1278 BPF(144-148 MHZ)
Now Meshtastic / MeshCore is now feasible on 2 Meters / 144-148 MHz, exclusively for Amateur Radio (no confusion about licensed / unlicensed)!KO6CNT also told me that a Meshtastic developer developed and is testing out a public / private key authentication system for Meshtastic. I asked him to put me in touch with that developer - that would be very cool to implement in future Amateur Radio data communications systems.
When I mentioned the above to Bruce Perens K6BP of Hams.com, he told that he had implemented a similar capability as an element of Hams.com, but I’ve forgotten the particulars of it, but what he described sounded plausible, workable, and practical to me at the time.
Kay Savetz K6KJN’s slide deck presentation for Pacificon 2026 - What’s New At DLARC — Pacificon 2026 was a hoot! I hope someone recorded a video.
I had a long chat with Eric Anderson AF7YQ of MorseNexus, expressing my admiration for his company’s products as the first company to treat Morse Code / CW as “just another digital mode” instead of solely a manual human skill. A MorseNexus DitStorm Cypher “modem” is on my “eventually purchase” list. AF7YQ told me that there’s plenty of expansion capability in the DitStorm Cypher and he’s experimenting with adding other digital modes to it.
AREDN just keeps getting better, and better. Some recent improvements:
Units that AREDN supports, that have multiple radios, can now use AREDN mesh on all the radios. Previously, AREDN only worked on one radio (but the other radios could do Wi-Fi).
Mesh stations can select the best PtMP to connect to.
For AREDN users that have issues about encryption used on Internet such as HTTPS passing through their node (using Amateur Radio spectrum), you can now set your node to not pass Internet traffic.
There are now many “scratch your personal itch” helper apps for AREDN, the vast majority of which were developed by vibe coding / AI-assisted software development.
The AREDN presentation from Pacificon 2026 is public - https://wiki.bayareamesh.us/images/2/24/AREDN_2026.pdf.
Apropos of nothing? Or perhaps something? Elecraft, FlexRadio, and Yaesu were exhibitors at Pacificon 2026. Icom and Kenwood, which both have had new radios that debuted in 2026 to show off, were not present at Pacificon 2026.
ARDC was also not an exhibitor at Pacificon (I was asked several times if ARDC was at Pacificon 2026).
It was notable that the nomadic W1AW/6 station agreed to add FreeDV RADE as a supported mode for guest operators to use - that is significant progress in FreeDV RADE to become more “mainstream” in Amateur Radio.
Please direct comments / feedback about this article to the Zero Retries email list with the hashtag #ZR0267. Paid subscribers can comment directly on the web version of this issue.
Breaking: xara - a VARA-compatible Modem for Linux
By Steve Stroh N8GNJ
Disclaimer - I have no involvement with this project - no early notice, no involvement in its development and testing, no hint who x0rro is… nothing.
I was initially notified about the existence of xara on 2026-10-27 by a longtime Zero Retries reader who prefers to remain anonymous.
Then, looking for some video entertainment during lunch, I discovered that Craig Lamparter KM6LYW of DigiPi (and ZRDC 2026 presenter) fame was aware of xara and was already testing it in a prototype future version of DigiPi:
Informed Comment, and Some Testing by KU0HN
Then I got a quick email from Ben Kuhn KU0HN (Founding Member 0005):
I came across XARA today. It appears to be compatible (over the air) with VARA and VARA-FM. It also ditches the libraries from 1998, as well as the GUI-based application model, so it works as a proper service. Seems like Linux only for now, but it’s open, and MIT licensed, so ports to other *nix based OSs should be trivial.
I’m going to try it out as soon as I find a few minutes.
Later update from KU0HN:
I did get a chance to do some limited testing this week. I was mostly focused on compatibility and CPU utilization. VARA on Wine is a pig, since it is dragging along Wine, and Windows dependencies (VB6) from the 1990s. There is also no good way to run it headless, so it brings the GUI and waterfall rendering along whether you want it or not.
My test was to swap out the VARA-FM and VARA modems on my linBPQ BBS and Winlink gateway. The BBS is a SFF desktop with a AMD Ryzen 5 PRO 2400GE. It uses a digirig-lite and Kenwood TK-790 for VHF and an IC-7300 for HF. I then connected from a client running PAT and the official VARA modems to ensure compatibility. The radio on that machine is a TS-2000 with a digirig mobile. The actual test is to upload and download a 10kb binary, uncompressable attachment using Winlink. This type of activity is where I see the most link failures in the real world, and it’s what I often use for a stress test when working on tncd as well.
The first tests (VARA-FM) did not go well. I encountered a bug that caused the link to drop mid-session. I reported the bug yesterday and a fix was released this afternoon. The root cause of the issue was the CM108 audio codec on the digirig lite. It’s sample rate wasn’t consistent between tx and rx. The code had to be updated to account for the difference.
The second set of tests went much better. Here are my results for both the HF and FM tests. One important note about throughput, though. I did set the audio levels for HF, but the test was over the air, so speed did adjust, as expected due to QRM and noise on the channel. I did see the modem up and down shift throughout the transfers as it should. On VHF, I didn’t take the time to perfectly set the deviation. I was more interested in testing compatibility and functionality. Despite that, there was at least one instance of stellar performance with xara, beating out the vara control. I guess even a broken clock is right twice a day.
Mode Direction Session Max rate Payload Gateway CPU Client VARA CPU
VARA FM upload 3:37 4,040 bps 0.38 kbps 22.5% 10.0%
VARA FM return 2:25 1,188 bps 0.56 kbps 17.8% 12.7%
xara 0.1.2 upload 3:24 2,390 bps 0.40 kbps 12.1% 10.1%
xara 0.1.2 return 0:33 16,932 bps 2.48 kbps 8.4% 13.9%
Mode Direction Session Max rate Gateway CPU Client VARA HF CPU
VARA HF upload 2:18 5,817 bps 53.0% 14.8%
VARA HF return 2:41 1,203 bps 54.3% 17.1%
xara HF upload 2:18 3,877 bps 5.3% 15.1%
xara HF return 2:25 2,423 bps 6.0% 17.3%
Needless to say, I’m extremely happy with the CPU utilization difference between the two modems. It’s also very obvious that the audio was set up right for HF compared to FM.
Prior to implementing VARA, both of the BPQ machines I sysop were on arm SBCs. They had fewer moving parts, tended to be more reliable and use significantly less power than the small form-factor desktops I’m using now. This is especially important for the remote site where I have to use snowshoes to get there for a few months out of the year.
My thanks to KU0HN for the second (after KM6LYW) actual testing of xara.
Once Upon a Time, I Imagined an Open Source Equivalent of VARA
Longtime Zero Retries readers might recall that I advocated for a potential open source equivalent of VARA beginning in Zero Retries 0004 - 2021-08-06. In the article The VARA FM Solution, in that issue, I said:
Yet another disclaimer - what I’m proposing below is (as far as I’m aware) entirely in my imagination. I think it’s feasible. I don’t think it will be easy or fast.
I think that a solution to the VARA FM Problem that I posit in the previous article would be to reverse engineer the technologies that EA5HVK has implemented in VARA FM, and implement equivalent technologies into an Open Source equivalent of VARA FM. Ideally, the Open Source implementation will be interoperable with VARA FM.
Oxford Languages, via Google, gives one definition of vara as “a long spiked lance used by a picador” (bullfighter). I’m guessing that’s the meaning of “vara” that a Spaniard such as EA5HVK would choose.
Thus, for sake of discussion, let’s call a potential open source equivalent of VARA FM “Pointy Stick”. (That was the most lighthearted equivalent to “long spiked lance” that I could think of.)
In Zero Retries 0006 - Something of a Plan for Creating RAMA, Greg Hancock Greg Hancock AE7EL chimed in on my observations about VARA:
2. My suggested name for the open source version of VARA: “RAMA”. It means “stick” or “branch” in Spanish. The first definition of vara in my Diccionario esencial de la lengua española is “rama delgada” (slender stick). RAMA also has some interesting meanings in Hindi/Sanskrit.
I was more than happy to adopt the name “RAMA”, versus “Pointy Stick” for the name for such an open source equivalent of VARA FM as I proposed, and AE7EL “seconded”.
But… my “plans” for instigating, or helping to create, an open source equivalent for VARA never progressed beyond this 2021 series of articles. In the succeeding years, I mentioned VARA FM regularly as a great example of technological innovation in Amateur Radio, and application of new technologies and techniques (and newer thinking) about “old problems” such as going beyond 1200 bps using Audio Frequency Shift Keying and a typical VHF / UHF FM radio only microphone input and speaker output which is problematic for higher speed data2.
VARA is best known for the VARA HF variant, for use on HF frequencies, where VARA’s use of Orthogonal Frequency Division Multiplexing (OFDM) works well to compensate for the fades, noise, and other unique issues of the HF bands that impact the reliability of data communications. Thus I’m well aware of the preponderance of VARA HF, but most of my writing has referenced the VARA FM variant for use on VHF / UHF for higher speed (than packet radio) data communications.
In Zero Retries, I’m primarily interested in, and write about VARA FM because when I began writing Zero Retries, progress on higher-speed data communications in Amateur Radio had generally stalled with the exceptions of AREDN (on microwave bands), New Packet Radio (which didn’t seem to get much widespread adoption), and the decades old Icom D-Star Digital Data mode that was (then) only available in the Icom IC-9700.
In contrast, VARA FM used a normal 12.5 kHz VHF / UHF FM channel and achieved reliable data communications at up to ~25 kbps, well beyond what’s possible with 9600 packet radio, even when adding Forward Error Correction.
Another primary point of admiration for VARA FM is that EA5HVK made VARA FM usable on any VHF / UHF FM radio - portables, mobiles, and especially radios that did not have a flat audio connection - only microphone / speaker connections…
and he made these two modes of VARA FM - up to ~12 kbps on radios with only microphone / speaker connections, and up to ~25 kbps on radios with flat audio connections interoperable on the same channel3. To date, that has never been possible with packet radio 1200 bps AFSK and 9600 bps FSK. Those two modes are incompatible - a 1200 bps AFSK system does not recognize 9600 FSK transmissions, and vice versa. Thus attempting to use those two modes on the same channel inevitably results in collisions and wasted channel time. But VARA FM “narrow” and VARA FM “wide” easily coexist and interoperate on a single channel.
Why an Open Source Version of VARA FM is Wanted / Needed
With VARA FM having been proven to work so well on VHF / UHF, there are two fundamental reasons why lots of folks feel an “open source” implementation of VARA is needed.
The first is that Windows has become problematic for dedicated / standalone applications such as VARA FM. For many, Windows has become a nightmare to try to maintain as a “just works” appliance for a dedicated use such as VARA FM4. Functionally, VARA FM is the equivalent of an old-school dialup modem. It’s supposed to “just work” to transport the bits between two radios, including being set up as a remote relay node (in packet radio, a digipeater) with minimal or no maintenance. In such use, the PC is generally not connected to Internet, and thus is in little danger from malware / hacking, and thus doesn’t require regular software updates.
Such a usage scenario no longer possible with current versions of Windows that cannot be prevented from unpredictably attempting to do software updates, or “phoning home” or display a popup message, all of which can prevent reliable operation of the VARA FM application.
The second reason is that many people want to “appliance-ize” their use of VARA FM to run on small, embedded computers such as Raspberry Pi to create a dedicated VARA FM appliance and use Linux. That’s become less of an issue with the rise in price of the latest, most capable Raspberry Pi units such as the Pi4 and Pi5, and the availability of “appliance” PC units.
And a factor about VARA FM being closed source and available only for Windows is that a lot of folks prefer / require open source software for their Amateur Radio operations. That’s a philosophical argument. I’m in complete agreement with EA5HVK’s decision not to make VARA FM open source, and make it available only for Windows. It’s his creation, and thus such decisions are his to make. That said, over the years, EA5HVK has received many requests within Amateur Radio for a version of VARA FM that’s open source / usable on Linux and has declined such requests. Thus, there is pent-up demand for an open source equivalent for an “open source” VARA FM.
So, now there is xara.
Q&A With xara’s Creator x0rro
It was apparently suggested on Reddit that I would likely write an article about xara, and “x0rro” proactively reached out to me via email. As you could imagine, I had some questions, and these are the ones that x0rro answered on the record. x0rro prefers to use all lowercase, and I preserved that in their answers.
N8GNJ:
You made a curious distinction about “registered mode”. If there’s no association between VARA and xara, and you’re doing this from scratch, why not just make “registered mode” the default? That said, doing so is a nice gesture to EA5HVK to subtly encourage people to pay him his license fee, or am I missing something?
x0rro:
out of respect for EA5HVK’s engineering and to honor his original license as much as possible, while developing an interoperable implementation. i sincerely hope that every person who uses the registered feature purchases a VARA license. a tremendous amount of thought and care went into its design and its creator deserves that recognition.
N8GNJ:
You said “xara-monitor … probably won’t run on a pi”. If you’re referring to a pretty typical Pi3B+ that’s used for a lot of embedded applications, understood. But is your statement true even for a Pi5 with, say, 2 GB RAM? If so, wow that is a demanding app.
x0rro:
heh you got me there. truth is i just haven’t focused as heavily on monitor as the rest of xara. the expensive part is worth a post of its own... what i’ll say is i hope someone benchmarks it and reports back. and maybe in the future: FM support in monitor and details on that technique.
N8GNJ:
Are there any exceptions for interoperability? For example, one limitation I’ve heard people complain about is VARA only allows a maximum of two digipeaters, and that seems an arbitrary limitation in larger networks (which seem a bit more likely with xara being able to be embedded into lots of apps).
x0rro:
i actually discovered a few VARA bugs and work around those, but for the most part i’ve kept xara exactly as VARA. i like to think of it as the reference implementation from which a thousand forks are launched.
N8GNJ:
How did you… or did you… implement the speed upshift / downshift capability of VARA? In following the discussions of Mercury, that was a significant effort to implement that capability.
x0rro:
very carefully. the protocol is extremely sophisticated. during a transmission the receiver constantly monitors the channel, and then when it ACKs the packet, it sends back a level flag. this tells the transmitter to go up a level, down a level, up 2 levels, 3, 4... the sender also gives a hint based on how deep its queue is. like i said, the engineering that went into this protocol is very impressive.
N8GNJ:
In creating xara, did you see any potential for going beyond VARA’s limitations, or was your primary goal to, essentially, make a version of VARA for Linux? Do you envision xara becoming a superset of VARA, keeping “backwards compatibility” with VARA, but when xara to xara, be able to do additional functions / capabilities? (I’m guessing that’s going to happen pretty quickly with forks of xara.)
x0rro:
i have my ideas, but i don’t feel it’s my place to do so in this project. there are things i wish VARA did better or differently, and the truth is if i improved it i would start from the ground up, taking things that worked well but applying my own principles to what makes a good digital mode. xara is a reference: this is what VARA does and how it works. use it, learn from it, improve it. that’s what ham radio is about.
N8GNJ:
In the US, the Part 97 regulations state:
§97.309(a) lists the specified codes: Baudot, AMTOR, ASCII, and others. It also allows any technique whose technical characteristics have been publicly documented, such as CLOVER, G-TOR, or PacTOR.
While it’s arguable that EA5HVK didn’t do a very good job of “publicly documented” specifications of VARA, at least he did something.
You don’t seem to have provided any “publicly documented” specifications, only the reference to compatibility with VARA, and, of course, open source code. Any plans to add some “publicly documented” specifications or ????
x0rro:
the source is the documentation :)
N8GNJ:
Any future plans for xara other than making it available for others to test and report bugs and make it solidly interoperable with VARA in a version 1.0?
x0rro:
if we can reach perfect interoperability to VARA, to the point that VARA could never tell, i will be happy. in my opinion VARA is a legacy protocol at this point, and closed source thinking is a legacy way of thinking. i hope people take what’s good from VARA and eventually move on to newer, better, more modern and open protocols.
…
The implications of xara “versus” VARA have yet to emerge in public (there’s been no public statement from VARA’s creator about xara). But of course, “armchair lawyers” have emerged with some pushback on public forums about xara being “reverse engineered” from VARA. Addressing such viewpoints, x0rro stated (on Reddit thread):
you can’t copyright a protocol, only its implementation. to develop xara i observed VARA’s behavior and developed a spec and a test suite. then i implemented against that spec until the test suite passed. then i ran xara exhaustively against VARA, systematically testing every mode and failure condition, to ensure behavioral equivalence.
this is an independent implementation of the same protocol VARA supports and does not share any code with VARA.
In support of that position, over the years of writing Zero Retries, and especially discussing the possibility of an open source workalike of VARA, I’ve heard from a number of software developers that they’ve used AI to reverse engineer application software into a specification that can then be used to develop work-alike or compatible software. One said (paraphrased):
What you’re describing as a big project, to generate a detailed specification for how VARA works, and then build a new application from scratch to interoperate with, or work very much like VARA (same capabilities, speed, etc.)… is just a normal few day’s work for me in reverse engineering various radio protocols. This is now just a normal phase of radio engineering work.
xara, in Many Respects, is a Non-event
In many respects, I view the emergence of xara as largely a non-event. In the bigger picture of usage of VARA in Amateur Radio, I don’t expect the existence of xara to negatively impact the usage of VARA.
One primary reason for this perspective is that the vast majority of Amateur Radio users, use and prefer using Windows. They understand it, and despite its many flaws, it’s “the devil they know”. Thus VARA, running on Windows, is preferred over xara running on Linux.
Another significant group of VARA users are participating in formal, organized Emergency Communications activities. Such groups have a strong preference for software that is well understood and well supported (by the vendor, or by peer support). Thus EMCOM users of VARA will likely choose to use the “official” versions of VARA (on Windows), pay the VARA license fee (many groups arrange discounted license fees), and thus be able to operate VARA at its full capabilities so they can fully interoperate with the rest of their Emergency Communications group.
As for additional users beginning to use xara “instead of VARA”, the vast majority of those potential VARA that may be viewed as having been “lost to xara”, weren’t actually potential VARA users. It’s my perspective that the majority of the potential user base for xara are those who have a strong preference, or outright requirement, that what they use on Amateur Radio must be open source, not proprietary.
There’s another portion of potential xara users who may not necessarily prefer or require open source software, but they do prefer or require software that runs on Linux rather than Windows or MacOS.
As for those VARA users who prefer not to pay VARA’s license fee to unlock the maximum performance tiers of VARA, many are just cheap and they’re content to use the free / basic / slow tier of VARA (which works better in a lot of ways than AX.25 packet radio at 1200 bps). They were never going to pay for a VARA license, so those are not “lost” sales of VARA licenses.
The Existence of xara Could Grow VARA Communities and Ecosystem
Thus, it’s my perspective that sales of VARA usage, or purchase of VARA licenses are unlikely to be significantly (negatively) impacted by the emergence of xara.
In fact, I expect the usage of VARA to actually be improved by the existence of xara. Now that the Open Source advocates have the option to use xara and the advanced (compared to Amateur Radio Packet Radio) capabilities of VARA, I think that the existence of xara will actually increase the use of VARA on Amateur Radio, such as:
xara on Linux / Raspberry Pi is a more realistic option for VARA digipeaters in locations (towers, mountaintops) where an unattended Windows computer just isn’t a realistic, reliable option. A well-engineered Raspberry Pi (power protection, watchdog circuit, etc.) is generally a better option in such scenarios (there are exceptions).
VARA running on a Windows box wasn’t really a realistic choice for a typical NewTechHam as they generally prefer Linux because it’s free and open source. Inexpensive starter solutions such as DigiPi can now offer xara as just another digital mode in DigiPi and they could then add to the local VARA activity and infrastructure for more widespread VARA usage.
Other Amateur Radio data “appliances” such as (purely speculation on my part) the OpenTNC could, like the DigiPi, increase the local VARA activity infrastructure for more widespread VARA usage.
xara digipeaters, DigiPi users, and OpenTNC users can serve to grow VARA usage in a community (where there was minimal or no VARA usage). Inevitably as such a “VARA community” grows, there will be those users who prefer using Windows, and those users are potential VARA users and license purchasers. A rising “VARA / xara tide” will inevitably increase the potential user base / license purchases of VARA.
I, for one, welcome the emergence of xara, as a Linux option for making use of VARA technology. I think that the lack of such an option has, in a number of ways, held back the growth and wider usage of VARA.
I think that xara on Linux will attract NewTechHams to explore VARA and find creative ways to use it to grow and enhance local VARA usage and the overall VARA ecosystem.
Please direct comments / feedback about this article to the Zero Retries email list with the hashtag #ZR0267. Paid subscribers can comment directly on the web version of this issue.
AnyRadio - Receive AnyFrequency / Receive AnyMode…
And, correspondingly, transmit on AnyFrequency using AnyMode
By Steve Stroh N8GNJ
Software Defined Radio technology has not only enabled being able to receive on nearly any frequency and any band… but most recently, any mode.
This will be a short… terse… article to mention this bright (?) idea that occurred to me in the aftermath of ZRDC 2026 and Pacificon 2026.
I’ve previously explained that with the breakthrough of the ability of ka9q-radio to “parse out” the I/Q stream of a Software Defined Receiver into as many virtual receivers (channels) as you can support with a chosen host computer (Raspberry Pi 5 = x channels, a multi-blade server perhaps 100x), all being received simultaneously (not sequentially scanned - simultaneous, virtual receivers).
With that capacity, an Amateur Radio can receive anywhere, such as monitoring every 12.5 kHz channel in the 2 meter / 144-148 MHz band. For Packet Radio, this means that you can hear a transmission on any 2m channel.
And, more importantly, that means that when you transmit, you can use any channel to transmit and you’ll be heard by any station (in close proximity) that’s similarly equipped.
This is a key concept of my SuperPeater concept - not only can you use any frequency / channel, increasingly, you can use any mode.
I arrived at that insight when I heard that there are now many Software Defined Receiver software applications that now incorporate receiving M17 and FreeDV RADE in their standard configuration. As supported modes, a transmission on any frequency within the capability of the software / hardware (especially HF, which is easily covered by a single SD receiver unit), M17 and FreeDV RADE “just work”.
This trend was emphasized by the OpenTNC’s ability to recognize not just 1200 bps AFSK transmissions and 9600 FSK transmissions, but also the two different variants of Forward Error Correction, and various other aspects of packet radio that in previous, less sophisticated packet radio hardware and software would have to be specified in advance and used on dedicated channels and carefully coordinated. But now, OpenTNC has enough computer power and sophistication to do simultaneous decoding.
Then… combine AI assisted software development that could result in a “SuperRadio” that not only incorporates the ka9q-radio capability to virtualize individual receivers for an entire band… but, increasingly, the ability to decode / support any mode. To an AI, adding another mode to be supported / decoded is “just another library, or code base” to be incorporated into the application.
So, for SSB (or AM, or FM) or or M17 or FreeDV, not only could you be decoding a received signal to an audio stream for listening, a SuperRadio could be decoding / transcribing it into a text display. Same for Morse Code / CW, or RTTY, or JTTY, or FT8, or Mercury, or Modem73, or x, or y, and z.
Yes, each new mode being added / simultaneously decoded takes an incremental amount of computing power (and CPU cycles), and memory to be able to simultaneously decode all modes, all channels in a band. And thinking more conventionally, I would agree with you that there’s a practical limit to such an ambitious “SuperRadio”.
But what I’m seeing happen is that AI software development isn’t just “accreting” each new capability that is requested to be added - it’s “thinking differently” in how to accomplish the task you’re requesting.
For example - Apple’s M series processors combine a number of processors, graphics / AI processors, other processors optimized for various compute functions on the same die, all of which have multiple cores, variable clock cycles depending on loads (to be more power efficient), and all with shared RAM. Most applications don’t take advantage of anywhere near that amount of aggregate compute power - the app has to depend on the MacOS and skillful use of Apple’s Application Programming Interface to make effective use of that aggregate compute power.
I’m imagining (I are not a software engineer…) that an AI software development assistant, when tasked with combining ka9q-radio and a number of various mode decoders, and full knowledge of how to efficiently use Apple’s M series processors, could create a much more efficient software package than a human would imagine. It could probably figure out what the common elements of decoding M17, and Modem 73, and JTTY, 9600 FSK packet radio, and CW, and whatever other mode you want your system to decode into a unique, efficient software package that… just works, more efficiently than any human software developer could possibly imagine. Simply because humans don’t develop software the same way an AI develops software. An AI might even decide that it’s more efficient to develop a single monolithic app to perform this dedicated function than trying to build an app that suffers from the overhead of a multitasking operating system.
Such a fantasy application may well beyond the capabilities of a Raspberry Pi 5 maxed out with 16 GB RAM and an M.2 SSD (still reasonably priced at ~$300 + SSD), running a 64-bit Raspberry Pi OS (Linux)…
But, I bet this would be within the capability of a future Raspberry Pi 6 that we’ll inevitably see in a few years. In the meantime, blade-based servers are being retired and are relatively cheap for the development of wild ideas like this.
We won’t see this kind of capability from a “mainstream” radio manufacturer because such a system does to support their business model that radios are designed to support only a few modes, and supporting additional modes / bands / receiving multiple frequencies requires a more expensive, sophisticated radio.
But that’s not necessarily the case when you factor in the collision of true Software Defined Radio technology, AI assisted software development, cheap compute capability being substituted for dedicated radio hardware, and especially open source libraries for the many and varied digital (and analog) modes. Soon enough we’re going to see FreeDV RADE on an 850 Hz on a 10 meter SSB transceiver operating at 25 watts be a work as a “voice / data intercom via radio” that operates reliably over an entire region.
You read it first in Zero Retries.
Please direct comments / feedback about this article to the Zero Retries email list with the hashtag #ZR0267. Paid subscribers can comment directly on the web version of this issue.
ZR > BEACON
By Steve Stroh N8GNJ
Short mentions of Zero Retries Interesting items.
New TAPR Product - MVR GPSDO
MVR GPSDO is a low-cost GPS disciplined oscillator
Low Cost GPSDO
The MVR (“Minimum Viable Reference”) GPSDO is a low-cost GPS disciplined oscillator intended primarily for HF radio applications. It has a 10 MHz output as well as three additional outputs that are programmable to frequencies between about 200 kHz and 200 MHz (operation outside these ranges is possible, but not guaranteed). Thus it can serve as an external clock source for SDRs such as the RX888, WEB-888, or KiwiSDR.The MVR is powered from a USB-C connector which is also used to access the configuration menu. Once the unit is configured, it can operate from a standard USB-C power supply; the computer does not need to be connected except when changing configuration. The antenna connector provides 3.3 volts to drive a GPS antenna. The outputs are square waves at about +10 dBm into 50 ohms.
The MVR’s long term accuracy approaches that of the GNSS satellite constellation, but its low-cost design goal means that its short-term stability is not as good as some other GPSDOs. To be more specific, its 10 MHz output wiggles from second to second by about 9 milliHertz. For applications below 30 MHz, this is usually lost in the noise. But frequency and phase noise scale with frequency, so at VHF or UHF frequencies, the short-term noise may become an issue. Other instruments are a better choice for such applications.
Another limitation of the MVR is that it does not have a “holdover” capability – if GNSS signal is lost for more than a second or so, the unit will lose lock and the frequency will shift significantly. However, with multiple satellite constellations available today, and the GNSS module supporting most of them, loss of lock should be very rare unless the antenna is severely compromised, or there is active GNSS jamming in the area – in which case you probably have bigger problems to deal with!
I found out about this unit at the recently concluded TAPR 2026 Annual (online) Meeting, watching the recorded video (which was privately shared with me).
Before deciding to offer this for sale, reportedly several testers did A/B comparisons with another popular GPSDO unit. The conclusion was that this unit handled most Amateur Radio use cases, and for only $100, it would increase the usage of GPSDO within Amateur Radio.
902-928 MHz Horizontally Polarized Omnidirectional Antenna Options
In his presentation - AREDN 2026 at Pacificon 2026, discussing his experience with 902-928 MHz AREDN units, Tim Wilkinson KN6PLV mentioned that horizontal polarization for 902-928 MHz AREDN worked much better (less interference) than horizontally vertically5 polarized antennas. A long time ago I became aware that horizontally polarized omnidirectional antennas do exist (not just a horizontal omni rotated horizontally… though two of them in parallel at 90 degrees might work…).
A brief web search engine query was useless. Thus I turned to Claude AI (my favorite at the moment), which said:
These three each meet all three criteria: they cover 902–928 MHz, radiate 360° in azimuth, and are horizontally polarized. Nothing directional is included.
1. TIL-TEK TA-950H: highest gain
Pattern: Omni-Directional
Polarization: Horizontal
Frequency: 902 to 928 MHz
Specs: 9 dBi, 100 W, VSWR 1.50:1, N Type female, pole or clamp mount, 1524 x 203.2 x 50.8 mm, 6.3 kg
The listing shows a 360° figure and a 16° figure, with the labels swapped. The 360° is the azimuth (omni) pattern, and the 16° is the narrow elevation beam you’d expect at 9 dBi. It doesn’t mean the antenna is directional.
2. PCTEL BOA8905HNF: best all-round commercial unit
Pattern and polarization: Omnidirectional, 890 - 960 MHz, 5 dBi, Horizontal, 50 W
Build: N-Female, UV stable fiberglass, 4.26 lbs, 3.5” OD x 26.8” H, wind rating 125 mph
PCTEL markets it for ISM, private networks, and LoRa/LPWAN base stations.
One distributor lists availability at 4 to 6 Weeks.
3. W6OAL Nano Wheel (33 cm): amateur and budget pick
Specs: Nano Wheel 33cm - 2oz, 6.5” dia., 902-928 MHz, priced at $70
Pattern: horizontally polarized omni directional radiation on the horizon with a wide vertical beam width of +/- 35 degrees
Good for 33 cm SSB/CW, beacons, rover work, or anywhere small size matters.
The TA-950H gives the most range toward the horizon. The PCTEL suits a site with users at varied distances and heights. The Nano Wheel is the cheapest and smallest.
Sources:
W6OAL antennas, at a glance, look reasonably priced and well-suited for Amateur Radio or unlicensed radio experimentation.
AREDN 4.26.10.0 Release
Major Features
Memory improvements
Babel footprint reduced by 4 MB
2-4 MB additional memory improvement on 64M devices.
Support multi-mesh radios
For nodes with multiple radios it’s now possible to enable the various mesh modes on them simultaneously.
Support multi-station radios
A mesh station node can now configure multiple channels allowing it to automatically pick the best. Good for mobile nodes.
Improve channel availability
All hardware supported channel and bandwidth combinations should now be available. These can differ on different hardware, and only those actually supported will be shown.
Improve tunnel configurations
Tunnel configuration no longer includes IP addresses. Old tunnels will continue to work but new tunnels must be created between upgraded nodes.
New tunnels now default to a smaller MTU (Maximum Transmission Unit - 1280 bytes, the same as Tailscale) to improve compatibility with some ISPs, particularly cellular providers. Old tunnels are unaffected.
WAN improvements
A group of nodes now share the WAN available on just one of them.
WAN connectivity is monitored and only made available to others on the mesh if enabled and available.
Internet opt-out
A node can elect not to carry traffic to or from the Internet. Mesh-bound traffic is still routed through the node.
Mesh Tools
There’s now quick access to various tools from the mesh page.
New Devices Supported
Ubiquiti Bullet AC (2WA)
Ubiquiti NanoBeam 5AC Gen1 (WA)
AREDN just keeps improving and getting more capable. Kudos to the AREDN team, including (and especially) the Evangelists who keep… well, evangelizing AREDN including at big events like Pacificon 2026. Now that ZRDC 2026 is (nearly) in the rearview mirror, I can’t wait to get some of the newer AREDN-compatible radios on order, including 902-928 MHz units.
Omarchy - Linux GUI That Looks Like MacOS
“Friendly” Windows (or Mac) like desktop / graphical user interfaces on Linux has had a checkered history. There have been some notable, and noble attempts such as Ubuntu, Linspire, and System 76 with Pop!_OS.
Now there’s Omarchy:
Linux used to be a chore to setup, difficult to debug, and full of confusing upfront choices. Omarchy solves all of it with a lightning fast installation, agents that debug all issues, and fantastic defaults that give you a fully functioning system that looks amazing out of the box.
Oma is for omakase, chef’s choice: we pick the tools and tune the details, so you can get straight to work. But this is your computer. You’re free to change everything.
Behind it all is the Omarchy Doctrine: ten principles for uniting the nerds, welcoming the agents, and building the perfect computer. We’re not there yet, but we can fix everything now.
Omarchy seems to have some significant momentum behind it, including some significant funding and longer-term funding commitments.
The goal of Omarchy, as I understand it, is to replicate, on Linux, the usability, stability, and the consistency (ha!6) of MacOS, not just on “PC” hardware, but also on Mac hardware (which is arguably, some of the best, especially in the M series processor generation.
So, apparently, now we can try Omarchy on our existing Mac hardware to see for ourselves:
Try Omarchy
Omarchy inside Apple’s Ecosystem.
Try Omarchy is a Mac app that runs stock Omarchy in a fast virtual machine deeply integrated with macOS. Use it as your daily driver, or give Omarchy a try and migrate to a native install. Integrations include Apple’s universal clipboard, AirPods, Touch ID, the Retina display, Super shortcuts, Mac clipboard, audio, camera, battery, and a shared folder. The official Omarchy Mac image is used, so it behaves and updates like any other Omarchy install.
That… would be interesting to run something other than MacOS. Given how fast Apple is upgrading their systems… they just released the M6 processor, and I’m still using a laptop with an M1, I’m guessing there’s going to be a lot of perfectly good M series units coming onto the used market at reasonable prices as folks upgrade to newer, faster M series units. With every major update, more “legacy” Macs get dropped off the new OS compatibility list. The few remaining Intel Macs, including my Mac Mini in my office finally got that bad news with the latest MacOS version.
Amazing Open Firmware for the Xiegu X6200
Peter Marks VK3TPM on his blog:
Icom radios are great but the firmware rarely gets updated. I’ve been making my own user interfaces by making software that talks to them but this morning I grabbed some amazing open firmware for my Xiegu X6200 from https://openx6x00.org
Amazing improvement over the stock Xiegu software. A great thing about this is it lives on a microSD card and if you remove the card the radio boots up as it was.
I joined the MRARC 80m net using the radio and got good reports running 10W when normally I run 100W. Just goes to show it’s all about the antenna. Here’s some bits of the net including another Xiegu station running a G1M that sounds excellent.
This video was made using the built-in screen recording feature. I then connected to the radio over its built-in web server and downloaded the video files.
Zero Retries readers have been telling me about Xiegu radios being able to be modified with various firmware “hacks”, but this is the most comprehensive that I’ve seen. I guess Xiegu deserves to be added to the category of HF radios that can in fact be substantively modified by users in ways that the company didn’t imagine when they shipped the unit.
Kudos to Xiegu, and VK3TPM!
Please direct comments / feedback about ZR > BEACON to the Zero Retries email list with the hashtag #ZR0267. Paid subscribers can comment directly on the web version of this issue.
Request To Send
By Steve Stroh N8GNJ
Editorial, Commentary, and Occasional Digressions
Zero Retries 0267 is Delayed and “planned to publish on Saturday”
As soon as this publishes, the evidence of that misstatement will be deleted.
Sorry for that misleading bulletin, dear readers, and forcing you to go an extra week without your Zero Retries fix. This week Tina and I were still playing catch-up on our lives at home. I was feeling (and apparently looking, and acting) harried on Saturday, and Sunday, and Monday… and Tina convinced me that I could take a week off post ZRDC 2026 (and she wanted a few more days to work on her column). Thank you to those of you who reached out mid-week if everything was OK.
Long time reader Rob Salsgiver NR3O, when he received my note that Zero Retries 0267 is Delayed:
So does that make this edition “1 retry”? 😂🤣
to which I replied:
Touche! Good one!
3700+ Email Subscribers!!!
The sole, reliable, objective “metric” of the popularity of Zero Retries is the number of readers who opt to receive email for each new issue of Zero Retries. I started Zero Retries in July 2021 and seeded the email subscriber list with something like 35 emails of family and friends and a few “you might be interested” folks. That was the only “seeding” I’ve done.
Since then, the growth of Zero Retries email readership is entirely organic - driven by word of mouth, mentions on nets, in articles, the occasional video or podcast appearance, in-person appearances like Pacificon 2026 and Hamvention 2026, a bit on social media (Twitter, back when it was usable, and recently Mastodon) and just a bit from cross-fertilization within the Substack ecosystem.
It continually amazes me when Zero Retries email readership ticks up over a new “century” mark every few months, this time going past 3700 email readers during Pacificon weekend.
Thank you, once again, to you many loyal Zero Retries readers. Without you, there would be no point in publishing Zero Retries solely for my own amusement.
NetNewsWire / More Realtime RSS Feeds - Solid Progress
My use of NetNewsWire RSS Reader has turned into a very solid, efficiency-enhancing productivity hack for trying to stay current with the amazing amount of Technological Innovation in Amateur Radio™️7 to report out on here in Zero Retries. Initially I was swamped with the amount of “backlog” reading through several thousand articles, but now that I’ve plowed through those (bookmarking way more than I’ll ever be able to report out on), it’s now the work of perhaps 15 minutes daily to get through these groups of new developments:
Amateur Radio Individuals
Amateur Radio Groups
Including several Google searches for various phrases such as Packet Radio (which have an RSS feed)
Amateur Radio Groups.io email lists (partial)
Things added to Digital Library of Amateur Radio & Communications (DLARC). Some days this can include several hundred new entries, but most can be skipped such as historic newsletters which aren’t Zero Retries Interesting.
Not yet caught up on:
Amateur Radio YouTube channels
The critical thing about all of those that I’m now following near-realtime (within a day or so) is that they all have RSS feeds. Sadly, some really interesting sources of information, including some Amateur Radio related Groups.io email lists, and Amateur Radio related YouTube channels, don’t have RSS feeds. One interesting aspect is that I’ve seen a number of creative and interesting new blogs / info websites (some of which admit to using vibe coding) that are individually created to scratch the author’s personal design preferences, but don’t include an RSS feed of updates.
And, of course, there are no RSS feeds for interesting posts on Facebook.
Within a year, this is something that I expect I’ll be able to turn over to a local instance of AI, not only to watch RSS feeds, but also watch, for example, GitHub repositories for significant updates and those websites that don’t have RSS feeds. And maybe, the most interesting Amateur Radio groups / pages on Facebook and Mastodon.
Speaking of Lots of Info From RSS Feeds…
I’ll defer most of what I found recently from NetNewsWire / RSS and catch up on that in a future issue of Zero Retries. This issue has been multiple days in preparation, and I’m very much looking forward to pushing PUBLISH (dammit!) and feel that weight lift from my shoulders.
Weekends Are For Amateur Radio!
One wonderful aspect of a ZRDC is a renewed surge of Amateur Radio energy to get active again on Amateur Radio. One immediate priority is to get one of my brand new NA6D OpenTNCs hooked up to my trusty Kenwood TM-V71A radio I use for data operations and play packet radio with a small group here in Whatcom County. No, I didn’t “win” an OpenTNC at ZRDC 2026 - I bought several when it became apparent how capable they were, and instead of struggling to resurrect one of my vintage TNCs to play packet radio, it’s going to be so much more efficient and fun to use the modern OpenTNC, with native USB (no serial port, unknown speed, parity, etc.).
And yes, very patient friend… Getting my loaned MeshCore unit finally on the air. That is way, way past time.
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 #ZR0267. 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 2025, 3rd 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 0267 was published on 2026-10-30. This issue was 16251 words.
Footnotes For This Issue
To see the relevant sentence for the footnote, just click the footnote number.
My thanks to Ren Roderick K7JB for catching this typo.
Problem for higher speed data because FM two-way radios apply “pre-emphasis” to microphone audio to the transmitted audio signal to improve the intelligibility of human voice. On the speaker audio, corresponding de-emphasis is applied prior to the received signal being sent to the audio amplifier and speaker. VARA FM is able to achieve higher data speeds using the microphone / speaker audio because it applies “audio shaping” (my understanding / terminology) to the audio signal as transmitted and received to compensate for the pre-emphasis / de-emphasis. 1200 bps Audio Frequency Shift Keying (AFSK) also works with microphone / speaker connections because its modulation is, in a word, “loose” (forgiving) enough to not be affected by pre-emphasis / de-emphasis.
The first implementation of a practical method that I’m aware of to operate 1200 bps AFSK and 9600 bps FSK on the same VHF / UHF channel without (or minimal) collisions between the two modes was discussed by Dave Platt AE6EO in his presentation about the OpenTNC project at Zero Retries Digital Conference 2026.
Obviously, it is possible for Windows to be customized fur such “appliance” applications such as medical devices, military applications, process control systems, etc., but only with special arrangement / licensing from Microsoft. Those versions of Windows are not available to the general public such as us Amateur Radio Operators.
My thanks to David Ranch KI6ZHD for catching this error.
One mildly maddening thing for us longer term Mac users is that Apple loves to change things up on the MacOS every new “model year”, whether such changes are needed or useful, or not. There’s many features added several generations ago that I still don’t make any use of. It’s like the “new style of tail fins every year” on 1950’s automobiles.
I use the phrase Technological Innovation in Amateur Radio so often in Zero Retries, and I don’t see it elsewhere, so my use of ™️ is purely humorous.