Zero Retries 0244

Steve Stroh

— 35 min read
Zero Retries 0244

2026-03-27

Zero Retries is an independent newsletter promoting technological innovation in and adjacent to Amateur Radio, and Amateur Radio as (literally) a license to experiment with and learn about radio technology. Radios are computers - with antennas! Now in its fifth year of publication, with 3500+ subscribers.

Steve Stroh N8GNJ, Editor

editor@zeroretries.net

Tina Stroh KD7WSF, Business / Conference Manager


tina@zeroretries.net

Ghost says this issue is too big for email clients? YES
Thus, it might be easier to read this in a web browser -
https://www.zeroretries.radio/zero-retries-0244

In This Issue...

I-Frame

  • Some Weeks Just Fly By
  • Not Publishing on Substack

AX.25 Version 2.2 - John Langner WB2OSZ

Introduction By Steve Stroh N8GNJ

FCC Bans New "Consumer Routers" - Steve Stroh N8GNJ

ZR > BEACON

  • AREDN Soon "Rebased" on OpenWrt 25.12
  • PyTNC Pro
  • GroundWave Project
  • The ISS Returns to S-Band: HamTV Now Transmitting Color Bars on 13 cm
  • Improving Open AMBE for D-Star
  • 44Net Connect Has a Limit of 8 Tunnels
  • Starlink Micro Stealth Introduction?
  • First Release Candidate For GNU Radio 4 (GR4)
  • UltraPeater
  • Introducing Hamstat.com
  • CDM Repeaters
  • Video - TRMNL X

Request To Send

  • Still Working on Getting Paid Subscribers Set Up In Ghost
  • Apologies to Zero Retries Subscribers on Comcast / Xfinity
  • Perhaps a Disruption Is Coming for the zeroretries.radio Domain...
  • Nice Mention of Zero Retries by Jared Crapo K0TFU
  • Hamvention Ho!
  • Weekends Are For Amateur Radio!

Closing Thanks

The Usual Administrivia

I-Frame

By Steve Stroh N8GNJ

Brief notes about this issue of Zero Retries.

Some Weeks Just Fly By

One story I worked on for most of a day this week ended up not being usable here in Zero Retries. But, it was still fascinating to work on the story and I don't regret the time "lost" doing so.

And... that's the story, for me, writ large about Zero Retires. This coming July will begin the sixth year of publishing Zero Retries (almost) weekly, and creating a new issue of Zero Retries every week is still as much fun, immersive, and addictive as it was at the beginning.

Thank you, Zero Retries readers for coming along on the ride.

Not Publishing on Substack

For new Zero Retries email subscribers that sign up for Zero Retries on Substack from a link, or the Substack app, or ??? and find yourself receiving Zero Retries from Ghost, the short story is that I'm no longer using Substack to publish Zero Retries. When a new email subscriber adds themselves to Zero Retries on Substack, I manually add that person to receive Zero Retries via Ghost (no big deal). Between Substack and Ghost, a typical week sees 3-10 new email subscribers to Zero Retries.

Please direct comments / feedback about I-Frame to the Zero Retries email list with the #ZR0244 hashtag.

AX.25 Version 2.2

By John Langner WB2OSZ

Introduction By Steve Stroh N8GNJ
John Langner WB2OSZ is one of my heroes of Zero Retries Interesting Amateur Radio. WB2OSZ is the creator of the Dire Wolf Software TNC, which has become one of... if not the cornerstone element(s) of Amateur Radio Packet Radio remaining relevant in the 21st century. Dire Wolf is remarkably capable software, most notably incorporating a unique, automatic mechanism for correcting received single bit errors without requiring a retransmission (Zero Retries!). This capability is largely "behind the scenes" of Dire Wolf operation, but WB2OSZ explained it in a 2018 presentation, where I was privileged to be in the audience and meet WB2OSZ.

Dire Wolf is interoperable with both FX.25 and IL2P Forward Error Correction (FEC) systems now in use in modern Amateur Radio that make Packet Radio much more usable and reliable, especially at (fussy) 9600 bps operation. Dire Wolf is also interoperable with a number of different speed tiers such as 2400 bps and 4800 bps, including interoperability with the NinoTNC. Dire Wolf includes many of the primary elements for being an APRS digipeater / IGate, and runs very well on Linux, Windows, and MacOS. It also runs on systems as modest as the Raspberry Pi Zero 2 W as evidenced by it being one of the primary modes of the DigiPi.

WB2OSZ is also a capable technical writer (Dire Wolf documentation is excellent). In the past several years has begun systematically documenting the many divergent enhancements of APRS since the development (decades ago now) of the first formal specification of APRS. Just one example of WB2OSZ's excellent technical writing is APRS Digipeater Algorithm.

When WB2OSZ shared a draft version of this article with me in December 2025, I was struck that I wasn't aware of the significant advantages of AX.25 Version 2.2 over Version 2.0. Given that decades that have now passed since the release of Version 2.2, it's valuable for this knowledge to be propagated more widely.

One might ask... why does this matter now, after more than two decades since this update? Simply, Amateur Radio Packet Radio operation continues in many areas. One example is that Packet Radio TNCs are now embedded within new, modern radios. Another example is that there are extensive Amateur Radio Packet Radio networks such as the 145.050 NET/ROM Packet Radio Network (operating in California, Nevada, and Oregon) and EastNet Packet in the Northeastern US. Not to mention Amateur Radio Packet Radio being used as "transport" for APRS and Winlink.

Given the significant advantages of AX.25 Version 2.2 that WB2OSZ explains, I hope that other AX.25 implementations will consider updating to Version 2.2. Most modern "Terminal Node Controllers" - TNCs such as the TNC4, and Kantronics 9612XE ("Easily upgradeable flash based bios/firmware") are now implemented in (updatable) flash-based firmware and not nearly as memory or processor power constrained as 1980's era TNCs. More modern TNCs are "KISS" TNCs and thus move AX.25 functionality into a host computer.

Lastly... WB2OSZ is perhaps guilty of "burying the lede" in his article in not referencing that Dire Wolf has implemented AX.25 Version 2.2. That capability is another element of why Amateur Radio Packet Radio networks using Dire Wolf generally work better than using legacy TNCs.

I had originally planned to "reprint" the entire article here in Zero Retries, but WB2OSZ completed the article and it's now publicly available - see below.

...

If you had to choose between using a mobile phone from 1984 and one from 1998, the decision would be obvious. In just fourteen years, mobile technology evolved from bulky, single-purpose bricks into compact, reliable, feature-rich devices. What’s easy to forget is that communication protocols evolve in exactly the same way — and Amateur Packet Radio is no exception.

Most operators know that AX.25 is the protocol that made amateur packet radio possible. What fewer realize is that there isn’t just one AX.25 standard. In fact, there are two major revisions, separated by nearly a decade and a half of real-world experience, experimentation, and lessons learned.

Packet radio exploded in popularity in the mid-1980s. New TNC manufacturers appeared almost overnight, and the hobby grew rapidly because everyone agreed to speak the same digital “language”:

AX.25 Version 2.0 — October 1984

But technology didn’t stand still. After more than ten years of operational use, network experimentation, and feedback from thousands of packet operators, [AX.25] was revisited and improved. The result was a significantly more capable and efficient protocol:

AX.25 Version 2.2 — July 1998
(Now more than 25 years old as I write this.)

Ironically, while the 1998 revision brought meaningful improvements, existing implementations rarely adopted it. Most manufacturers disappeared, and the few that remain don’t mention AX.25 2.2 support at all.

So, what changed? And why does AX.25 Version 2.2 offer such clear advantages over its 1984 predecessor?

Let’s take a closer look at what makes Version 2.2 the better protocol — and why you should be using it.

Read (download) the entire (PDF) article at:
https://github.com/wb2osz/direwolf-doc/blob/main/AX.25-version-2.2.pdf

WB2OSZ's article is an easy to understand, high level treatment of the differences between AX.25 Version 2.0 and Version 2.2, and a good explanation of how Version 2.2 is backwards compatible / interoperable with Version 2.0. A primary feature of Version 2.2 is that implementing it...

does not break any functionality or compatibility or interoperability with existing TNCs or existing Amateur Radio Packet Radio networks.

Highly recommended! My thanks to WB2OSZ for this article, and his many contributions to Amateur Radio in both his work on Dire Wolf and his writing.

Please direct comments / feedback about this article to the Zero Retries email list with the #ZR0244 hashtag.

FCC Bans New "Consumer Routers"

By Steve Stroh N8GNJ

This issue may become problematic, at least for a while, for Amateur Radio. We had it good for a long time with cheap, capable routers such as GL-iNet units (my personal favorites, supported by AREDN firmware). But there are some workarounds for Amateur Radio given we're a bit more savvy than typical consumers. It's quickly going to get confusing as the FCC makes no attempt to "de-conflate" the two functions - the actual Internet routing function in a household, and the Wireless Access Point function, that are almost always combined into a single unit. It will also probably become an amusing game of "whack a mole" as new "versions" of existing (currently approved) routers slip through the proposed new processes for approval of new units.

To answer a likely criticism in advance, I am not a lawyer (thus I'm not "armchair lawyering"), I am not an FCC "kremlinologist", and these views are offered as relevant to the Zero Retries Interesting Amateur Radio, not political, aspects of this issue.

FACT SHEET: FCC Updates Covered List to Include Foreign-Made Consumer Routers, Prohibiting Approval of New Model

Update Follows Determination by Executive Branch Agencies that Consumer-Grade Routers Produced in Foreign Countries Threaten National Security

WASHINGTON, March 23, 2026—Today, the Federal Communications Commission updated itsCovered List to include all consumer-grade routers produced in foreign countries. Routers are the boxes in every home that connect computers, phones, and smart devices to the internet. This followed a determination by a White House-convened Executive Branch interagency body with appropriate national security expertise that such routers “pose unacceptable risks to the national security of the United States or the safety and security of United States persons.”

The Executive Branch determination noted that foreign-produced routers (1) introduce “a supply chain vulnerability that could disrupt the U.S. economy, critical infrastructure, and national defense” and (2) pose “a severe cybersecurity risk that could be leveraged to immediately and severely disrupt U.S. critical infrastructure and directly harm U.S. persons.”

Read the entire statement at https://docs.fcc.gov/public/attachments/DOC-420034A1.pdf.

I agree with some very limited aspects of the reasoning behind this decision. Cheap consumer grade routers are routinely shipped with not just known security flaws, but sometimes with malware / spyware already installed. Attempts by "authorities" (not just in the US) to get the manufacturers to correct known issues have not been taken seriously by the manufacturers.

Thus this sledgehammer approach to improve the situation... whatever the real motives, however flawed the execution.

This issue won't affect the vast majority of consumers that use routers supplied by their Internet service provider such as Comcast, Starlink, etc. Those big providers have enough clout (influence) within the US government to get their units rapidly approved through this "process".

I predict the "process" as outlined, such as new units require approval from Department of Defense... will collapse within months under the weight of applications for use of newer technology in routers such as Wi-Fi 7 which is still in the early adoption phase. The "process" outlined by the FCC does not seem reasonable, workable, or scalable.

I don't plan to cover this issue further in Zero Retries as it will be breathlessly covered (it's irresistible clickbait) by consumer and homelab websites, newsletters, YouTubers, etc. That said, here are a few observations from the Zero Retries perspective.

I foresee three Zero Retries Interesting areas that I think this issue may affect:

  • AREDN makes extensive use of routers in being able to meld AREDN networking / access within an Amateur Radio Operator's home to be accessible via their household Internet... such as getting your laptop onto an AREDN network while using your household Wi-Fi.
  • 44Net / 44Net Connect requires routers (capable of Wireguard Virtual Private Network - VPN) for use of 44Net systems and services.
  • This issue also may affect Amateur Radio Over Internet systems such as communicating on Internet talk groups, especially using radio hotspots. Functionally, these projects / products bridge (route) Internet to a radio. No, these aren't "consumer routers" that the FCC is targeting, but that may well be too fine a distinction for the FCC when faced with a tsunami of requests for exemptions. Thus Amateur Radio products may well be swept up in the "blanket ban" that the FCC is proposing on "routers" that are manufactured outside the US.

    It's interesting to note the approach for Amateur Radio hotspots that AllScan uses in its products - combining used embedded PCs and commodity portable radios, ends up being a clever and effective workaround. Thus AllScan's products won't be affected by this issue.

Knowledgeable folks like many Zero Retries readers have known about the issues of cheap routers and the first thing they do when they want to use one is to install OpenWRT firmware. Whether a router is supported by OpenWRT is my primary checklist item when considering purchasing a new router.

I expect that embedded computers such as Raspberry Pis (with independent Ethernet ports and external, higher capability Wi-Fi), will bridge the gap of availability of consumer routers. That Raspberry Pi can handle this function is evidenced by their use by Pi-hole. I'll guess that some vendors will quickly bring Raspberry Pi "router appliances" to market... which may well prove highly useful to Amateur Radio. Just open up such an appliance to find the Micro SD card, and swap that out with a Micro SD card with Amateur Radio routing software.

Lastly, of course, this issue affects only those of us within the US trying to purchase products that are manufactured outside the US. My sympathies to vendors of innovative Amateur Radio products manufactured outside the US, trying to sell into the US, that will get impacted by this issue. Hopefully... not calling the product anything resembling Internet router will help.

Please direct comments / feedback about this article to the Zero Retries email list with the #ZR0244 hashtag.

By Steve Stroh N8GNJ

Email from Starlink (I'm a customer) directing me to their web page for this use case:

Be prepared for power outages, natural disasters, and extreme weather when traditional coverage fails..

STAY ONLINE NO MATTER WHERE YOU LIVE
Starlink delivers connectivity to remote areas beyond cell service reach.

Stay connected when you need it most with affordable service plans.

OFF-GRID RESILIENCE
Starlink emergency backup powers connectivity in even the most rural and remote areas.

CONNECTIVITY WHEN AND WHERE YOU NEED IT
Stay connected to friends, family, and your community without latency or delays.

GET ONLINE IN MINUTES
Starlink emergency backup deploys in minutes for instant off-grid connectivity.

BACKUP HOME INTERNET: STARLINK FOR OUTAGES. ANYWHERE COVERAGE.

Starlink offers anywhere coverage for homes during power and internet outages, harsh weather conditions, and natural disasters.

Starlink (a service of SpaceX) continues to expand the its marketing of Starlink service for additional use cases. This is the first time (that I'm aware of) that Starlink has explicitly marketed Starlink specifically, directly as "emergency backup" communications. Emergency communications capability has been mentioned in Starlink For Businesses for some time, but only somewhat incidentally to the overall service offering.

As I've mentioned, Starlink made me an offer I couldn't refuse as a Starlink Home customer - a free Starlink Mini unit as long as I maintain at least $5/month standby service. I said Yes, of course, and I've done a number of "test deployments" in the past several months of using it in a lightly simulated emergency scenario. I've set it up in random locations, using emergency power (battery unit, 12 volts from a car), and there are only two issues that I've seen:

  • If it's been a while since one's Starlink Mini has been used, upon activation it will not be usable immediately as it will download a software update that, depending on the connectivity (see below) may take some time.
  • Heavy tree coverage does degrade the speeds and reliability as the Starlink constellation shifts behind trees. Using the Starlink app to optimize the orientation of the Starlink Mini will help this issue a lot. Also, using Starlink Mini.

Also as part of my informal testing, I've "fast updated" my Starlink Mini operating operating mode from STANDBY - $5/month to ROAM - $50/month..

It's not a direct comparison between Standby and Roam. Standby speed is limited to 400 kbps, but total transfer is not capped. Roam speed is "full broadband" (speed not stated), but total transfer is capped to 100 GB. Changing back and forth is fluid, done in the Starlink app (either IOS or Android).

For emergency usage, the Starlink Mini is pretty amazing. It can be used for Broadband Internet either via built-in Wi-Fi or via Ethernet. Starlink offers a several routers what can extend the built-in Wi-Fi or via Ethernet. And the Starlink Mini can be powered via AC adapter, USB-C or 12 volts (I recommend the Starlink 12 volt to USB-C adapter).

I think this indicates that Starlink is beginning to position itself as a capable system for emergency communications. This is a slow start to existing Starlink customers. But, similar to Starlink for Businesses, I think that Starlink is likely to create a new sub-business for use of "fleets" of Starlink Minis to be managed, paid for (group discounts likely), and likely special services (Starlink specific Push to Talk voice communications app?) marketed to organizations with large service areas such as utilities, highway departments, construction companies, trucking companies, etc.

Please direct comments / feedback about I-Frame to the Zero Retries email list with the #ZR0244 hashtag.

ZR > BEACON

By Steve Stroh N8GNJ

Short mentions of Zero Retries Interesting items.

AREDN Soon "Rebased" on OpenWrt 25.12

Orv Beach W6BI on several AREDN-related email lists:

The nightly build due out on 03/18 has been "rebased" on OpenWrt 25.12. It has a new kernel, new wireless drivers and many, many months of patches and fixes and they've all been rolled into the AREDN software. It's been lab-tested and seems fine, but the usual caveat applies: Don't test it on any node you'd be really annoyed at having to rebuild. But please do test.

AREDN just continues to amaze me with its capabilities and the basic improvements that are continuing to be incorporated such as this.

PyTNC Pro

Stefaan Desmedt KO6IKR via email:

[My new project, PyTNC Pro,] is still in Beta, but it is APRS, Direwolf, VARA FM, etc. all in one interface.

I was a bit sick and tired of jumping around all these apps. I am looking for some feedback. Just put your radio in APRS mode, or if using VARA FM..

I am planning to do a monthly update of this.
Manual : https://github.com/smashingwaffle/pytnc-pro/wiki

https://github.com/smashingwaffle/pytnc-pro

From the Github page:

A FREE modern, feature-rich APRS transceiver for Windows with real-time mapping, emergency communications support, and VARA FM integration. The WIKI page is live.

Features:

📡 APRS Operations
• APRS-IS Integration - Connect to the worldwide APRS Internet System
• RF TX/RX - Transmit and receive over radio via soundcard modem (AFSK 1200 baud)
• VARA FM Support - High-speed digital mode for APRS over VARA FM
• Smart Beaconing - Automatic position beacons with configurable intervals
• Full Symbol Support - All APRS symbols with Hessu icon set

🗺️ Real-Time Mapping
• Live Station Tracking - See all APRS stations on an interactive map
• Clickable Callsigns - Click any callsign in the feed to pan to their location
• QRZ Popups - Station info with profile photos (requires QRZ subscription)
• Trail History - Track station movement over time
• GPU Accelerated - Smooth 60fps map rendering

🚨 Emergency Communications (EmComm)
• NOAA Weather Alerts - Real-time NWS warnings and watches
• USGS Earthquakes - Live earthquake data with magnitude filtering
• NASA FIRMS Wildfires - Active fire detection from satellite data
• Air Quality Index (AQI) - Smoke and pollution monitoring via AirNow
• Hospital Locations - Nearby trauma centers and emergency rooms
• DARN Network - Disaster Amateur Radio Network repeater locations

📻 Radio Integration
• PTT Control - Serial port PTT (RTS/DTR)
• CAT Control - Rig frequency/mode control (Yaesu, Icom, Kenwood)
• GPS Support - Serial GPS for automatic position updates
• Audio Device Selection - Independent TX/RX audio routing
Future feature ::### 💬 Messaging
• APRS Messaging - Send and receive APRS messages
• Message Acknowledgment - Automatic retry with ACK/REJ
• Conversation History - Persistent chat logs

KO6IKR is active in Amateur Radio emergency communications activities in California and the feature set of PyTNC Pro is tailored to the use case for that region's Amateur Radio EMCOM infrastructure. PyTNC Pro is an impressive project, from one person, illustrating that a lot of technological innovation is occurring, in Amateur Radio.

GroundWave Project

Email from Jason Miller KF7TNN on a private email list:

I've been working on a project that I would say is HAM adjacent and I would be curious if there is anyone in the group who would be interested in playing around with it and providing feedback on features and usability.

The project is called GroundWave and you can learn more about it here

https://groundwave.io

...

What is GroundWave

GroundWave is an open-source, field-deployable situational awareness platform inspired by ATAK (Android Team Awareness Kit). It provides mapping, real-time position tracking, messaging, and team coordination through a standard web browser — no native app installation required.

The platform is packaged as a suite of Docker containers designed to run on portable, low-cost hardware such as a Raspberry Pi or Intel NUC. A single server unit creates a local Wi-Fi access point; client devices — phones, tablets, laptops — connect to that network and open GroundWave in their browser.

GroundWave is fully self-contained and operational without internet connectivity. Offline map tiles, position data, chat messages, and all coordination tools are served entirely from the local device. When connectivity does exist, optional features such as online map style fallback and server federation become available.

GroundWave is MIT-licensed. The source repository will be open to contributions when GroundWave exits beta.

Design Principles

Every architectural and feature decision in GroundWave is guided by a core set of principles:

Offline-First. The system must be fully operational with zero internet access. Map tiles, APIs, and real-time communication all run locally. Internet connectivity, when present, is treated as an optional enhancement rather than a requirement.

Containerized. All server-side components run inside Docker containers orchestrated by Docker Compose. Deployment is a single command regardless of the host operating system. Updates and rollbacks are clean and reproducible.

Web-Native. Clients connect via any modern web browser. No native app is required on phones, tablets, or laptops. This eliminates app store dependencies and device enrollment friction in the field.

Replicable. A complete GroundWave deployment — server hardware, Docker images, and tile data — can be reproduced from a self-contained release archive. No external registries or cloud services are needed to stand up a new unit.

Modular. Features are organized into discrete, independently toggleable modules (chat, markers, file sharing, overlays, voice, federation). Operators can enable only what their mission requires via environment configuration.

Resource-Conscious. The platform is designed to run on single-board computers with limited CPU, RAM, and storage. Performance budgets are validated against a Raspberry Pi 4 baseline. Unnecessary dependencies are avoided.

No Cloud Dependencies. GroundWave does not phone home, require license validation, or depend on any third-party SaaS. All data remains on the local device under operator control.

Network-Agnostic. The server communicates over standard TCP/IP and works on any network topology — Wi-Fi hotspot, wired LAN, mesh radio, or ad hoc. The client needs only a browser and an IP route to the server.

A later followup from KF7TNN:

To be transparent here, this project was never aimed at competing with larger platforms or commercial offerings, but rather to provide smaller groups, organizations or rural communities who can’t otherwise afford those options a tool they could use. My goal was to just add in features that could make a difference, and let the users find interesting and impactful ways to use them in their scenarios. On one hand that might be aiding in SAR, CERT, etc., while on the other it could just be a local community or group using it to coordinate with volunteers for an event, for example. I’m excited to see it used in ways I never even imagined.

The self-contained nature of it is key and provides endless ways it can be deployed. Basically, any machine that can support Docker should be able to run GroundWave. And any client device that can support a web browser would be able to connect and use it. As far as a network goes, it just assumes it’s on one, but that could be anything from the internet, to cellular, to WiFi to all the way down to Meshtastic (coming soon, but as you can imagine limits a lot of the features unfortunately). I personally have been playing around with portable WiFi HaLow nodes running OpenMANET and that seems to work great.

As for the data, I have not added any connections to outside services or platforms, but would love to know more about the things that would be useful to connect to. For right now, any data generated within GroundWave is exportable from the dashboard, mostly as JSON, but a few of the location specific items have their own formats. The idea there was that before starting a “mission” you’d spin up an empty instance, load up your maps and data, and when you’re done you can export everything back out for analysis, public record, or whatever your use-case is. It also allows for reuse of annotations which is very useful for repeating events (think parades, festivals, etc., where the details are mostly the same and could be reused).

Feel free to reach out to me directly with any questions. Happy to demo it for you or take you deeper under the hood if you’d like. Just let me know.

KF7TNN posted his email address on the list - jason@jason-miller.com. GroundWave Project incorporates encryption, but this project is not necessarily intended for Amateur Radio use (but that's not structurally excluded, either). GroundWave Project is another impressive project, from one person, illustrating that a lot of technological innovation is occurring, in this case, adjacent to Amateur Radio.

The ISS Returns to S-Band: HamTV Now Transmitting Color Bars on 13 cm

The ISS Returns to S-Band: HamTV Now Transmitting Color Bars on 13 cm
Since just before Christmas 2025, the HamTV experiment aboard the International Space Station has resumed active video transmissions on the 13 cm amateur radio band. Where the downlink had previously been limited to a black screen, the signal at 2395 MHz is now carrying full-colour test pattern video.
AMSAT Canada

The above is an experiment. When I just paste in a URL, Ghost creates a website "bookmark" like the above . If this works well for readers (feedback requested) this would allow more items to be featured, with less manual formatting work.

This is a good article explaining the reasons for setting up a receive only station for S-band (13 cm) - 2.395 GHz. The article is Zero Retries Interesting - recommended. Kudos to AMSAT-CA for an interesting article and making content such as this publicly accessible instead of behind a paywall like AMSAT-US does.

My thanks to Amateur Radio Weekly Issue 411 for mentioning this item.

The postscript to this article was particularly Zero Retries Interesting:

What’s Coming Next on AMSAT-CA

This article is the first in a short, focused series aimed at helping amateurs move from curiosity to capability.

Upcoming posts will include:

A Minimally Viable HamTV Receive Station Experiments using easily obtained antennas, low-noise amplifiers, and simple RF chains to demonstrate what is just enough to receive the signal.

Selecting and Using a Software Defined Radio for S-Band Reception A practical discussion of SDR selection, front-end considerations, sampling bandwidth, dynamic range, frequency stability, and how SDR choice affects real-world microwave performance.

Demodulating and Displaying the Video A straightforward walkthrough of software tools, signal recording, demodulation steps, and video display—no black boxes.

Tracking and Automation Pathways Several approaches to tracking the ISS at S-band, from manual methods to semi- and fully-automated solutions, using commonly available tools.

Along the way, we’ll share real results with real hardware, so others can decide for themselves how far they want to push their experiments.

The Bigger Picture

The goal here isn’t just to receive colour bars.

It’s to lower the barrier to microwave experimentation, spark repeat engagement, and build practical skills across the amateur community. These short primers will eventually be consolidated into a complete technical paper documenting what was learned, what worked, what didn’t, and how others can build on it.

HamTV on the ISS gives us a rare thing: A persistent, meaningful microwave experiment that amateurs can grow with over time.

If you’ve ever been curious about S-band, this is the moment.

Stay tuned—pun fully intended—as we find out just how interesting a test pattern can be.

Improving Open AMBE for D-Star

Steve Lampereur KB9MWR:

Overview:

The AMBE vocoder (speech coder) problem started when D-Star was developed and introduced to ham radio in the late 90's early 2000's. It's since been compounded by DMR, Yaesu Fusion, and other digital radios. The proposed solution has been to replace this with an open source codec. However, none of these digital modes have a means to specify or differentiate the audio codec should they ever want to move away from AMBE. And there still isn't much of a working implementation of Codec 2 for VHF/UHF radios. There is a working implementation for HF. Codec2/FreeDV is a good conception, but it hasn't come to fruition in the advent of the AMBE patents expiring and other digital radios also employing AMBE and flooding the market. Besides we still don't have radios with open firmware where we could load our own apps or alternative codec.

Keen observers have noticed a number of good radio initiatives that sadly haven't come to be. The; Connect Systems CS7000, Wireless Holdings DV4 Mobile, the HT of the Future (aka: Algoram, Katena, Whitebox), the Newradio initiative in Germany/Austria, RU3ANQ SDR, and so on. There is a new (2019) initiative, the M17 Project, but it's too early to tell if that will reach production.

Manufacturers are a fairly conservative bunch. They don't want to invest in anything unless they know it's going to sell. We all understand. Fortunately, much of the innovation now is purely in the form of software, which is much easier to mass-produce than hardware. So all you need the manufacturers for is to make general purpose SDR hardware, which is an easier sell than some new special mode. It's also important for leaders to recognize the works of the dedicated software developers. And when the hardware manufacturers see the potential from their work, to work out an agreement so the software folks receive more than just a thank you.

This article resurfaced as part of an email discussion I participated in this week. While it's somewhat dated (it was stated in the email exchange that this was published six years ago), it seems worth revisiting as the patents for AMBE have now aged another six years (and now out of patent protection, and thus eligible for an open source workalike?).

It's worth discussion whether to (or not to) attempt to implement Amateur Radio digital voice modes such as D-Star and System Fusion, complete with AMBE, in new Software Defined Radios such as the forthcoming LinHT.

Or not? My impression is that Digital Mobile Radio (DMR) digital voice technology has largely eclipsed D-Star and System Fusion in Amateur Radio. Icom / Kenwood and Yaesu's radios for those modes are expensive; DMR radios are much less expensive. DMR radios are available from multiple manufacturers, and there are now many more DMR repeaters (and support groups) than for D-Star or System Fusion.

If it were me as a software developer (and I'm not), it would seem more fun to take advantage of the easier path of fully implementing the already open source, code available and proven M17 Project (which the LinHT developers have already done), or break some new ground in implementing FreeDV RADE (designed for HF narrowband channels) or FreeDV BBFM (designed for VHF / UHF wider channels), both of which have amazing voice quality considering the narrow channels, and especially in comparison to the (inferior, in my opinion) voice quality of systems using AMBE.

44Net Connect Has a Limit of 8 Tunnels

Phil Karn KA9Q on the ARDC 44Net email list:

... I've hit the limit of 8 tunnels per account, so I can't add any more.

Reply from Adam Lewis KC7GDY, ARDC's IT and Development Operations Manager:

Bumped you up. You can spin up more tunnels now.

Thus, "8" is a default, but not a hard limit. It was fascinating to read KA9Q's use case(s) and his experience with using 44Net Connect for the first time.

In the article Brinc unveils Guardian, a Starlink-connected drone that could ‘replace the police helicopter’ there was this mention:

Guardian is the world’s first Starlink-connected drone. An integrated panel on top of the device gives the drone unlimited range anywhere in the world, maintaining a reliable data link when traditional cellular or terrestrial infrastructure is unavailable.

Yes, Starlink (Mini) has been used on (larger) drones for some time. But in this photo:

BRINC Drones Guardian - Image courtesy of GeekWire

the Starlink unit (looks to me to be) smaller than the Starlink Mini - roughly half the size of the Starlink Mini. I'm inventing (or anticipating) the terminology for this unit - The Starlink Micro. Not to mention that the power requirements of this unit must be commensurately lower to not severely curtail the power budget of drone overall, which also needs to power a camera and a floodlight. Given that the "Micro" would be operating with a much improved Line of Sight to the Starlink constellation in Low Earth Orbit, perhaps the "Micro" has be simplified, and its power budget reduced with the use of a static panel antenna, rather than a Phased Array antenna.

My primary reason for mentioning Guardian and its Starlink connectivity isn't to begin covering drones in Zero Retries (though I'm not fundamentally opposed to doing so). Rather, this development illustrates the amazing increase in radio technology that we wouldn't have imagined in previous eras. We've had handheld satellite radios for decades (Iridium and Globalstar), but only for voice and low bandwidth data. But this unit, given its capability of high definition video, must be capable of at least 20 Mbps. Now Broadband Internet Access in a (nearly) handheld form factor can be used nearly anywhere in the world for real world applications, at reasonable prices.

First Release Candidate For GNU Radio 4 (GR4)

Image courtesy of GNU Radio
MARCH 22, 2026

GNU Radio 4.0 RC1: A New Foundation for High-Performance Signal Processing

GNU Radio 4.0 has reached its first release candidate (RC1)—a major milestone that signals the transition from active development to near-production readiness. See the tag for all the details.

At this stage, the core architecture is stable, the execution model is well-defined, and the API is no longer expected to undergo major breaking changes. Developers can begin building against GR4 today with confidence that their work will carry forward into the final release.

GNU Radio 4 is a fundamental re-architecture of the system—designed for modern C++, deterministic execution, and high-performance pipelines that scale from embedded systems to large, complex DSP applications, while remaining accessible for research and hobbyist use.

This is not an incremental update. It is a new foundation for building signal processing systems.

Based on an early explanation of (then forthcoming) GR4 at GNU Radio Conference 2025, from my perspective, there are two primary advancements in GR4 from earlier versions of GNU Radio:

Plugin system with built-in reflection
...
This enables:
...
Integration with higher-level systems, including AI-driven workflows

and

Permissive core licensing

The GR4 core adopts a more permissive licensing model, lowering barriers for adoption:

• Easier integration into commercial systems
• Greater flexibility for mixed-license environments
• Broader ecosystem participation

It was explained to me at GNU Radio Conference 2025 that GR4 will be much more usable than earlier versions of GNU Radio for development in conjunction with Artificial Intelligence / Machine Learning.

One thing I hope to see in GR4 is for the Graphical User Interface (GUI) - GNU Radio Companion (GRC) to be more integrated if not integral to GR4. Imagine doing vibe coding in GR4 and the output of the vibe coding will be the graphical elements of a GNU Radio Companion diagram. Conceptually, an AI could teach one the basics of Software Defined Radio using GNU Radio Companion block diagrams - and develop useful new radio technology.

As explained to me at GNU Radio Conference 2025, the license used in previous versions of GNU Radio required public disclosure of any code derived from GNU Radio, and that had a chilling effect for corporate or government use of GNU Radio other than for prototyping. That's no longer the case with GR4. Thus GR4 could be used more directly for (Software Defined) radio development rather than a workflow of

  • Prototype in GNU Radio
  • Prove out concepts
  • Redevelop as an embedded system

Radio technology developed in GR4 should be able to be "directly embedded", saving a lot of (re)development time and resources... somewhat akin to (imperfect analogy warning) prototyping software in a high level language, proving out the concept, then rewriting the system in a more efficient low level (machine) language.

Overall, it seems that GR4 is a clean sheet of paper approach to the entire concept of GNU Radio as (my imperfect analogy) conceptually a Linux-like Operating System for Software Defined Radio systems. There seems to be a migration path for earlier versions of GNU Radio flowgraphs to be adapted for GR4, thus it won't be required to "start over from scratch" for systems developed in earlier versions of GNU Radio.

Beyond those two elements of GR4, I can't do justice to the wealth of detail in this article about the improvements in GR4 beyond earlier versions of GNU Radio, so please click the link at the headline.

I think that GR4 will be a big deal for Software Defined Radio technology in 2026 and beyond, especially for Amateur Radio applications given GR4 will be more usable for development with the help of Artificial Intelligence.

UltraPeater

The UltraPeater by Zindello Industries is the ultimate infrastructure-grade LoRa mesh repeater designed to elevate your mesh network to new heights—literally.

...

Engineered for fixed, high-performance deployments at comms sites, towers, masts, or remote installations, the UltraPeater transforms the compact power of the Luckfox Pico Ultra into a reliable, always-on backbone node. Unlike portable solar-powered mesh devices, the UltraPeater is built for seamless integration into existing infrastructure: powered via PoE for 24/7 uptime, mast-mount ready, and ships with a preconfigured setup so it hits the air running.

At its core is a precision-engineered radio hat featuring one of two high-performance EBYTE E22-series LoRa modules (customer-selectable at order*):

• EBYTE E22 900M30S — 30dBm (1W) output with integrated LNA (Low noise amplifier) for superior sensitivity and performance in low-noise environments, delivering exceptional range and reliability where clean spectrum is available.
• EBYTE E22P 915M30S — 30dBm (1W) with both integrated LNA and BPF (Low Noise Amplifier and Band Pass Filter for 915MHz), providing top-tier noise rejection and clean operation in higher-RF-noise environments like HAM Radio sites, dense urban towers or co-located comms sites.

Every UltraPeater board is rigorously tested in-house, with actual transmit power output verified before shipping—so you get guaranteed performance, not just spec-sheet promises.

Flexible Antenna Connectivity

The UltraPeater can be optioned with your choice of two robust antenna connector types to suit your installation:

• SMA — Compact and widely compatible, perfect for sheltered outdoor installations or use indoors.
• N-type — Rugged, weatherproof, and ideal for outdoor/mast-mounted setups with low-loss coax runs.

UltraPeater - even better than a SuperPeater! 🤣

I don't remember where I saw this mentioned, but this makes a lot of sense. The main thing it has to recommend it is that it has 1 watt transmit power, powered by Power Over Ethernet (POE) (several options). At a quick read, I wasn't able to determine if the UltraPeater is "North America" compatible. These are made in Australia, thus they may not be configured to use the full 902-928 MHz band that we have access to in North America.

Introducing Hamstat.com

Andrew McCaskey WA4MTP:

The HAMSTAT HamsOverIP Monitor served up at https://hamstat.com provides a real time view of “conditions” on the HamsOverIP system. HamStat shows who is on a HamsOverIP call, who has recently finished a call, and who may be available or open to a call from another ham. Any licensed amateur radio operator worldwide can join HamsOverIP with proof of license and a free Digital Mobile Radio (DMR) id. 
Image courtesy of Andrew McCaskey WA4MTP
The Active BLF tab on the HamsOverIP.com site is the indicator that a ham extension is busy. Hamstat reads that info and determines who just hung up and how long they have been offline. The system operates on the notion that for a short time (selectable up to 30 minutes), you are probably still in the shack and might be open to a call or QSO with another ham that you have not yet met. Their extension number is right beside their callsign, and a click on their callsign pulls up the QRZ.com page for that station.

Hamstat also lets you:

• Enthusiastically advise people that you are “in the shack” for the next few minutes and that you are definitely open to a call or QSO.
• Add up to five stations in a watchlist, and then notifies you through your browser when they become available.
• See who has recently been on the system
• Opt of of HamStat so you will never appear on the page at HamStat.com (unless you opt back in at a later date).

This seems like a cool enhancement to HamsOverIP service. WA4MTP makes a good case:

HamStat is the same scenario: It identifies who may still be in the shack for a “tailend” QSO by VoIP phone using the HamsOverIP system instead of radio.

This is a reminder of yet another project for N8GNJ / Zero Retries Labs – get my Amateur Radio VOIP phone, formerly for Hamshack Hotline, ported over to HOIP. And get registered for HamStat at the same time.

CDM Repeaters

Custom-built Amateur Radio 1.25M Repeaters

Welcome to our site dedicated to custom-built amateur radio repeaters! We specialize in 220 MHz systems, but our expertise extends beyond that frequency. Whether you're a hobbyist or a seasoned operator, we here to provide you with high-quality solutions tailored to your needs. Join us in enhancing your communication experience!

Another fortuitous "I don't remember how I found it" Zero Retries Interesting discovery. The North America 1.25 meter / 222-225 MHz (and perhaps 219-220 MHz) is an ideal place for more interesting data communications systems - if there is a reliable source of radios for that band. I used to recommend BridgeCom Systems BCM-220 radios, but that unit is now out of production. When dealing with surplus / used commercial land mobile radios, there's an infinite number of ways to get tripped up if you're not very well versed in knowing what to buy and how to adapt them to Amateur Radio use. Thus I'm happy to pay a company like CDM Repeaters to procure, test, and adapt such radios to end up with a unit usable for Amateur Radio.

I have too many projects already in queue (including a BridgeCom Systems BCR-220 repeater...) to investigate their products, but it's good to know that CDM Repeaters is a source of (apparently repurposed Motorola CDM radios) for the Amateur Radio 1.25m band.

Video - TRMNL X

From the video description:

The TRMNL X is a 10.3-inch e-ink dashboard with 16-level grayscale, 227 PPI, IP65 water resistance, dual ESP32 microcontrollers, 5 GHz Wi-Fi, and up to 12,000 mAh of battery for six months between charges—all for $219 with no subscription fees. One year after the original TRMNL review, every promise has shipped: open-source firmware, bring-your-own-device support for Kindle, Nook, iPad, Kobo, Raspberry Pi, and Seeed Studio DIY kits, plus fully self-hosted servers in PHP, Node, Python, Ruby, and Elixir through the Terminus project. The community has exploded to over 850 free plugins and recipes funded by a Creator Fund that pays developers real money based on installs and API impressions. TRMNL also hacked 2-bit grayscale out of 1-bit e-paper hardware, shipped zero-flicker refresh, removed front branding with Tailor, and published an Unbrickable Pledge promising to open-source everything if the company folds. The TRMNL X features a 4:3 aspect ratio, magnetic pogo pin charging, modular puck connector for future PoE and sensor accessories, gesture touch controls, and OTG power bank mode—making it the e-ink display the original should have been.

This seems like an amazing combination of features. I knew e-ink was power efficient... but six months on battery? Wow!

My thanks to Joe Hamelin W7COM for mentioning this to me.

Please offer comments / feedback about ZR > BEACON to the Zero Retries email list with the #ZR0244 hashtag.

Request To Send

By Steve Stroh N8GNJ

Still Working on Getting Paid Subscribers Set Up In Ghost

Ghost has something like 50-75% of the publishing features that Substack has. Mostly that's for the better, such as Ghost has no "Followers", no "Notes", etc. But Substack was definitely easier to figure out the basics like setting up paid subscription tiers.

Tina and I were able to get Stripe connected to Ghost... but presenting the "tiers" to new (and existing) email subscribers isn't very transparent. We're working on it.

Apologies to Zero Retries Subscribers on Comcast / Xfinity

Like Microsoft, Comcast / Xfinity operates their own "Internet protection" systems for both basic web access and users of comcast.net email. Currently, the zeroretries.radio and zeroretries.net domains (the latter used, at the moment, only for email) are being blocked by Comcast / Xfinity. I've appealed this issue several times via the online form below. My last attempt pleaded for them to tell me specifically what Comcast's issue is with those domains. All I've received to date is a blanket "nope - still on the naughty list until the domain owner fixes the issues we have a problem with" reply, with no indication that the specific info I included was even looked at, let alone considered.

All I can suggest to Comcast / Xfinity subscribers of Zero Retries is to provide feedback to Comcast / Xfinity via this online form: https://spa.xfinity.com/report.

This issue is an additional reason for me to be glad to be a former customer of Comcast / Xfinity. For me, Starlink is an ideal Internet service provider - "just the bits" Internet service, stable pricing, works reliably, and provides good quality broadband Internet anywhere in suburban / rural areas like Bellingham / Whatcom County, Washington that have scattered islands of other Broadband Internet options, including fiber and "5G" cellular. Not to mention the significantly lower cost than Comcast - I'm using the 200 Mbps tier for $80 / month and it works great. I could probably be on the 100 Mbps tier for $50 / month and I might try that for a month to see if we even notice the difference.

Perhaps a Disruption Is Coming for the zeroretries.radio Domain...

Interesting email this morning...

We are writing to inform you that your .radio domain name will be transferred to a new registrar by the beginning of May 2026, on a date that will be shortly notified.

Following the transfer of the .radio top-level domain registry from the European Broadcasting Union (EBU) to Digity, LLC, EBU has decided to cease the operations of the register.radio service, which has been operated by COREhub SRLU on EBU’s behalf until now. Therefore all domain names sponsored by register.radio will be transferred to an ICANN-accredited registrar affiliated with Digity, LLC: Sav.com, LLC. From that day expected in early May neither COREhub SRLU nor EBU will have any responsibility on the management of these domains.

...

Once the transfer is completed, Sav.com will become your sponsoring registrar for .radio domain name(s), and you will receive further information directly from Sav.com regarding account access and registrar services.

If there are any significant disruptions from this transition, that could be a tipping point to convert to a (more mundane) domain than zeroretries.radio. I'm acutely aware of the sunk cost fallacy regarding the time / energy / reader frustration issues associated with using zeroretries.radio.

Nice Mention of Zero Retries by Jared Crapo K0TFU

Zero Retries is an independent newsletter promoting technological innovation in and adjacent to Amateur Radio. Published by Steve and Tina Stroh, it’s the weekly newsletter to read if you are what Steve calls a NewTechHam. NewTechHams wanna build handheld SDRs that can do DSTAR, AllStar, or any other digital mode with just a software update. NewTechHams are as comfortable with a Raspberry Pi as they are with a 2m HT. NewTechHams want to design repeaters that use digital timeslicing so a repeater doesn’t need a big duplexer or multiple frequencies. If any of this sounds interesting to you, you should be subscribed to this free email newsletter.

My thanks to K0TFU for this nice mention on his website!

Hamvention Ho!
7 weeks until Hamvention 2026
in Xenia, Ohio, USA...
Zero Retries / DLARC booth 1506
in Building 1 / Maxim

Weekends Are For Amateur Radio!

The weather oracle on my pocket computer predicts "not rain" for this weekend, so mostly this coming weekend will be another catch-up session in N8GNJ / Zero Retries Labs. As for projects, as soon as I get down to the actual bench top in my workshop, I want to fire up the MeshCore unit I was loaned to try that out.

Have a great weekend, all of you co-conspirators in Zero Retries Interesting Amateur Radio activities!

Please offer comments / feedback about Request To Send on the Zero Retries email list with the #ZR02xx hashtag.

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 financially:
Founding Member 0000 - Steven Davidson K3FZT (Renewed 2025, 3rd year!)
Founding Member 0001 - Randy Smith WU2S (Renewed 2025, 3rd year!)
Founding Member 0002 - Chris Osburn KD7DVD (Renewed 2025, 3rd year!)
Founding Member 0003 - Don Rotolo N2IRZ (Renewed 2025, 3rd year!)
Founding Member 0004 - William Arcand W1WRA (Renewed 2025, 3rd year!)
Founding Member 0005 - Ben Kuhn KU0HN (Renewed 2025, 3rd year!)
Founding Member 0006 - Todd Willey KQ4FID (Renewed 2025, 3rd year!)
Founding Member 0007 and 0010 - Merik Karman VK1DF / VK2MKZ (Renewed 2025 x2, 3rd year!)
Founding Member 0008 - Prefers to Remain Anonymous 08 (Renewed 2025, 3rd year!)
Founding Member 0009 - Prefers to Remain Anonymous 19 (Renewed 2025, 2nd year!)
Founding Member 0011 - Rick Prelinger W6XBE (Renewed 2025, 2nd year!)
Founding Member 0012 - Ryan Tolboom N2BP (Renewed 2025, 2nd year!)
Founding Member 0013 - Newton White N4EWT (Renewed 2026, 2nd year!)
Founding Member 0014 - Joe Hamelin W7COM (Renewed 2026, 2nd year!)
Founding Member 0015 - Rich Stocking N7OP (New 2025)
Founding Member 0016 - Prefers to Remain Anonymous 77 (New 2025)
Founding Member 0017 - Phil Karn KA9Q (New 2025)
Founding Member 0018 - Prefers to Remain Anonymous 95 (New 2025)
Founding Member 0019 - Prefers to Remain Anonymous 0108 (New 2025)
Founding Member 0020 - Prefers to Remain Anonymous 110 (New 2025)
Founding Member 0021 - Prefers to Remain Anonymous 111 (New 2025)
Founding Member 0022 - Prefers to Remain Anonymous 112 (New 2025)
Founding Member 0023 - Prefers to Remain Anonymous 116 (New 2026)
Founding Member 0024 - Rob Bowser (SPOOLTENNA) (New 2026)

Numerous Annual and Monthly subscribers who also generously support Zero Retries financially!

You thousands of readers of Zero Retries without which there would be little point in publishing this newsletter.

The Usual Administrivia

⬅️⬅️⬅️  Previous Issue of ZR  |  Next Issue of ZR  ➡️➡️➡️

This issue, Zero Retries 0244, released on 2026-03-27

(end) This issue was 9,165 words.

Read more