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.
My thanks to Craig Dale W9PAX for renewing as an Annual Paid Subscriber to Zero Retries this past week!
Financial support from Zero Retries readers is a significant vote of support for the continued publication of Zero Retries.
Reopening Substack Comments to Paid Subscribers
Optional Paid Subscriptions to Zero Retries, such as W9PAX this week, help offset the expenses of publishing Zero Retries. Tina and I are indebted to all of the paid subscribers and Founding Members.them. From the beginning of Zero Retries, the content of Zero Retries is the same for free and paid subscribers. Recently, I was asked by one of the Paid Subscribers if I would reconsider my policy of closing comments on Substack and steering comments to the Zero Retries email list, and
The Paid Subscriber noted that when they feel moved to comment, it’s a bit more “friction” to send an email to the Zero Retries email list versus posting a comment on Substack. To post a comment on the Zero Retries email list, one issue is that you have to be subscribed to the Zero Retries email list to be able to send an email to it.
That was a fair point, and I decided that being able to post a comment on Substack will be one minor “perk” for the Paid Subscribers.
Email from Martin McCormick K1MCC on the supporters email list:
With two full Moons in May, a MoonRF / open.space update is officially overdue!
Last week we applied to Crowd Supply to help us launch QuadRF, our 4-antenna / 4x4 MIMO SDR tile. It’s the core of the 240-antenna MoonRF architecture, the building block for the larger arrays.
The QuadRF Kit is one RF tile + four dual-polarization antennas, an integrated Raspberry Pi 5, and a preloaded software stack so you can start experimenting right away.
One exciting thing about QuadRF is that it moves software-defined radio beyond time and frequency and into the spatial domain.
This is most obvious in the real-time RF camera mode, that gives an augmented-reality heat-map of all the RF signals around you..
Check out our full application video about it here:
That shows our literal first attempt with the augmented-reality RF overlay on a cellphone! It’s cool to watch, but even more amazing in hand, as the visualization is quite immediate and responsive.
Besides shooting nerdy YouTube videos, we’re,
cleaning up the software/drivers/docs/examples so more people can build on the code
adding a battery and cellphone holder feature to the enclosure for AR
preparing antenna, mechanical, and simulation files for the open source larger arrays for those who want to build their own early
working on our CCATS commodity-classification request so we can confirm the proper export-control treatment before launch and make shipping availability clear for backers
We are not live on Crowd Supply yet. They let us know they received the application and are excited to work through the details early this week. One nice thing about Crowd Supply is they handle all distribution / shipping / VAT / export etc.. which let’s us focus on the actual technology and support, so it will be great to work with them.
We’ll keep you posted! Assuming the project gets approved, help support us by picking up one QuadRF Kit (or two)! You can then reuse the kit’s tile as part of the larger MoonRF phased arrays which will become cheaper to build when we start shipping mass RF tiles!!
In the meantime, please join the Discord if you have questions, ideas, demo requests, or just want to follow along,
Post Publication Update: Email from Martin McCormick K1MCC:
The QuadRF [kit] is likely to be $399, not $2000.
Wow. Just… Wow. That’s an incredibly reasonable price point.
While K1MCC attracted my attention with an open source, hackable, phased array antenna system that, oh yeah, could be ganged together to do Earth Moon Earth (EME) communications at 5 GHz, there are many other applications for a phased array antenna system that’s hackable. One of the most interesting and potentially useful is:
… augmented-reality heat-map of all the RF signals around you.
After my meeting with the Cascade STEAM Spectrum group a couple of weeks ago1, the QuadRF is the kind of tool / capability that really helps newcomers to radio technology get a jump start on viscerally beginning to understand RF… because with an radio energy heat-map, they can finally “see” radio energy, not just try to visualize it in their mind. Another effective demonstration, when you do have the ability to “see a radio energy heat-map is to demonstrate attenuation of various materials, and reflectivity of materials.
I predict MoonRF will eventually sell a… lot… of QuadRF to Electrical Engineering programs and EE students.
For precision frequency measurements it needs an external reference clock adaptor
Hardware design (schematics and PCB) are not open-source
So we decided to design a new SDR
Based on the BBRF103 → RX-888
Eliminated VHF converter and other unused components.
Improved and flexible filtering and low-frequency performance.
Input for external reference clock
Input for time-synchronization source
Improved thermal design
Larger PCB, allowing easier future development
True open-source from TAPR
I’m glad to see this significant new project from TAPR. The HamSCI community has been making good use of a network of RX-888s, but at HamSCI 2026, when I first heard of this project (apparently at the very early stages), there was a lot of frustration expressed that buying a RX-888 to participate in HamSCI research was, essentially, pretty random chance that any given unit purchased could result in a usable unit, or a poorly built unit, or an outright scam. There are no “brand names” of RX-888 units.
I hope TAPR begins some real marketing for this unit to build interest. At the moment, the existence of this project is essentially word of mouth. There is no dedicated mention of this project (that I can find) on the TAPR website, and to date, it hasn’t been featured in the TAPR newsletter (that I recall reading).
I’m refreshing my AIOC project with new hardware and software, and I’m excited to share what’s coming.
COS (Carrier Operated Signal) is used by applications like AllStarLink (ASL3) to indicate that a radio carrier is present, it not based upon the sound received, but on the carrier being present (even is there is no speech at the time). Good COS performance is important so that the ASL3 (or similar) software knows when to be sending the signal to the other party, and when to stop sending.
This new AIOC hardware version stays true to the original AIOC form factor and dimensions while integrating new circuitry to provide several meaningful improvements. It uses the standard v1.3 or later firmware:
Hardware COS — Speaker Bias Method For low-cost HTs in the Baofeng class, the new board includes hardware COS detection using the speaker bias method to reliably detect an open squelch. This delivers consistent hotspot performance that virtual COS implementations simply can’t match — no more dropped keying or intermittent behaviour.
Hardware COS — Logic-Level For HTs with logic-level COS support, such as the Tidradio H3, a dedicated logic-level COS input is included. This also opens the door to other use cases like integration with an SA818 module or an APRS repeater.
Improved Voltage Regulation The dual regulator has been replaced with two discrete regulators, offering better short-circuit protection — particularly useful given the open, “naked” nature of the AIOC board — along with improved overall reliability.
Circuit Layout Refinements Vulnerable tracks have been moved away from plug solder joints, and pads have been made larger and easier to work with, reducing construction risk and making the build more beginner-friendly.
New Setup Scripts for ASL3 AllStarLink v3 supports the AIOC, but currently requires manual file editing. I’ll be releasing a single-line setup script that handles all the necessary modifications to ASL3, eliminating errors and making the process far more accessible.
New ASL3 How-To Documentation Configuration guidance on this blog has drifted out of sync with the current state of ASL3 and AIOC over the years. I’ll be publishing a definitive how-to guide covering a complete simple hotspot build using the G1LRO AIOC card and a low-cost HT, with full use of the advanced COS functionality for reliable, professional-grade performance. Video walkthroughs are planned too, and I’ll be sending sample boards to some YouTube friends for independent reviews.
Watch this space.
G1LRO’s addressing of the COS issues with portable radios is welcome relief. That’s one of the most frustrating aspects of using inexpensive portable radios for data communications.
AIOC is All In One Connector is an open source project for a single unit that combines the (previously, separate) audio interface and programming interface hardware. AIOC is in a form factor suitable for just plugging into many portable radios with a pair of 3.5mm “audio” jacks. There are many versions of the AIOC available for retail sale, including one that’s called All In One Board, not intended for use with portable radios. My personal favorite is a version by Nigel Armstrong NA6D, who generously donated a number of AIOCs for Zero Retries Digital Conference 20252.
An AIOC mated to an inexpensive portable radio is an easy, low-cost low-risk way to experiment with Amateur Radio data modes. However, there are two significant “gotchas” for those new to data modes using portable radios.
Some portable radios are slow (electronically) to switch from Receive to Transmit mode (and back to Receive) - hundreds of mS versus tens of mS. If you have such a radio, data modes can be frustrating to set up because you have to configure each application (data or voice) that you want to use to provide adequate switching time before attempting to transmit data or voice. In Packet Radio, this parameter is called TXDelay (TXD). One easy workaround for this issue is to buy a Baofeng UV5R Mini for data experimentation; see Zero Retries 0237 - Is The “Mini” Better for Data Modes? (Video) for context.
Because the transmitted radio energy is being radiated close to the data device (the AIOC) because of the “rubber duck” antenna on the portable radio, radio energy can cause unintended operation, usually by induction into the data cables as they act as receive antennas. The usual cure is to use a high quality (good shielding) data cable, or add ferrite coils onto the data cable to suppress the radio energy from being conducted by the cable.
It’s frustrating to see the “latest and greatest” radios proudly debuting their built-in 1200 bps (and occasionally 9600 bps) TNCs… that are basically 30 year old technology. Audio interfaces like AIOC combined with very capable software such as Dire Wolf running on the host computer or RadioMail on an iPhone are much more capable and flexible than any (fixed function) internal TNC on a portable (or mobile) radio.
Thought experiment: Instead of integrating a TNC into a portable (or mobile) radio, integrate an audio interface such as an AIOC instead. I’d be much more inclined to buy such a portable radio as opposed to yet another “meh” portable radio “featuring” an internal TNC.
Thanks to my satellite station, my shortwave station was suddenly available for experimentation. The idea arose to find a digital mode robust enough for my situation with the interference and offering true keyboard-to-keyboard communication. I’ve had quite a bit of success with FT8 so far, but it’s quite far from real QSOs. However, there’s JS8 with the accompanying software JS8Call. This digi mode is like FT8 but for real QSOs and has many other great features such as relaying messages, sending heartbeats, querying which other stations are able to hear, and more. After some research, it turned out that the main activity takes place on 40m. This is perfect because I have a 10-meter-long vertical antenna right behind the garden shed that is tuned to 40m.
The Station
My idea was to build a JS8 station that’s as simple as possible, so it can also be operated remotely. I’ve already tried remote operation with the Hermes Lite 2, though back then I was still using a power amplifier and an antenna tuner - with only moderate success. The whole setup is far too complex, with too many variables. So I came up with the following setup:
Raspberry Pi 5 running Debian Linux with JS8Call and a VNC server
10m long vertical antenna
40m band pass filter
no antenna tuner
no amplifier
I’ve already described the station’s setup here: https://rz01.org/qmx. To summarize the linked post, I’ve installed the QMX+ and the Raspberry Pi in a 19-inch rack inside the garden shed.
This is another facet of a trend I’ve been seeing that I’ve begun calling RadioServer. Formerly, I’ve also called this idea Station Server, and before that I think I might have called it “RadioLab” a few times as an allusion to Information Technology (IT) experimenter’s HomeLab. Just as DK1MI describes with his remote JS83 station, generically a RadioServer is a radio / computer “stack” that’s within your household, but “sits in a corner unattended”. A RadioServer isn’t intended to be used locally; only rarely (troubleshooting) would you sit in front of the RadioServer. Instead, you access it remotely via your home network from your lap / laptop, your couch / tablet, or even a mobile phone. A RadioServer isn’t the same as a remote station (though, I guess it is, from a purely technical perspective - an IP address is an IP address).
Another well-developed example of a RadioServers is DigiPi which modifies data modes intended to display locally and reroutes display, keyboard, and pointer into a web browser interface.
The most well-developed example of a RadioServer is by Paul Schwan N4FTD, explained well on his website Recliners On the Air (ROTA). He has put a lot of work into creating his concept of a RadioServer (which he terms Radio Engine).
My thanks to Amateur Radio Weekly Issue 422 for bringing this development to my attention for inclusion in Zero Retries.
See what’s happening on the air — without sitting in front of a radio.
NodusNet is a community-powered ham radio activity dashboard. It observes local FM traffic in real time, identifies operators by callsign, tracks nets, and builds a shared picture of what’s happening on the air. Whether you’re a licensed ham or just curious about what’s on the airwaves — you’re welcome here.
What is NodusNet?
Ham radio is a blind medium. Unless you’re parked on a specific frequency at the right time, you have no idea what’s happening on the air. New hams get licensed and hear silence. Net controllers run sessions without participation data. Clubs can’t tell which members are actually active.
NodusNet makes local ham radio activity visible, measurable, and shareable.
Listener nodes — each one just an RTL-SDR dongle and a small app — monitor local repeaters and feed activity into either a local (your own) or shared dashboard — your choice! NodusNet detects transmissions, identifies operators by callsign, recognizes net sessions, tracks participation, and surfaces patterns across your local bands.
Live activity feed — See who’s on the air right now across all monitored frequencies
Net tracking — Automatic net detection with check-in counts and participation trends
Leaderboards & badges — Community recognition for active operators
Interactive map — See where activity is happening geographically
Repeater profiles — Which repeaters are active, when they’re busiest, who uses them
Club directory — Find and join local ham radio organizations
Notifications — Get notified when a callsign you follow is heard or a new ham keys up
New ham welcome & connect — Automatically greets newly licensed operators heard on the air and connects them with locals who share their interests
Privacy controls — Don’t want your callsign publicised? No problem — claim it and opt out with one click
How It Works
STEP 1
Plug in an RTL-SDR dongle
$25–35, any RTL2832U-based USB stick
STEP 2
Enter your zip code
Local repeaters populate automatically from RepeaterBook
STEP 3
Watch your dashboard
Activity appears within minutes
STEP 4
Sign up
Unlock leaderboards, operator profiles, and community features
Each node monitors multiple frequencies simultaneously using FFT channelization, transcribes speech locally using AI, and extracts callsigns from the audio. All processing happens on your hardware. If you want more — connect to NodusNet!
This is an interesting system. It seems to be very early days for it:
Where is NodusNet available?
NodusNet is live in Omaha, NE. Each new metro requires at least one listener node — no code changes. If you’re interested in bringing NodusNet to your area, reach out.
Despite the similarities, NodusNet seems to be an independent development from RepeaterBook’s Project Apollo, although NodusNet uses RepeaterBook for repeater data lookups.
I didn’t find any information about the person(s), group, or company behind NodusNet.
Interesting project!
My thanks to Dave Stewart K7XST (Founding Member 0025) for bringing this development to my attention for inclusion in Zero Retries.
Hot Iron #133
Frank Barnes W4NPN via the Hot Iron distribution email list:
I’m a day late distributing this May 31st issue, due to making some home repairs that my missus said “would not wait.” Message received and understood. Home harmony now reigns.
As usual, this issue covers a wide range of topics and wanders over the ham radio landscape. Since we are the “Constructors” (”builders”) club, it tends toward building projects. I’m constantly looking for simple solid state and/or digital projects that can be easily constructed at home, as well as tube designs (which I’m partial to). I’m not a trained digital technician so must rely on others for this info. Not being very digital, I tend toward older analogue designs. Please send info you might have regarding digital projects.
This issue mentions
The sad cessation of CHU transmissions,
BBC’s 198 KC long-wave cessation,
A reminder about DLARC,
The 76 year- old 555 timer chip that just won’t stop tickin’,
I am in the process of integrating the use of the TNC4 with my iOS app to allow an RF path out from the iOS environment. If you have an iOS device, a TNC4 and a capable 9600baud KISS mode radio (see the Mobilinkd website for insights), you may be able to help verify this feature. Please reply to this email if you are interested in helping to test and prove out this capability.
The Mobilinkd TNC4 is a KISS TNC with Bluetooth (that can connect to both Apple IOS and Android devices ) as well as a USB-C connection. It’s battery powered and pretty small, thus it works well with portable radios. One of the TNC4’s unique features is that it supports M17 data modes. Please help W5GGW if you can.
It shows all the stations my AUBNOD hears with the correct tag in real time, plotted on a proper map with active/stale status and a sidebar to browse through.
Getting on the map is simple. Just include a location tag in any packet beacon you send and get it to a point my node can hear in south Auburn. I hear KBANN the best
The format is: <MAP:lat,lon,callsign,nodename>
or
<MAP:lat,lon,callsign>
It can be part of a larger message — doesn’t need to be a standalone beacon. If AUBNOD hears it (usually relayed through KBANN), you’ll appear on the map within about 30–60 seconds. More instructions on the top of the webpage under “How to”
A note on the stations already showing. I imported the digipeater nodes from the old maps so you can see what’s out there, but they’re on the same timer as everyone else:
Green = heard within the last 24 hours, Gray = last heard 1 day to 2 weeks ago, Disappeared = no activity for over 2 weeks,
If you operate a node and want it to stay visible, just make sure it sends a beacon through every so often. At least once a day to make it not turn stale.
Let me know what you think. Good idea? Bad idea? I’m also open to suggestions.
From the 145050PacketNetwork email list home page:
145.050 Packet Radio Network
In California, Nevada, and Oregon: The VHF Ham Frequency at 145.050 is the home to an extensive NET/ROM Packet Radio Network.
It still rocks my world that the 145.050 Packet Radio Network is perking along using NET/ROM as its networking protocol. Note that NET/ROM was the original… and powerful… mesh networking protocol for Amateur Radio Packet Radio. When it was introduced, NET/ROM was horribly constrained by running it on TAPR TNC-2 hardware… a 1 MHz Z-80 system, with 32kB ROM and 32kb RAM. I can’t imagine how well it works now with 1 GHz (and multi core) processors, and pretty much as much RAM as you could use.
Good thing folks like the 145.050 Packet Radio Network aren’t paying any heed to those that consider Packet Radio no longer used, interesting, or relevant.
My thanks to Joe Hamelin W7COM (Founding Member 0014) for bringing this development to my attention for inclusion in Zero Retries.
The articles I write for the blog are mostly technical but, I thought it was about time that I wrote this article as it’s been buzzing around inside my head for some time now.
So, what are the 5 things that I have found revolutionary in my shack that have brought new, exciting ideas and projects to life making amateur radio more enjoyable.
1: A RaspberryPi Single Board Computer
2: A 3D Printer
3: An AllStarLink Node
4: Node-Red
5: A Hermes Lite 2 HF SDR Transceiver
M0AWS offers a compelling, detailed justification for all of these Zero Retries Interesting items. I agree with all of them.
PacketRF is firmware for building IP-capable radio nodes that behave like ordinary network interfaces from the host side and like proper amateur radio modems on the air side. It is open source, it runs on RP2350 hardware, and it is designed as a platform — meaning it does not stop at one protocol or one board.
The project currently focuses on New Packet Radio by Guillaume F4HDK, because NPR is the most interesting actively deployed data-radio system on the 70 cm band and because there is a real opportunity to move it forward without breaking what already works. Beyond NPR, PacketRF is intended to grow into a more general experimentation platform for packet networks over RF, including classic AX.25 audio packet radio, additional transceivers, and eventually delay-tolerant networking on top of all of that.
A PacketRF node connects two worlds. On one side it speaks standard IPv4 — the HW shows up to your operating system as a regular network interface, gets an address, takes part in routing, and carries any traffic you care to push through it. On the other side it speaks whatever air protocol the firmware is currently running, today NPR over an SI4463 transceiver. There is no proprietary modem in the middle, no special tool to capture and forward the data; once the node is up, the radio link is just an interface like any other, and the rest of the stack does not need to know it is there.
Configuration and status live on a separate management interface, reachable both locally over USB and remotely over IP, including over the radio itself. That management interface uses CoAP and CBOR, requires authenticated writes, and is designed to be safe to leave it reachable on a real an open network. More on it in Quick Start, the Management CLI, and the developer-side Control Module.
Existing amateur data systems sit at two extremes. Traditional packet radio is universal but slow and hard to extend past the assumptions it was built on in the 1980s. WiFi-derived systems like HSMM/Hamnet are fast, but they need bands and conditions that not every operator has access to and that not every experiment fits inside.
Between those two points there is a useful middle: usable IP throughput on lower bands, narrower channels, modest hardware, and a clean network model. NPR already lives in that middle. PacketRF is an attempt to give it a modern, maintainable codebase, a proper management options, and room to grow into more than one protocol family.
There is also a more personal motivation. Building a packet radio platform turns out to be a very direct way to learn, in detail, how IP networks actually behave when the link underneath them is genuinely constrained — a shared TDMA channel, narrow bandwidth, real latency, occasional silence or noise. That kind of environment is exactly where most modern “Internet networks” stop working, and where amateur radio can experiment and be interesting to use.
This bit was inspired:
Between those two points there is a useful middle: usable IP throughput on lower bands, narrower channels, modest hardware, and a clean network model.
I’ve met folks who can’t imagine such a “useful middle”. They’re advocates of either “TCP/IP is only usable on 1 Mbps+ networks” or “Packet Radio is its own networking system, and has no need for TCP/IP”.
Kudos to OK5VAS for thinking this through and presenting it so well.
(Another great article from) Vlastimil Slinták OK5VAS
Some time ago I started implementing “classic” packet radio into PacketRF. Not the fancy NPR stuff, not high-speed links, but the old and simple AX.25. The one that runs at 1200 baud over a narrow FM channel and somehow still works over surprisingly long distances.
And as soon as I decided to support 1200 baud packet radio (often called PR1200) in PacketRF, I ran into a problem that many people before me had already solved, but I had never really thought about in detail: how do you efficiently decode Bell 202 AFSK on a small embedded system without wasting half your CPU on it?
This post is a write-up of what I learned. Part refresher, part rediscovery, part “wait, why does this even work?”. I ended up making a bunch of small visualizations along the way, mostly out of curiosity, and at some point I realized this is actually a very nice way to look at DFT and Goertzel that I personally had never seen presented this way.
So this is not a textbook explanation. This is more like: I needed this for PacketRF, I looked into it, and this is what finally made it understandable for me. And I also wanted to share my fancy animated GIFs :)
What are we trying to decode?
Let’s start from the beginning. Packet radio is one of those things that “everyone knows”, but if you ask three people what PR actually is, you will probably get three slightly different answers.
Classic packet radio (on VHF/UHF) is basically a stack of very simple building blocks layered on top of each other:
AX.25 on the link layer (HDLC-like framing)
NRZI encoding of bits
AFSK modulation at the physical layer
And specifically for 1200 baud, this is Bell 202, which uses two tones:
The part we care about in this article is just one small piece of that chain: detect tones and turn them into bits in the receiver path. So the question we will be solving in the rest of this text is:
Given a chunk of audio samples, how do we decide whether it contains 1200 Hz or 2200 Hz?
That’s it. That’s the entire problem.
At that point, OK5VAS begins a deep dive into signal processing, applied to the “simple” problem of decoding a packet radio 1200 bps transmission that consists of two tones.
Why a self-healing UDP/multicast data mesh simplifies your PACE plan, defeats jamming, and makes cheap drones lethal.
The Department of War (DoW) builds communication plans around a framework called PACE — Primary, Alternate, Contingency, Emergency. Four pathways. Four separate systems. Four failure modes to manage under fire.
Every layer assumes a different radio, a different waveform, a different piece of kit strapped to the warfighter or bolted onto the vehicle. When the Primary goes down, the unit switches to Alternate. When Alternate goes down, they switch to Contingency. And so on, until they reach Emergency — which usually means voice over HF and a prayer.
This model made sense when every pathway was a single point of failure. A radio. A satellite link. A frequency. One jammer pointed at the right frequency and the link was dead.
This model was a compromise. It made sense when compute at the edge did not exist, when processors on tactical nodes could not encode, decode, or repair data in real time, and when the gain from a smarter transport layer was not sufficient to justify the engineering effort. The technology was simply not there for COTS processors at the edge. So the military solved the problem with hardware redundancy instead of software intelligence — at the cost of increasing the warfighter’s fighting load.
That compromise is no longer acceptable. Edge compute is here. Processors that fit inside a cheap drone can execute forward error correction in milliseconds. The gain from a self-healing transport layer is no longer marginal — it is the difference between a formation that survives jamming and one that does not. Modern warfare demands mesh-scale communication across thousands of nodes in contested spectrum. The current model was not designed for that fight.
But what if the data link itself could not be killed with a single jammer? What if the mesh healed itself faster than the adversary could disrupt it? What if taking down the mesh required an emission signature so large that it became a target worth more than the data it was trying to silence?
That is the argument for a self-healing UDP/multicast data mesh. And that is what changes the PACE equation.
The Problem
Today’s military data links are point-to-point. One sender. One receiver. One pathway. Jam the path, interfere with it, or destroy a node along it, and the message does not arrive. Hub-and-spoke does not solve this. It scales it. Each spoke is its own point-to-point link to the hub. The hub is a single point of failure managing dozens of single points of failure. Take down the hub and every spoke goes dark.
The military compensates by layering redundancy. PACE is that redundancy. But PACE is expensive. Each layer requires its own hardware, its own spectrum allocation, and its own logistics supply chain. The four-system model is a SWaP-C problem, whether on a soldier’s rucksack or on a deployed drone.
The result is predictable. Drones today rely on a single data link. If that link gets jammed, the drone is lost. The warfighter loses situational awareness. The mission degrades.
This is not a technology problem. We have the technology today, ready to be fielded. It is an architecture problem, and it begins with a change in perspective.
Self-Healing Changes the Math
A UDP/multicast mesh does not rely on a single path. Every node in the mesh is both a sender and a receiver, and data propagates across multiple paths simultaneously. If one node is jammed or destroyed, the mesh routes around it automatically. No operator intervention. No switching to Alternate. No time wasted by the warfighter switching hardware or configurations.
This is the power of self-healing at the transport layer. The mesh detects losses. The mesh repairs them. It does both in microseconds — not the minutes it takes a human to recognize a link failure, diagnose the cause, and switch to a backup system.
PULSE is built with the single goal of accomplishing this: a true UDP/multicast mesh. This is done by building a full protocol from the bits up, based on NACK-based repair, forward error correction encoding and decoding in under 50 microseconds, and Beehive clustering that organizes nodes into self-managing groups.
Every node carries the logic to detect, repair, and reroute. No central controller. No single point of failure.
The mesh may still need a PACE plan, but it is far more resilient before it ever reaches for one. A self-healing mesh at the transport layer absorbs jamming, reroutes around lost nodes in DDIL environments, and restores data flow — all before a frequency hop is necessary. The mesh exhausts its own redundancy first. Primary, Alternate, Contingency, and Emergency are embedded in the topology itself. Every path is Primary. Every route is Alternate. The mesh provides all four layers simultaneously without four separate hardware stacks. When the mesh finally does jump to another frequency, it is a deliberate step — not a panicked fallback.
This Substack newsletter is apparently a marketing vehicle for TerraKinesis and their product called PULSE:
Distributed Computing up to 1,000 nodes. Real-time. No Servers. No SATCOM.
1,000+NODES AT SCALE
<1ms LOCAL REPAIR
95-99%
Allowing myself a bit of snark… the Substack newsletter and the website of vague claims is what is passing for “marketing” of this product in this era of white hot interest and ample available investment funding of anything related to drones used in defense systems.
I’m including this in Zero Retries to illustrate how much we Amateur Radio Operators can do / experiment with in Amateur Radio and how cutting-edge mesh networking is in the real world of radio technology. It wouldn’t take much to create a mesh network such as what’s proposed here using software defined radios operating in Amateur Radio spectrum, deployed by a bunch of Amateur Radio experimenters.
I just created and released a new piece of open source software called kiss-tnc-bridge. This daemon bridges Bluetooth KISS TNC clients to TCP KISS TNC servers. Here’s why I created it, how it works, and how you can use it.
Why does this exist?
If you already have a KISS TNC server running on TCP, why would you want it to work via Bluetooth?
In a scenario where power consumption matters more than range, Bluetooth Low Energy uses less power than WiFi.
On Apple’s iOS, the aprs.fi app cannot use WiFi when it’s not the foreground app. But it can use Bluetooth, allowing it to remain connected in the background.
I created a portable APRS station using Graywolf on a Raspberry Pi. Graywolf can be configured to create a TCP KISS TNC so multiple apps can use the radio set up in Graywolf. kiss-tnc-bridge lets a mobile device use Graywolf’s TNC without having to have any WiFi available.
How I use it
I have built a setup I call an APRS Command Center. I’ll do a more detailed write up soon. To summarize, I want an APRS station that supports some or all of these functions, depending on the scenario:
portable (i.e. work in a car, easy to set up in a remote location)
flexible radio/antenna options (digirig connected to a 50 W mobile radio and an X300 on a 25 foot mast, or my TH-D75 connected via USB cable)
multiple options for power (solar, USB-C battery, 12V power, 13.8V power)
doesn’t require internet access
can be an igate if internet access is available
shows a live map of APRS stations, which needs to work with no internet access
can beacon my location, as well as objects and locations of other assets
I want a station I can use at a race event where there is no internet access.
This station will be most useful when co-located with net control. In that setting, it is likely that other devices, like a phone running aprs.fi, may want to connect to the station to send/receive their own APRS packets using the radio connected to the APRS Command Center. Graywolf can easily offer a TCP KISS TNC. This new kiss-tnc-bridge also offers another method to connect, and has the important benefit that it doesn’t require WiFi to work.
APRS (Automatic Packet Reporting System) is a digital ham radio protocol that broadcasts live position, telemetry, weather and short messages over VHF — and worldwide via the APRS-IS gateway network. Licensed amateur-radio operators have used APRS since the early 1990s as a real-time situational awareness tool.
APRS World is a modern visualization platform for the worldwide APRS network used by amateur-radio operators. Free, open-source, no ads — a live ham radio station locator and callsign lookup, all in your browser.
APRS in practice
Once a station beacons a position, every digipeater within RF range repeats it; one of those digipeaters typically forwards it to APRS-IS, the global internet backbone for APRS. APRS World subscribes to that backbone so the moment a beacon hits the network, it lands on the live map you see at the homepage.
Features
Live worldwide map of APRS stations
Per-station detail with position history, telemetry, weather, raw packets
Read and send APRS messages over APRS-IS (licensed callsign + passcode)
Follow friends and stations, multi-SSID support
Dark/light theme, multilingual UI
APRS World (apparently) has three elements - Web app, a cloud back end, and an Android app. The Android app has some paid features, such as ability to use a KISS TNC. The basic functionality on the web app (viewing) is available at no cost (as far as I could tell).
APRSdroid is a hugely valuable 12-year-old project — its KISS TNC and phone-mic AFSK depth is real. This page isn’t a hit piece; it’s a head-to-head on the things modern web + cloud can do that APRSdroid hasn’t touched.
Apparently an IOS app is planned - from the FAQs:
When is the mobile app?
Native iOS + Android, shipping to App Store + Play Store + F-Droid once Apple Developer + Google Play Console accounts are live. Soon.
It’s an interesting looking project, and apparently a new entrant into Amateur Radio APRS.
I didn’t find any information about the person(s), group, or company behind APRS World other than it seems to be based in Turkey, per the two contributors in the Credits page being Amateur Radio Operators in Turkey.
There’s Plenty Happening in the Apple Amateur Radio Land With Some Great New And Updated Apps Across Mac, iPhone, iPad, AppleTV And Watch (May 2026)
Andrew Woodward VK2AWN on his blog:
In recent months there’s been a plethora of apps coming to Mac, iPhone and iPad for amateur (ham) radio. I have tried a few of them and in the list below comment where I feel I can do so credibly.
If there are some apps I have missed, please share them in the comments on the social media posts or contact me directly and I will update the list. I will link this post to my Apple Amateur Radio page and the Apple Amateur Radio Subreddit.
There are many other great web based services that could be included in this list but they have no specific Mac, iOS, iPadOS or other Apple aspect and are therefore not included. Apps are presented in alphabetical order.
I wasn’t sure what criteria VK2AWN was applying, but there were several data related apps in development or in the process of being updated including RadioMail and Packet Commander, both from Island Magic / Georges Auberger WH6AZ. (I couldn’t find a comment section on that post on VK2AWN’s blog.)
Both RadioMail and Packet Commander are listed on Mac Ham Radio, which is a comprehensive website for all things Amateur Radio and Apple products. I don’t know why I didn’t check previously, but it has an RSS feed, now added, so I can more easily stay up to date on Mac and iDevice Amateur Radio apps.
My thanks to Amateur Radio Weekly Issue 423 for bringing this development to my attention for inclusion in Zero Retries.
A modern, cross-platform implementation with improved state management and progress tracking.
What caught my attention is that you can tune the parameters for smaller chunks (for slower networks), and many other actions / tuning parameters. Just another tool that you can use over Amateur Radio networks that support TCP/IP.
JS8Call Waveforms “Wrapper” for Arbitrary Data (and Your Own Software)
Speaking of JS8Call, I’m also the author of js8net (now js8net-legacy), which is an open-source python API layer that makes JS8Call easy to interface with your own software. The current version is for the legacy JS8Call software. I started working on fixing and rebuilding the JS8Call API for JS8Call-Improved, but had two big deaths in the family in close succession, and had to drop out of that effort and focus at home for a while. It looks fantastic, though, and I wish them well. I’ve build js8net-improved that does the same thing as the old js8net, only for the new js8net-improved.
I’ve also written my own version of JS8Call called JF8Call from scratch. It’s early in the process, so it’s still alpha code, but it does work, and I’ve had multiple QSO with other ham using JS8Call. I started with a version of the 8FSK library extracted from JS8Call-Improved (see 8FSK Modem), but now it’s got its own written-from-scratch 8FSK modem (see 8FSK Modem-clean). It also supports Olivia (with the modem code extracted from FLDigi) and a PSK soundmodem that supports BPSK, QPSK, and BPSKF at various speeds that I wrote from scratch. Oh, and also the codec2 modem. JF8Call was designed from the ground up to run headless (using an API), with a Qt interface, or with a curses-based text interface. The websocket API supports 100% of the functionality of the software, and has a corresponding Python3 SDK called jf8net.
The title is my (probably imperfect) description of what N0GQ is describing in those two paragraphs.
N0GQ is a friend from when we both lived in the Lesser Seattle area and both involved in Amateur Radio data communications (and discovered that we were both involved in Experimental Aircraft and both were fans of Zenith kit planes).
I saw N0GQ at Hamvention 2026 and we caught up a bit. As you can see from the above, N0GQ “forged his own path” in Amateur Radio data communications. I think that his utilities are an elegant method to use the robust FT8 / JS8Call waveforms for data communications moving arbitrary data.
I maintain this guide to attempt to keep track of the many Zero Retries Interesting events that are relevant to or adjacent to technological innovation in Amateur Radio. Recent additions include:
2026 AMSAT Space Symposium & Annual General Meeting 2026
ARRL Field Day 2026
HOPE 2026
GNU Radio European Days 2026
North Star Radio Convention 2026 / ARRL Dakota Division Convention 2026
Winter Field Day 2026
Zero Retries Digital Conference 2026
There are a few more events to add to it and then it will be complete for 2026, and it will soon be appropriate to add some big events for 2027.
Followup on Zero Retries 0250 - Networking, Networking, Networking
The piece “Networking, Networking, Networking” contains this paragraph.
But none of the current Amateur Radio networks are big enough, successful enough to be considered the data networking solution for Amateur Radio. Thus, Amateur Radio can’t really cite a “success story” for Amateur Radio networking.
I think I understand the reasoning behind the piece, but I do push back against the notion that there needs to be “the data networking solution”, or a “success story”, and therefore the need for a “networking strategy”.
Amateur Radio is an experimental hobby. Note the emphasis on hobby: it’s not a business or a profession: it’s a wide-ranging technical hobby. Everything from construction to moon bounce with stops along the way for [B,I,M,P,S]OTA, DXing etc. Do any of these have “success stories”? If they do, I’m not aware of any. Do they have a “strategy”? No.
Amateur data communications is no different. It’s an opportunity to see what can be done and to experiment. There’s no business plan, no strategy, and no success measures beyond simple things like “how far did that message/packet get?”
Having said all that, I can see the merit in somebody trying to inter-network all the islands: after all, the inspiration for the “Internet” was to inter-network those islands of proprietary network protocols. But it’s still a personal endeavour - like climbing a mountain - because it’s there; and not because it’s of any practical use.
Also, using the voice network analogy is odd. I look around in my local area and I see analogue FM, DSTAR, DMR, and C4FM repeaters. Hardly ubiquitous unless they are all connected to AllStarLink.
M5KVK had some fair points. I replied:
The following are my opinions. Your opinions may vary. Reasonable people can agree to disagree in their respective opinions.
Amateur Radio in the US isn’t a hobby that can be enjoyed equivalent to… woodworking, for example. That is, anyone can do woodworking with tools as simple as a saw, or as expensive as an entire shop, limited only by one’s time, interests, and budget, and skills. How you do your individual woodworking is completely up to you, unregulated, requiring no other inputs.
In contrast, Amateur Radio is a radio service regulated in the US by the FCC. The spectrum used by Amateur Radio is allocated by the FCC (and international treaties for some spectrum). Without allocated spectrum, there is hobby radio that can make use of limited, unlicensed portions of spectrum, such as CB, FRS, MURS, ISM, etc. Hobby radio is not completely equivalent to Amateur Radio. There are severe power limits, no access to portions of spectrum such as HF, and many other significant differences.
Thus Amateur Radio does not exist solely as a hobby activity. The spectrum allocated to Amateur Radio is at the expense of that “Amateur Radio” spectrum being withheld from other uses of spectrum. In some cases, Amateur Radio operation in some portions of spectrum is at the forbearance of primary users, such as the US Government / Military.
Thus, for Amateur Radio to continue to exist as we know it… to have dedicated or shared spectrum allocated to Amateur Radio, requires some justification. I posit that “allocate spectrum for hobbyist use” may not be sufficient justification by those that make the decisions of how to allocate spectrum amongst competing uses.
The most prominent, relevant, present / future such justification for the continuation of dedicated or shared spectrum allocated to Amateur Radio, is providing examples of networking over Amateur Radio and more generally, networking in many different forms and capabilities, via radio.
In my article, I cited many examples of different forms and capabilities of networking occurring in Amateur Radio.
I cited Amateur Radio voice repeaters as an example that Amateur Radio knows how to deploy infrastructure to the point of having achieved near-ubiquity. No, Amateur Radio voice repeaters are not heterogeneous, but that wasn’t my point. My point was that all but a vanishingly small number of Amateur Radio Operators are within the coverage pattern(s) of “Amateur Radio infrastructure” (voice repeaters). Thus we know how to deploy Amateur Radio infrastructure. To date, we’ve chosen to do so only for voice communications.
I also posted a more general reply:
In a more global response to Gareth M5KVK and Orv W6BI about why not try to create a global network within / for Amateur Radio…
I think part of the problem is most of Amateur Radio doesn’t understand how much… how good… networking we can (now) do. A great example is the high capacity networking that’s now possible on the Amateur Radio 10 GHz band that Orv W6BI cites.
We’ve had low capacity, fragmented networks for so long, that many of us in Amateur Radio feel that’s the best Amateur Radio networking can accomplish.
We know about Winlink, accessed via packet radio, VARA, or PACTOR 4 via VHF / UHF and HF,
We know about networks of APRS digipeaters,
We know about pockets of packet radio networking such as OhioNet, EastNet, the 105 network in California,
Or that the only way to bridge disparate Amateur Radio networks is via Internet.
If most of us in Amateur Radio don’t know what’s possible in Amateur Radio networking… we accept the status quo of low speed, fragmented networks that we’ve had for decades now.
I posit that now that we have the technology of interconnecting Amateur Radio networks… I think we should try to interconnect Amateur Radio networks.
And, that doing so will have a side effect of demonstrating Amateur Radio is relevant and useful and interesting in the 21st Century.
…
Have a great weekend, all of you co-conspirators in Zero Retries Interesting Amateur Radio activities!
My ongoing Thanks to: Tina Stroh KD7WSF for, well, everything! Jack Stroh, Late Night Assistant Editor Emeritus Fiona and Shreky Stroh, Late Night Assistant Editors In Training
Founding Members who generously support Zero Retries financially: Founding Member 0000 - Steven Davidson K3FZT (Renewed 2025, 3rd year!) Founding Member 0001 - Randy Smith WU2S (Renewed 2025, 3rd year!) Founding Member 0002 - Chris Osburn KD7DVD (Renewed 2025, 3rd year!) Founding Member 0003 - Don Rotolo N2IRZ (Renewed 2025, 3rd year!) Founding Member 0004 - William Arcand W1WRA (Renewed 2025, 3rd year!) Founding Member 0005 - Ben Kuhn KU0HN (Renewed 2025, 3rd year!) Founding Member 0006 - Todd Willey KQ4FID (Renewed 2025, 3rd year!) Founding Member 0007 and 0010 - Merik Karman VK1DF / VK2MKZ (Renewed 2025 x2, 3rd year!) Founding Member 0008 - Prefers to Remain Anonymous 08 (Renewed 2025, 3rd year!) Founding Member 0009 - Prefers to Remain Anonymous 19 (Renewed 2025, 2nd year!) Founding Member 0011 - Rick Prelinger W6XBE (Renewed 2025, 2nd year!) Founding Member 0012 - Ryan Tolboom N2BP (Renewed 2025, 2nd year!) Founding Member 0013 - Newton White N4EWT (Renewed 2026, 2nd year!) Founding Member 0014 - Joe Hamelin W7COM (Renewed 2026, 2nd year!) Founding Member 0015 - Rich Stocking N7OP (Renewed 2026, 2nd year!) 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) Founding Member 0025 - Dave Stewart K7XST (New 2026)
Numerous Annual and Monthly subscribers who also generously support Zero Retries financially!
You thousands of readers of Zero Retries without which there would be little point in publishing this newsletter.
Fair Use - All excerpts from other authors or organizations, including images, are intended to be fair use and are fully attributed generally by author and link (URL).
Paid Promotional Content - Unless otherwise noted in the article or item, advertisement, or sponsorship notice, Zero Retries does not include paid promotional content. Exceptions:
Advertisements in Zero Retries,
Sponsorships in Zero Retries,
Zero Retries products,
Zero Retries events
Features and content exclusive to paid subscribers.
