Zero Retries is an independent newsletter promoting technological innovation in and adjacent to Amateur Radio, and Amateur Radio as (literally) a license to experiment with and learn about radio technology. Radios are computers - with antennas! Now in its sixth year of publication, with 3600+ subscribers.
Zero Retries Digital Conference 2026 is October 16th in San Ramon, CA
www.zeroretries.org/p/conference
Steve Stroh N8GNJ, Editor
Tina Stroh KD7WSF, Business / Conference Manager
Substack says this issue is likely to be truncated by some email clients. Thus, it might be easier to read in a web browser - www.zeroretries.org/p/zero-retries-0261.
It’s easy and free to subscribe for your own copy of Zero Retries every week:
In This Issue:
ZRDC 2026 Update 09/04/2026
Tina Stroh KD7WSF
Correction - Internet Connectivity for Meshtastic and MeshCore
Steve Stroh N8GNJ
Update on KK7NQN AI Net Logger
Hunter Inman KK7NQN
Zero Retries - Tightening Focus to Data Communications
Steve Stroh N8GNJ
Deferring Most Coverage of Amateur Radio Space to the AMSATs
Some Exceptions About Space That I’ll Continue to Cover in Zero Retries
Continuing Coverage of Software Defined Radio, Especially GNU Radio
The Use Cases of IP400 Networks
Steve Stroh N8GNJ
Packet Radio in Amateur Radio is Mostly Stuck at 1200 bps AFSK AX.25
Again, What Can You Do With IP400? Text Chat Like Meshtastic / MeshCore.
Dragon Labs CR-8 - An 8-channel Coherent SDR That Doesn’t Sacrifice Performance
Open Research Institute (ORI) Presentation at futureGEO Community Workshop at HAMRADIO 2026
TAPR Annual Membership Meeting and Board of Directors Elections
Comments on This Issue (Redirects to Comments Page)
I-Frame
By Steve Stroh N8GNJ
Brief notes about this issue of Zero Retries.
Paid Subscribers / Founding Members Update
Optional Paid Subscriptions, and especially Founding Member subscriptions to Zero Retries not only help offset various expenses incurred in publishing Zero Retries, but also are a large portion of the “seed capital” that is needed to host Zero Retries Digital Conference (ZRDC) 2026, and future ZRDCs. Thank You!
My thanks to Bill Arcand W1WRA for renewing as Founding Member 0004 to Zero Retries in the past two weeks (4th year)!
Founding Member Subscribers are listed in every issue of Zero Retries!
My thanks to Prefers to Remain Anonymous 09 for renewing as an Annual Paid Subscriber (4th year!) to Zero Retries in the past two weeks!
My thanks to Prefers to Remain Anonymous 41 for renewing as an Annual Paid Subscriber (3rd year!) to Zero Retries in the past two weeks!
My thanks to Tom Cain WB8OUE for renewing as an Annual Paid Subscriber (2nd year!) to Zero Retries in the past two weeks!
My thanks to Prefers To Remain Anonymous 81 for renewing as an Annual Paid Subscriber (2nd year!) to Zero Retries in the past two weeks!
My thanks to Prefers To Remain Anonymous 85 for renewing as an Annual Paid Subscriber (2nd year!) to Zero Retries in the past two weeks!
My thanks to Prefers To Remain Anonymous 86 for renewing as an Annual Paid Subscriber (2nd year!) to Zero Retries in the past two weeks!
My thanks to Prefers To Remain Anonymous 88 for renewing as an Annual Paid Subscriber (2nd year!) to Zero Retries in the past two weeks!
My thanks to Prefers To Remain Anonymous 90 for renewing as an Annual Paid Subscriber (2nd year!) to Zero Retries in the past two weeks!
My thanks to Conrad Trautmann N2YCH for upgrading from a free subscriber to Zero Retries to an Annual Paid Subscriber in the past two weeks!
My thanks to Prefers To Remain Anonymous 133 for upgrading from a free subscriber to Zero Retries to an Annual Paid Subscriber in the past two weeks!
My thanks to Prefers To Remain Anonymous 134 for upgrading from a free subscriber to Zero Retries to an Annual Paid Subscriber in the past two weeks!
My thanks to Prefers To Remain Anonymous 132 for recently becoming a new Annual Paid Subscriber to Zero Retries. (This acknowledgement should have been in the previous issue of Zero Retries. My apologies for that omission.
My thanks to John Zaruba K2ZA for becoming a new Annual Paid Subscriber to Zero Retries in the past two weeks!
My thanks to Prefers To Remain Anonymous 135 for becoming a new Annual Paid Subscriber to Zero Retries in the past two weeks!
My thanks to Prefers To Remain Anonymous 96 for one year of being a Paid Subscriber to Zero Retries this past week!
Financial support from Zero Retries readers is a significant vote of support for the continued publication of Zero Retries.
Zero Retries Summer 2026 Publishing Schedule - Biweekly
During Summer 2026, Zero Retries has being published biweekly. The publication schedule for the remainder of Summer 2026 is:
Zero Retries 0262 - 2026-09-18
The reason for not publishing on 2026-09-11 is that next week, Tina and I will be brand new grandparents1, and we’ll spending the week oohing and cooing and cuddling with our new grandchild. Thus publishing Zero Retries will be a distant secondary priority. Thus I choose to recognize that reality in advance and not stress about Zero Retries.
I’ll resume publishing Zero Retries weekly with Zero Retries 0263 on 2026-09-25.
Please direct comments / feedback about I-Frame to the Zero Retries email list with the hashtag #ZR0260. Paid subscribers can comment directly on the web version of this issue.
ZRDC 2026 Update 09/04/2026
By Tina Stroh KD7WSF
Zero Retries Digital Conference Manager
This is the fourth in a series of updates leading up to Zero Retries Digital Conference 2026.
Panel of Speakers Complete
With roughly six weeks to go, the panel of speakers is complete. The panel of speakers is:
Dave Platt, AE6EO - OpenTNC - something old, something new, something to build upon.
Cale Mooth, K4HCK - New Tech Hams
Jeff Scoville, AE5ME - M17
Martin Alcock, VE6VH - IP 400 Project
Glen Popiel, KW5GP - Microcontroller Communication Technologies and Protocols for Ham Radio
Mooneer Salem, K6AQ - FreeDV Project
Craig Lamparter, KM6LYW - DigiPi - Data
Steve Stroh, N8GNJ - Update on projects and presentations from ZRDC 2025 and LinHT Status in late 2026
Panel Discussion - Encryption in Amateur Radio
Registration Has Slowed
I have to say, registration has been very slow. I am not sure if it is just that time of year when we are saying goodbye to summer and vacations or something else. I have sent out a round of press releases and will continue to do so. Please feel free to share any and all information so that the word goes out.
Two New Sponsors - CentyLab and NA6D
To that note, we have also had two additional sponsors support ZRDC 2026 - CentyLab and NA6D. Both have contributed amazing equipment for door prizes at ZRDC 2026. We thank both for their generosity and support.
CentyLab:
PocketPD (3)
PPsTrigger Board (2)
NA6D:
AIOC assembled (5)
Open TNC with both cables (5)
As we did last year, the AIOCs will be bundled with Explorer QRZ-1 portable radios donated by GigaParts.
Demonstrations - AMSAT CubeSatSim and M17 Repeater
We are going to have demonstrations at ZRDC.
Steve is a member of AMSAT and read in the most recent AMSAT newsletter that they can make a demonstrator unit of “CubSatSim” available for events like ZRDC. We’re grateful to Alan Johnston, KU2Y and AMSAT for the loan of a CubeSatSim for ZRDC. Steve is happy that it will be able to run a demonstration of “Pacsat”. He’ll be providing more details about that in a future issue of Zero Retries.
Also, Jeff Scoville, AE5ME will be bringing his M17 repeater, so if you have M17 radios, bring them tuned to:
Repeater Output: 441.850
Repeater Input: 446.850.
Steve will be bringing our pair of CS7000 M17 portable radios, and his pair of TNC4s with suitable radios to do M17 data.
Please direct comments / feedback about this article to the Zero Retries email list with the hashtag #ZR0261. Paid subscribers can comment directly on the web version of this issue.
Correction - Internet Connectivity for Meshtastic and MeshCore
By Steve Stroh N8GNJ and Claude (specific model not noted)
In Zero Retries 0260 - A Brief Comparison of Networking - Meshtastic / MeshCore vs Amateur Radio AX.25 Packet Radio, in a footnote, I said:
It is my understanding that there’s no Internet gateways / tunneling / bridging with Meshtastic or MeshCore. There is a technology for LoRa called LoRaWAN that is such an Internet backbone, but LoRaWAN is generally not used in hobbyist use of LoRa.
I received a graceful correction on this point from Conrad Trautmann N2YCH:
When I began with Meshtastic, there is functionality built into the phone app to use your phone’s internet via MQTT to get on an internet backbone. I mentioned that in my qrper.com article [Building an Off-Grid Meshcore Network, One Node at a Time].
I thought you’d want to be aware of that functionality. I did try it with Meshtastic and it was a little crazy, with random messages popping up on the device. There didn’t seem to be any organization to it, and I quickly disabled it.
Apparently Meshcore has a way to use the internet to connect repeaters together, but I haven’t dug in deep enough to speak to that.
Thus, my statement about no Internet gateways / tunneling / bridging in Meshtastic or MeshCore is profoundly incorrect from not doing reasonable research. My apologies to Zero Retries readers. My thanks to N2YCH for pointing out this error.
I mentioned in my brief Post-Publication Update in Zero Retries 0260:
The popular perception (and, in my reading, almost all deployments of Meshtastic / MeshCore) is that Meshtastic / MeshCore networks don’t use, or depend on Internet or other “centrally controllable” infrastructure.
Claude Says About Meshtastic Internet Connectivity…
As is usual these days, to get a fast, general overview of a particular topic or question, instead of doing a web search, it’s often more efficient to consult an AI - Claude, in my case. This is the pretty useful and informative result for Meshtastic.
(This AI answer is not vetted.)
Meshtastic bridges to the internet almost entirely through MQTT, with a few variations on how a node gets that MQTT connection:
1. MQTT bridging (the core mechanism) Any node can be configured to publish/subscribe mesh packets to an MQTT broker, either:
Public server —
mqtt.meshtastic.org, the default public broker. Encrypted channels stay encrypted end-to-end even over MQTT (the broker just relays ciphertext), but there’s an obvious privacy/traffic-analysis tradeoff to publishing your mesh’s existence publicly.Private/self-hosted broker — point your node config at your own Mosquitto instance or similar, useful if you want to bridge two physically separate mesh islands over the internet without exposing anything publicly.
Per-channel settings control uplink (mesh→MQTT) and downlink (MQTT→mesh) independently, so you can have a channel that only reports out, or one that’s fully bidirectional (letting internet-side traffic re-inject into the mesh).
2. What gets the node onto the internet in the first place The MQTT client has to run on a node that itself has IP connectivity:
WiFi-capable nodes (ESP32-based — Heltec V3, T-Beam variants with WiFi, RAK WisBlock with WiFi core) can join a local WiFi network directly and act as an MQTT gateway node.
Ethernet — RAK WisBlock with an Ethernet module (or similar) for a wired uplink, handy for a fixed gateway location.
Client-side bridging via the phone/desktop app — if you connect over Bluetooth/USB/TCP to a node from the Meshtastic Android/iOS/web app, the app itself can proxy MQTT over the phone’s internet connection rather than the node needing its own radio-side IP link. This is the common setup for a “portable” node that isn’t WiFi/Ethernet capable (e.g., most nRF52-based boards).
3. Downstream integrations Once traffic is on MQTT, it’s trivial to fan it out further — Home Assistant, Node-RED, Grafana dashboards, Discord/Telegram bots, APRS-IS gateways, etc. all just subscribe to the broker. There isn’t a native non-MQTT internet gateway path (no direct AREDN-style IP tunneling built into the firmware) — MQTT is the one blessed bridge point.
One caveat: Meshtastic firmware and MQTT topic/config details change fairly often between releases, and I can’t be certain everything above reflects the current firmware version. Worth a quick check of the official docs or a web search if you’re about to configure this — happy to search now if useful.
Claude Says About MeshCore Internet Connectivity…
(This AI answer is not vetted.)
MeshCore’s answer to this is quite different from Meshtastic’s — there’s no single blessed internet-bridge mechanism baked into mainline firmware. Instead it’s grown organically through third-party bridge tools, mostly modeled after Meshtastic’s approach but running as separate software rather than a first-class firmware feature.
1. Companion app connectivity (not really “internet,” but the base layer) Like Meshtastic, a MeshCore node can run in Companion Radio mode, connected to a phone/PC app over BLE, USB, or WiFi. This gets you a chat client talking to the mesh, but by itself it’s not an internet gateway — it’s just how you interact with a node.
2. Third-party MQTT bridges (the actual internet path) Since MeshCore itself doesn’t ship a native MQTT client in the way Meshtastic firmware does, the ecosystem has produced several separate bridge tools that sit between a MeshCore node and an MQTT broker:
meshcore-mqtt — a bridge service connecting to a MeshCore device over TCP, Serial, or BLE, with full MQTT client support including authentication, QoS, retention, TLS, and configurable event monitoring.
meshcoretomqtt — a Python script for sending MeshCore debug and packet-capture data to MQTT for analysis, intended to run on a Raspberry Pi or similar device connected to a repeater, useful for tracking a message’s path through multiple repeaters via its unique hash.
Meshcore-Repeater-MQTT-Gateway / EastMesh — custom repeater firmware forks with MQTT bridging built directly into the firmware itself (rather than an external script), including bidirectional forwarding, TLS, and NTP time sync required for TLS certificate validation.
3. “Observer” nodes — community mapping/analysis networks This seems to be MeshCore’s most common real-world internet use case. An Observer is a MeshCore node — repeater, room server, or companion device — that listens to nearby mesh traffic and reports what it hears to an MQTT broker over the internet, feeding regional community projects (ChiMesh, NashMesh, LetsMesh, etc.) for coverage mapping and reliability stats. Observers can be configured to share only advertisement packets so they show up on a node map without exposing message contents, and you can stop sharing at any time. Setup is either via a packet-capture install script on a companion device, or via custom observer-enabled repeater/room-server firmware from community builds.
4. Cross-protocol bridges to Meshtastic There’s at least one project, Akita-Meshtastic-Meshcore-Bridge, purpose-built to bridge between Meshtastic and MeshCore networks, enabling communication between the two, supporting direct serial connections plus MQTT as an external transport with per-channel mapping between the two systems.
5. Multi-protocol dashboards Tools like MeshMonitor unify things further — it can connect over TCP, Serial, or BLE to both Meshtastic and MeshCore nodes, and separately connect to MQTT brokers either as a read-only source or by running its own embedded broker with bidirectional bridges to public upstreams, letting you mix protocols in one dashboard rather than picking just one gateway path.
Bottom line vs. Meshtastic: Meshtastic has uplink/downlink MQTT as a native, documented firmware feature. MeshCore’s internet connectivity is more of a bolt-on layer — third-party bridge software or forked firmware, generally organized around either generic MQTT/IoT integration or community-run “observer” networks for mapping. This space is moving fast and fragmented across several independent projects (several updated within the last few weeks), so it’s worth checking each project’s repo directly before committing to one for a deployment.
Now I, and perhaps some of you now know that there are “Internet options” for Meshtastic and MeshCore, when that’s desired.
Please direct comments / feedback about this article to the Zero Retries email list with the hashtag #ZR0261. Paid subscribers can comment directly on the web version of this issue.
Update on KK7NQN AI Net Logger
By Hunter Inman KK7NQN
Editor’s Intro
This article was triggered by Tom Salzer KJ7T’s article in Random Wire 198 - Hunter’s Transcription Script:
I love the graphic, subtitled:
I don’t always listen to nets, but when I do, I like them transcribed!
I can’t always listen to a net, even when I really do want the learning that comes from hearing so many great questions and answers. Then I remembered Hunter Inman’s KK7NQN Transcription Logger project from the first Zero Retries Digital Conference and decided to give it a try on a spare AllStar node. Read Hunter’s overview at https://kk7nqn.net/. It is pretty amazing stuff.
However, getting it working required inferring some information and making some choices. A key choice for me was to use regular expressions instead of an AI for some transcription tasks. The system also tries to detect whether it has captured a net. Just like me, it does struggle with call signs.
Ultimately, I forked Hunter’s code and incorporated some fixes, including some new files. One of those was creating a simple transcript viewer web page. That saves me from having to SSH into the node and run a complicated MySQL query just to see a transcript. The Transcript Viewer lets me use date selectors to set a start and end date/time for the query. The query output is parsed into a table, and the transcript is downloadable as a text file.
Earlier this week KJ7T provided me a preview of his article and that caused me to reach out KK7NQN to mention Tom’s fork, and check in, in general. KK7NQN’s reply was a detailed update on his recent progress, with photos, and thus this article.
…
[Tom’s fork] is really cool to see. Thanks for sending it over!
I actually started on a second major rewrite of the system back in February, although I didn’t get the new version online until around late June. My available project time has been pretty limited lately.
What I find especially interesting about Tom’s project is that he and I seem to have taken the original system in almost completely opposite directions, which is really cool to see.
With the second version, I went much heavier on AI and autonomous operation. I still wanted to preserve the original “everything local” idea, so I built out two dedicated servers in a business location my wife and I own.
I’ve attached some photos of the servers I built out to handle the load of the new system.
One is essentially a full-time AI server, while the other is the central orchestrator that manages the radio nodes, scheduling, transcription pipeline, database work, and the rest of the backend.
The current system is running at:
https://kk7nqn.net/viewer.html
The central server is an HP ProLiant DL380 Gen9 with dual Xeon E5-2667 v4 CPUs and two RTX 3060 GPUs that handle Whisper transcription. The AI server is an ASUS ESC4000 with dual Xeon E5-2699 v4 CPUs, four Tesla V100 GPUs, and a RAID 0 array of four NVMe drives.
The new version also uses several monitoring AllStar nodes along with three separate SDR sites in Shelton, Potlatch, and Gig Harbor. The SDR sites run KA9Q-radio on Raspberry Pi 4s and feed audio back into the central system for transcription and processing.
Once I got everything running, I basically turned it loose. It has been operating essentially 100% hands-off since then, transcribing and processing several thousand transmissions per day on its own.
So while I ended up moving toward “throw a ridiculous amount of local compute and AI at it and make it autonomous,” Tom seems to be going the other direction: keeping the processing much more deterministic, digging through the original system methodically, finding bugs, fixing things, and documenting exactly how everything works.
I’m genuinely curious to see what he finds and what Parts 2 and 3 turn into. Seeing somebody fork the original project and take it in a direction that different from where I took version two is probably one of the coolest outcomes I could have hoped for.
And thanks again for having me demo it at ZRDC 2025. It’s pretty wild seeing how far the project has spread since then.
Editor’s Postscript
It’s just delightful watching the progress of KK7NQN’s project over the past year. I think it’s the ultimate validation of your work and that you documented it in public, adequately, when someone like KJ7T, in this case, uses your work in a way you never imagined.
In my big picture Zero Retries perspective, I think a synthesis of:
KK7NQN AI Net Logger,
RepeaterBook’s new capabilities to report on realtime repeater activity,
Advanced repeater capabilities such as IP400 and SuperPeater
are going to make Amateur Radio VHF / UHF repeaters even more of an Amateur Radio superpower. With a KK7NQN AI Net Logger, some (additional) embedded AI, the “see which is the most interesting repeater in my area” from RepeaterBook, and the extended capabilities of IP400 / SuperPeater means that NewTechHams can easily get on the air with modest equipment, in data modes, and see what folks on a repeater typically talk about, and join in on the one that’s the most interesting to them.
Kudos to both KK7NQN and KJ7T for their respective work on this concept!
Please direct comments / feedback about this article to the Zero Retries email list with the hashtag #ZR0261. Paid subscribers can comment directly on the web version of this issue.
Zero Retries - Tightening Focus to Data Communications
By Steve Stroh N8GNJ
The “big three” Zero Retries Interesting topics in Amateur Radio that don’t get much coverage in Amateur Radio media, and thus that I’ve tried to highlight in Zero Retries are Data Communications, Space, and Microwave Communications. Of late, I’ve rethought coverage of the latter two, primarily because those already have dedicated coverage.
Deferring Most Coverage of Amateur Radio Space to the AMSATs
For Space, there are the AMSATs of the world that are entirely oriented towards Space Communications, and many include their own publications, such as the AMSAT Journal. I wish that the “good stuff, such as AMSAT Journal was published for the benefit of Amateur Radio as a whole instead of solely for (paid) AMSAT members, but that’s their choice and I’ve decided to join ‘em rather than fight ‘em with independent coverage. That’s especially true since I’m not yet active on Amateur Radio satellites (other than the occasional passive reception) and the experts on technical aspects of Amateur Radio space are involved, and writing for, the AMSATs. The price of AMSAT (US) membership is reasonable, so I joined and thus have access to AMSAT Journal (including issues earlier than my membership) and I’m enjoying learning in more detail about Amateur Radio space communications.
Some Exceptions About Space That I’ll Continue to Cover in Zero Retries
Exceptions to the above:
It’s unfortunate to me that the AMSATs don’t cover the amazing projects of SatNOGS and TinyGS as receive-only ground stations dedicated to downloading telemetry from experimental satellites such as those built as school projects. I think that SatNOGS and TinyGS are particularly relevant to cover because they can be built and operated without an Amateur Radio license. For example, these can be projects of fans of STEM, Makers, Makerspaces, general interest radio technology organizations, schools, etc. Thus I’ll cover SatNOGS and TinyGS in Zero Retries.
The AMSATs don’t provide very good coverage of the data communications aspect of Amateur Radio in space, such as upcoming dedicated Amateur Radio data communications satellites (PACSATs). Thus, when I see something about data communications aspects of Amateur Radio in space, I’ll feature it in Zero Retries. An example is the story about the upcoming Pacsat emulation in a future version of software for the CubeSatSim in ZR > BEACON in this issue. I’ll also continue, as a paid member, to encourage AMSAT to consider dropping the paywall for access to AMSAT Journal.
The AMSATs don’t provide very good coverage of the potential of a second Amateur Radio payload in Geosynchronous Earth Orbit (GEO), hopefully covering at least portions of North America. Thus I’ll cover Amateur Radio GEO developments in Zero Retries. An example is the story from Open Research Institute in ZR > BEACON in this issue. There’s also very little coverage of data communications used on the QO-100 payload at GEO over Eurasia, so I’ll cover that in Zero Retries.
Earth Moon Earth (EME) aka Moonbounce / Lunabounce seems to be its own activity entirely separate from interest from AMSAT. That’s always seemed odd to me because the Moon / Luna is in fact a satellite orbiting Earth and ergo, EME is satellite communications - albeit highly specialized. EME used to be solely the province of those who could build and operate massive antenna arrays, 1 kW of transmit power on VHF or UHF, and slow Morse Code. In this era, EME is achievable with stations as modest as 100 watts of transmit power, an 11 element beam, and data modes optimized for EME. There are many disparate sites of good information for EME but no organization (that I’ve yet found). EME is interesting enough that I’ll probably continue to report on it in Zero Retries, especially “modest station” EME.
There are a handful of “big dishes” around the world that that incorporate regular Amateur Radio operation and often radio astronomy, such as those at MIT in Cambridge, Massachusetts, in Wall Township New Jersey, Colorado, and a number of others. I haven’t seen coverage of those in the publications of the AMSATs, so I’ll continue to cover them in Zero Retries.
Lastly, there’s no coverage of (what I consider) hobbyist / experimenter use of commercial (or government) Low Earth Orbit (LEO) and Geosynchronous Earth Orbit (GEO) communications satellites such as Starlink or HughesNet. Starlink is particularly interesting for experimentation given its mobility capability, the Starlink Mini unit (small size, easily mobile or portable, can be powered by batteries), and the Starlink Standby service for $10 / month for unlimited data transfer at 500 kbps. While there’s ample coverage of Starlink, that coverage is about using Starlink conventionally, and it’s usually puffed-up regurgitation of information published by Starlink. I think such capabilities are Zero Retries Interesting, and Amateur Radio adjacent, so you can expect ongoing coverage of Starlink in Zero Retries
Why Don’t I Write for AMSAT Journal? The Paywall!
It’s a reasonable question that if I’m going to devote energy to covering the above topics, why don’t I cover them for publications by the AMSATs? Simple answer - those publications are only available behind a paywall, and thus not readable by the vast majority of Amateur Radio Operators, and those interested in hobbyist space communications. Zero Retries is published without a paywall (paid subscriptions are entirely optional). If I’m going to devote time and energy to covering the above exceptions, I’m going to do so for the maximum benefit of Amateur Radio, not sequestered behind a paywall that can only be read by a comparative handful of folks.
That said… Like I recently discovered with ARRL’s publications, writing an article for a publication behind a paywall isn’t necessarily a binary choice. It’s (probably - I haven’t looked at AMSAT’s editorial policies) possible to write an article in Zero Retries and then offer it to AMSAT Journal, so now that I’m a member of AMSAT, I’ll consider that the next time I write a significant article about space for Zero Retries.
Post Publication Update - To be complete, AMSAT also provides AMSAT News Service Weekly Bulletins which is free to subscribe, and regularly feature short stories that are Zero Retries Interesting.
If you’d like more detailed information about Amateur Radio satellite activities that’s not behind a paywall, besides Zero Retries, I recommend the SARC Communicator. In that publicly accessible, bimonthly publication, Amateur Radio satellite news is featured regularly, often written by an Amateur Radio Operator active in satellite activity.
Deferring Most Coverage of Amateur Radio Microwave
Amateur Radio microwave communications also has a dedicated community… actually communities from indepenent, regional organizations and regional interest. That’s understandable because microwave communications and experimentation is inherently a local activity - microwave transmissions don’t travel very far terrestrially.
If one is interested in Amateur Radio microwave communications, and you’re within an area that has an Amateur Radio microwave communications organization - example San Diego, California has the San Bernardino Microwave Society, then you’re all set. If you’re interested in Amateur Radio microwave communications without a local community, you can “tap into” the existing communities and start one.
One exception to the above is that the Amateur Radio microwave communications organizations don’t seem interested in covering, or involvement in Amateur Radio microwave networking.
Since Amateur Radio microwave networking is inherently data communications, (even microwave networking for voice such as repeater linking is data), it falls squarely within the Zero Retries (newly narrowed) focus on Amateur Radio data communications.
Another exception is the potential of “Groundsats” - the idea of using wide(r)band transponders on Amateur Radio VHF / UHF bands such as are used on Amateur Radio satellites, but using transponders terrestrially such as mountains. I suspect that the Groundsat concept isn’t very popular because the most popular VHF / UHF radios don’t offer SSB operation that is required for (narrowband) use on transponders, but that is rapidly changing with the increasing availability of Software Defined Transceivers. Groundsats are rarely mentioned, so when I see coverage of Groundsats, I’ll feature them in Zero Retries.
Continuing Coverage of Software Defined Radio, Especially GNU Radio
Most of the general coverage about Software Defined Radio in Amateur Radio that I see is either:
Extolling the features of embedded SDR functionality that’s not modifiable by owners of radios with SDR functionality, and
Emulation of existing radio technology that was formerly done in hardware, now done better and less expensively using SDR.
But I rarely see any coverage of SDR in Amateur Radio media that explores what was not previously possible, or at least, not practical in Amateur Radio, but is now possible with SDR. An excellent example of something not previously possible with hardware radio technology, but now possible with SDR is ka9q-radio which allows simultaneous reception and decoding of individual portions of bandwidth (channels). Current Amateur Radio hardware or SDR paradigms “scan” (sequential reception of individual channels) or “bandscope” - displaying an large portion of spectrum but not receiving and decoding individual channels (until the operator selects a particular frequency).
I very rarely see any coverage of GNU Radio technology related to Amateur Radio, thus that’s a good fit for coverage in Zero Retries.
Other Zero Retries Interesting activities such as:
Low power operation (QRP),
Amateur Radio Television,
Digital Voice (VHF / UHF and HF [generally FreeDV RADE],
Amateur Radio Over Internet
Emergency Communications (EMCOM),
xOTA (whatevers On The Air)
Field Days
Unusual antenna systems, especially for VHF / UHF
… all have reasonable coverage in their own publications / communities -see Zero Retries Directory of Independent Open Amateur Radio Technical Media (recently updated with a number of new publications / communities).
I’m looking forward to Zero Retries being simplified and more focused on data communications.
Please direct comments / feedback about this article to the Zero Retries email list with the hashtag #ZR0261. Paid subscribers can comment directly on the web version of this issue.
The Use Cases of IP400 Networks
By Steve Stroh N8GNJ
IP400, the Advanced Mesh Network Controller (AMNC), OFDM-AB modulation… That’s all cool technology…
but in the big picture of Amateur Radio, what’s it good for?
The following is solely my opinion, independent of Alberta Digital Radio Communications Society (ADRCS), the developers / sponsors of IP400, and my involvement in IP400.
In the 21st century, with nearly ubiquitous mobile networks providing broadband speeds to devices we carry in our pockets, and very recently broadband communications anywhere in the world via satellite… Amateur Radio hasn’t had a “reasonable” data communications system / network that seems reasonably relevant.
Meshtastic / MeshCore
Meshtastic / MeshCore has become wildly popular as a radio communications technology that doesn’t require an Amateur Radio license to participate in and experiment with radio hardware. Within Amateur Radio, Meshtastic / MeshCore has become mildly popular.
My “armchair analysis” of the rapid and rabid uptake of Meshtastic / MeshCore is that it’s easy to experiment with (no license needed), low cost to participate, it works without much effort (lots of nearby nodes), there’s a welcoming community both online and locally, and it has some utility - a messaging system with no reliance on centralized systems or controllable by “bigcorps” or “biggovmint”.
But in the end, Meshtastic / MeshCore is a low data rate technology, and thus generally only usable for text messaging.
Packet Radio in Amateur Radio is Mostly Stuck at 1200 bps AFSK AX.25
The vast majority of Amateur Radio Packet Radio is still 1200 bps using Audio Frequency Shift Keying (AFSK) modulation, using the AX.25 protocol, with “wide area” networking done via digipeaters (and usually, digipeaters “tuned” to the very short packets of Automatic Packet Reporting System - APRS.
Yes, use of 9600 bps Frequency Shift Keying (FSK) using the AX.25 protocol is increasing thanks to it being a built-in mode of new radios like the Kenwood TM-D7502. But, the utility of 9600 bps doesn’t feature modern implementations of AX.25 such as Forward Error Correction and other improvements from the 21st century.
Pockets of Advanced Amateur Radio Data Communications
We have pockets of more advanced types of data communications, such as:
Post-publication Update: Internode links in NCPACKET are mostly faster-than 1200 bps (at least 4800 bps and often 9600 bps), and mostly using IL2P Forward Error Correction.
AREDN and other microwave networks,
New Packet Radio (NPR) and NPR 3.0,
VARA FM in conjunction with VarAC,
Icom D-Star Digital Data (DD),
But all of those suffer from some drawbacks / restrictions. AREDN and other microwave networks operate at microwave frequencies and thus subject to terrain / foliage issues. D-Star Digital Data is only available on a few high-end Icom radios operating on 1240 - 1300 MHz / 23cm. VARA FM and VarAC are closed source applications written for use on Windows, and only interoperable with some Packet Radio applications via VARA’s basic KISS interface.
To date, NPR and NPR 3.0 is the most “reasonably relevant in the 21st century” Amateur Radio data communications system in the 21st century. Its data interface is Ethernet, its networking protocol is TCP/IP, its data speeds are reasonable - 100 kbps - 1 Mbps, it operates on the 420-450 MHz / 70cm band3, it has a digipeater / repeater mode for wide-area use, and NPR 3.0 provides reasonable transmit power - 7 watts.
Another promising “reasonably relevant in the 21st century” option is AREDN replacement firmware ported to various hardware for the 902-928 MHz / 33cm band. Like NPR, Ethernet, TCP/IP, and reasonable data speeds. 902-928 MHz / 33cm offers reasonable foliage penetration, and reasonable range (more reasonable than microwave).
I’ve covered the details of IP400, the new OFDM-AB modulation, and the AMNC hardware in previous issues of Zero Retries, thus won’t rehash that in this article.
Again, What Can You Do With IP400? Text Chat Like Meshtastic / MeshCore.
Post-publication Update: Commenters on the Zero Retries email list suggested that Raven - the new text chat application running on AREDN nodes is worth mentioning in this context. Notably, Raven is compatible with AREDN, Meshtastic, and MeshCore networks. Hopefully when IP400 is shipping and getting deployed, support for IP400 networks could be added to Raven.
At a minimum, IP400 provides a reasonable alternative to Meshtastic and MeshCore operating in unlicensed spectrum that takes advantage of some of the unique aspects of Amateur Radio:
Like Meshtastic, IP400 provides integral autodiscovery mesh networking,
Like MeshCore, IP400 provides structured networking (repeaters) for wide area communications,
Like Meshtastic / MeshCore (LoRa), robust, reliable modulation,
Like Meshtastic / MeshCore, reasonable range with simple antennas (Amateur Radio has no transmit power restriction - 25 watt radios are common)
Thus, (again, at a minimum), IP400 can provide a network to offer very capable, very scalable, short text messaging / chat services the same as Meshtastic does.
One of the attractions of Meshtastic / MeshCore is portability:
There are many Meshtastic / MeshCore devices that can be carried on belt, backpack, etc., and
The “terminal” is often one’s mobile phone, with using an attractive, easy to use app.
That’s one use case that IP400 won’t immediately be able to provide a direct alternative - an Amateur Radio portable radio plus an AMNC will be bulkier than a portable Meshtastic / Meshcore device. But… watching the progress of the LinHT, it’s feasible that IP400 could eventually be available in a form factor similar to a LinHT
But in the “stationary” or “mobile” use cases, where the combination of a portable or mobile radio plus an AMNC isn’t an issue, IP400 would be completely competitive. Eventually there will be a IP400 converse app for mobile phones, tablets, or perhaps the AMNC operating on a Raspberry Pi could provide a compatible “host environment” to be able to use the same app as Meshtastic or AREDN’s Raven chat app.
Beyond Meshtastic / MeshCore…
From and infrastructure perspective, IP400 can go beyond Meshtastic / MeshCore:
Three big improvements beyond the above data communications modes:
Faster speeds - up to 70 kbps
Multi-tier networks - different bands, different frequencies can provide backbones.
Can interoperate with other Amateur Radio data communications systems such as Packet Radio, AREDN, NPR / NPR 3.0, and AllStarLink using TCP/IP and KISS.
IP400 Beyond Chat
The use cases of IP400 networks are closest in scope to AREDN networks, including:
File transfers in reasonable time (especially text-only like spreadsheets or HTML), including background updates of frequently updated files such as repeater lists, updates to Amateur Radio licensees, tactical maps, node maps updated daily, etc.
Firmware updates, including automatic or semi-automatic (user chooses to update, or not) of software for IP400 nodes. Like other systems of similar scope - example, an MMDVM hotspot, you can opt-in for automatic or semi-automatic updates of IP400 software for your IP400 node.
File transfer of audio files, or more recently, transcripts of audio files.
Email - individual and email lists.
Web servers / web browsers (especially simple HTML-only).
Flood bulletins.
Bulletin Board Servers / clients.
Voice Over Internet Protocol (VOIP) - provisionally - IP400 isn’t full duplex.
Extensions of wide area traffic handling / bulletins - regional handoffs from NTS and TPRFN to higher speed, high density / high participation IP400 networks.
Extension of APRS - port traffic from 1200 bps AFSK APRS on 144.390 MHz into IP400 networks - the difference in speed makes the APRS traffic a “light load” on IP400 networks, especially if aggregated (all traffic buffered for one minute, then ported into IP400 network).
Winlink - A local Winlink Radio Mail Server on HF can add a port to the local IP400 network to be able to cleanly route email to / from Internet email using the robust and well-developed Amateur Radio email handling capabilities of the Winlink system.
Community - Water Holes
Generally, IP400 networks can serve the same function, with data communications, as an active voice repeater does - be the infrastructure of an active and welcoming Amateur Radio community. Sometimes this functionality is described as a “water hole” (or in a more modern context, a water cooler) where folks naturally congregate, mingle, and communicate.
This isn’t an either / or - voice repeater or data communications. With the IP400 AMNC, you can do both, and they’re complimentary. For example, if you miss the nightly 21:00 net on your favorite repeater, the repeater club’s local KK7NQN AI Net Logger can email (or flood bulletin) a transcript of each night’s net.
Concluding
I think that IP400 Networks can potentially (there aren’t any, yet) provide a technically superior, more functional, and more accessible (to most Amateur Radio Operators) network system than previous Amateur Radio data communications networks… and Meshtastic / MeshCore networks.
Beyond that technical superiority, I think that IP400 networks can potentially provide a significant incentive for techies curious about experimenting with radio technology to get an Amateur Radio license and get involved in a local IP400 network to have fun and join the community that will (hopefully) form on such networks.
Further Reading:
Zero Retries 0033 - US Amateur Radio Data Network (In the 2020s) - USARDN
Please direct comments / feedback about this article to the Zero Retries email list with the hashtag #ZR0261. Paid subscribers can comment directly on the web version of this issue.
ZR > BEACON
By Steve Stroh N8GNJ
Short mentions of Zero Retries Interesting items.
Breaking! DigiPi 2.2 - Now Available!
Email from Craig Lamparter KM6LYW:
DigiPi 2.2 was just released with exciting new features and hardware support. The new Mercury HF winlink modem is loaded along side JS8Call “Improved”, and support for fully accelerated HDMI and mipi/DSI displays. These new displays look just like your cell phone with large/crisp/fast graphics.
In this video we are going to build a DigiPi from scratch and demonstrate some of the new modes including SMS, E-Mail, APRS, MercuryHF and JS8Call-Improved.
I’m suggesting a Pi3A+ as the new DigiPi base model for $25, and you can get a DSI display for $35. The Pi3A+ is readily available (unlike the Zero2W) and is an ideal platform when joined with a DSI 800x480 display.
All links and documentation may be found at
https://digipi.org/
The DigiPi software is available to Patrons of https://patreon.com/KM6LYW . Anything in the Patreon bucket gets you access to the DigiPi SD card - thank you for your continued support (and for making my videos ad-free!).
I think it’s a great idea to “graduate” DigiPi to be hosted on a Raspberry Pi 3B+ and the larger display format that’s formatted for a larger screen.
With this, I think the Mercury Modem data communications mode for HF now has an appliance for much easier use.
The Communicator: September - October 2026
Communicator Editor John Schouten VE7TI:
Welcome to the September-October 2026 issue of The Communicator. Dive into the latest issue of The SARC Communicator, a bumper edition brimming with technical innovation, operating field reports, and rich radio history for all levels of amateur radio.
A Blend of History and Innovation
This issue opens with a compelling profile of Sir William Stephenson, offering a deep dive into radio history. It then looks forward with “The Future of Morse Code Has a Call Sign,” exploring the enduring relevance of CW in the digital age. For those interested in cutting-edge technology, the feature on “FreeDV RADE” introduces a revolutionary new approach to digital voice over HF, leveraging machine learning for robust communication in noisy conditions.
Practical Projects and Operating News
Practical builders will appreciate “SARC’s NTP Clock Revisited,” which details how to achieve 14 display modes on a single ESP8266, and “Solving the USB charger problem… for good.” Operators can benefit from “An Almost Instant Visual Propagation Tool” and new hams will appreciate “Before You Press the PTT.” The “Radio Heroes on the International Pacific Highway” provides a historical account of the building of that roadway and the role amateur radio played. The issue also covers the latest in satellite news with “LEO satellite news: AMSAT in Canada” and “LEO.space.”
Community and Commentary
Editorial pieces like “Cheap ATV?” and “AI on the Air: Breakthrough, Shortcut, or the Next Tool in the Ham Shack?” provoke thought on the hobby’s direction. Community news includes “What’s New at DLARC,” “The New-Gen Ham,” and a profile of Zero Retries’ Steve Stroh N8GNJ. From “Hunting RF Interference” with the EMF Explorer to the return of packet radio with “New Packet Radio,” this issue is a comprehensive resource for every ham.
So power up, tune in, and turn the page—The Communicator has something for every communicator, now reaching 165+ countries.
The Communicator is the bimonthly newsletterzine of Surrey Amateur Radio Communications based in Surrey (Vancouver metro area) British Columbia, Canada. This issue is a “mere” 96 pages6. As always, this issue is a great mix of tutorials, history, operating tips, technology, and news about Surrey Amateur Radio Communications.
My column Zero Retries in this issue begins on page 66 - Networking, Networking, and More Networking. In this column I discuss IP400 / OFDM-AB / AMNC, LinHT progress, NPR-NG, and the new NA6D OpenTNC. All of those are topics that I’ve discussed in Zero Retries, but this is the “digest” version of those topics for the Communicator readership.
As VE7TI mentioned, I’m the subject of this month’s SARC member profile beginning on page 82:
Profiles of SARC members
Steve Stroh N8GNJ
presented by BLAKE R. WIGGS VA7BWG
I was surprised to see my profile run for four pages given that VA7BWG’s “interview” emails were a short series of questions, and I replied relatively tersely. VA7BWG dug into background information on Zero Retries to flesh out my terse responses. I’m pleased and humbled by the profile. Thanks Blake!
Pacsat Mode in CubeSatSim Software v2.3
The AMSAT Journal, July / August 2026 (paywalled), Educational Relations Update, by Alan Johnston, Ph.D., KU2Y V.P. Educational Relations:
We have some exciting software updates coming for the CubeSatSim! In the upcoming v2.3 software release, we will be adding:
Simulated Doppler shift where the transmit and receive frequencies change in real time, just like on a real satellite pass.
Pacsat Mode that works with the Pacsat Ground Station https://www.g0kla.com/pacsat/
Dashboard for controlling and monitoring your CubeSatSim using a web browser
Wi-Fi Hotspot for easy logging into the Pi Zero 2 and configuring your own Wi-Fi network
Support for Debian 12 “Bookworm.”
The second bullet - Pacsat mode is particularly interesting to me. At Hamvention 2026, I talked with AMSAT President Drew Glasbrenner KO4MA and explained to him that in my opinion, a standalone Pacsat node would be useful for terrestrial use as it overcomes several known issues in Packet Radio networks.
KO4MA was noncommittal about AMSAT making Pacsat components for non-AMSAT use, but did offer that there would soon be a Pacsat mode in the CubeSatSim. That info was not public at the time, and he asked me not to mention that until it was made public.
On the website Amateur Radio Station VETCP / GOKLA, AMSAT Pacsat Ground Station Software, there is a wealth of reference information on Pacsat technology such as:
PACSAT Protocol Suite - An overview
PACSAT File Header Definition
PACSAT Broadcast Protocol Used for directory broadcast and all downloads
PACSAT Broadcast Protocol Update 1 Errata
PACSAT Broadcast Protocol Update 2 The case for OLD and NEW dates on directory entries
PACSAT Broadcast Protocol Update 3 CL, BL file formats and the PBLIST destinations
Pacsat Protocol: File Transfer Level 0 Only used for Uploading Files, ignore Download logic
Pacsat Protocol: File Transfer Level 0 - Update
PACSAT Data Specification Standards
The legacy list of compression types
The legacy list of file types.
Codec2-mod Fixed-point, and in Rust!
Bruce Perens K6BP on a private email list (shared with permission):
I am experimenting with a re-implementation of codec2-mod done by Ai at my direction. I had the AI characterize the mathematical domains, there were three, and completely re-implement Codec2 in Rust, using fixed--point. This is an independent implementation observing only the algorithms of the original. The intent is to support M17 on hardware it would not run upon at present.
The codec is at https://github.com/BrucePerens/hams_open/tree/main/daemons/ham_digital_modes/src/codec2_3200
The C-language-compatibility layer is at https://github.com/BrucePerens/hams_open/tree/main/daemons/codec2_3200_capi
This should make it drop-in to M17.
Obviously, copyright means nothing any longer and people like myself with inadequate competence in a field can now direct a machine to do the work anyway.
Caveat - to date, this code is little-tested.
A followup to K6BP’s announcement by Wojciech Kaczmarski SP5WWP:
There is also this:
This is really cool to imagine M17 (which, remember, provides both digital voice and data), on simple(r) computing hardware that doesn’t support floating point.
M17 On Everything!
Cheap/Easy/Light GLOBAL E-MAIL Access! NEW!
Craig Lamparter KM6LYW / KM6LYW Radio on Patreon:
DL2MAN continues dominate the QRP world with not only the (tru)SDX 5-watt HF rig, but also a new standalone web/android Winlink/E-Mail/ARDOP software which leverages the built in cat/audio on a single USB cable! This is easily the cheapest and lightest HF email solution. SOTA operators rejoice! When grams count and your life is on the line, you have email access from anywhere in the WORLD!
https://dl2man.de/ARDOP/ NEW ARDOP Client
(tr)uSDX 5watt HF rig
https://www.ebay.com/sch/i.html?ssPageName=&_ssn=timortiz Antennas from N9SAB
DigiPi, possibly with trusdx usb support soon?
Danke Schoen Manuel!
See the YouTube video - preview not shown as this issue is already a bit too big for email.
(tr)uSDX support in DigiPi soon? That would be really cool and (more!) Zero Retries Interesting!
Ceefax Station — Teletext Pages Over AX.25 (M7TJF)
Email from Tobias Franklin M7TJF:
I saw your note on the IEEE Spectrum Spectel piece about wanting public ham-teletext code and people to try it on HF. I’ve been running something in that space from M7TJF.
BBC-style Ceefax pages over AX.25 AFSK1200, MIT licensed, with a public map of who’s transmitting and who’s actually decoding.
Live map: https://www.ceefaxstation.com
Code: https://github.com/thaum-labs/ceefax_station
The viewer works with no radio and no API keys. Windows installer or git clone. Alpha. Looking for people to experiment, especially TX/RX on HF or VHF.
I love Zero Retries Interesting projects like this!
SDRoxide - THE RADIO, REFORGED IN RUST
A powerful SDR transceiver client with a GPU panadapter, dual VFOs, neural noise reduction, built-in skimmers, a full stack of digital modes, Winlink radio email, 868 MHz sensor decoding, hands-free satellite operation and a live 3D space-weather globe — running native on Linux, macOS & Windows, or streamed to any browser.
SUPPORTED RADIOS
SDR Oxide supports everything from USB dongles, direct-sampling HF receivers, wideband IQ radios to network transceivers, dongle servers and CAT-controlled rigs — twenty interface families through pluggable backends.
The long list of radios isn’t easy excerptible, so here’s just a couple of common units to demonstrate the breadth of radios supported:
Native RTL-SDR
ADALM-Pluto
HydraSDR RFOne
MODES & MODEMS
Every mode runs in-process — native Rust modems, with the DRM receiver and the RADE codec linked into the binary. No external decoders, no virtual audio cables, nothing to wire up between programs.
The display is really attractive, and Rust seems to be the “new hotness” language of late.
The long list of modes isn’t easy excerptible, so here’s just a couple of common modes to demonstrate the breadth of modes supported:
JS8
Keyboard conversation on FT8’s waveform. All four speeds, JS8Call-compatible.
PACKET
AX.25 at 300 baud on HF sideband, 1200 and 9600 on FM — with a frame monitor and a KISS server for other software.
I’ll guess that both the radios and modes can easily be expanded.
My thanks to Jeff Davis KE9V for (very enthusiastically) bringing this development to my attention for inclusion in Zero Retries.
Dragon Labs CR-8 - An 8-channel Coherent SDR That Doesn’t Sacrifice Performance
New project on Crowd Supply:
Dragon Labs CR-8 is a high-performance, yet affordable, 8-channel coherent SDR receiver. It is capable of 8 MHz per channel with 12 bits of dynamic range and can tune anywhere from 25 MHz to 1750 MHz. That’s more channels, more bandwidth and more dynamic range than the KrakenSDR, giving you more capability.
It can operate with all 8 channels coherently, or with an arbitrary set of coherent and noncoherent groups. This can be used for example to be coherent on two frequency bands at once by having one set of channels tuned to one frequency, and the others to another frequency. If desired, all channels can even operate completely independently while remaining perfectly synchronized in time.
…
Hardware
Channels: 8
Bandwidth: 8 MHz per channel
Sample Depth: 12 bits
Tuning Range: 25 MHz to 1750 MHz
Coherence: Any combination of channels, up to all 8.
Phase Error: Less than 1° at 1750 MHz (More measurements necessary)
Timing Error: Less than 100 ps
Coherent tuning time: 25 to 50 ms Expected to be reduced to under 10 ms
Onboard Oscillator: TCXO, 2.5 ppm over -20°C to +85°C (-4°F to 185°F)
This is cool - 8 receivers @ 8 MHz bandwidth for each receiver, all coherent.
So finally we have the the fabled “All North America VHF / UHF bands” single unit Software Defined Radio Receiver:
Receiver 1 - 50-54 MHz
Receiver 2 - 144-148 MHz
Receiver 3 - 219-220 and 222-225 MHz
Receiver 4 - 420-428 MHz
Receiver 5 - 428-436 MHz
Receiver 6 - 436-444 MHz
Receiver 7 - 444-450 MHz
1 receiver for… whatever!
Open Research Institute (ORI) Presentation at futureGEO Community Workshop at HAMRADIO 2026
Michelle Thompson W5NYV in Inner Circle Newsletter Summer 2026:
ORI’s Presentation
Michelle Thompson was the third and final presenter at the workshop, speaking on behalf of ORI’s futureGEO proposal team. ORI is a signatory to the letter of interest (LOI) from AMSAT-DL, participated in the 2025 futureGEO Workshop at AMSAT-DL Symposium, and has submitted a one-page proposal as well as a white paper about ORI’s proposed design. Both of these documents can be found in the futureGEO GitLab as well as at the above links.
Michelle described the working hardware, firmware, and software implementations of Haifuraiya, or “High Flyer”. Haifuraiya is a functional prototype digital regenerative multiplexing amateur radio satellite system, with superior voice quality and integrated voice, text, and data. There are three implementations of the Opulent Voice ground station, and two implementations of the satellite segment. Processing occurs in the satellite. This is not a double-hop system. Uplink is frequency division multiple access Opulent Voice and downlink is DVB-S2 time-division multiplex. The design is carefully engineered and tested, completely open source, and fully documented.
Link - Poster PDF of ORI’s Haifuraiya Digital Satellite System Concept
Haifuraiya’s uplink is 5 GHz, and downlink is 10 GHz. The 5 GHz uplink seems a natural fit for ScaleRF / QuadRF - if it’s powerful enough to do EME, it can do GEO. Unfortunately, I’ve not seen any mention of the potential of using QuadRF with Amateur Radio satellites (except Luna).
TAPR Annual Membership Meeting and Board of Directors Elections
Staną Horzepa WA1LOU on various TAPR email lists:
ANNUAL MEMBERSHIP MEETING
TAPR’s Annual Membership Meeting will be held via Zoom on the afternoon (3 PM EDT, 1900Z) of October 24, 2026. It will run up to two hours. At the meeting, TAPR officers will discuss the current and future state of the organization and will answer questions and comments from the membership.
Nominations for three director positions may be made at this meeting. Anyone who is a member of TAPR can ‘throw their hat into the ring’ and stand for election. If there are more than three nominees, there will be an election by email, following the meeting.
Information on how to access the meeting will be posted on our website approximately one week before the meeting. You do NOT have to be a member to attend.
CALL FOR NOMINATIONS
Three Director positions on the TAPR Board of Directors are now open for nomination and nominations may be submitted now.
TAPR Board members serve three-year terms and their responsibilities include:
1) Attendance at the in-person board meeting that is held at Hamvention in May.
2) Regular participation in the continuous board session, which is conducted over the Internet.
3) Active engagement in TAPR’s management.
To place a person in nomination, please remember that he or she must be a member of TAPR. Also, confirm that the individual is willing to have his or her name placed in nomination. Send that person’s name (or your own if you wish to nominate yourself ), call sign, mailing address, e-mail address, phone number(s), and a biographical sketch (250 words maximum) via contact@tapr.org or via snail mail to TAPR, 1 Glen Ave., Wolcott, CT 06716-1442, to arrive BEFORE October 24, 2026. Nominations can also be made during the October 45th Annual Membership Meeting via Zoom.
An online election will be held from November 7 to November 20, 2026, using ElectionBuddy, if a vote is required.
Website announcement for 2026 Annual meeting:
https://tapr.org/annual-membership-meeting-2/
Website announcement for 2026 Board of Directors Nomination and Elections:
https://tapr.org/call-for-nominations-3/
Happy 50th to PRnet, ARPAnet, and Internet!
Greg Skinner on the Internet-history email list:
50th Anniversary of the First TCP Demonstration
By Don Nielson
Transmission Control Protocol (TCP) is the lifeblood of the Internet. It is the protocol, first defined in 1975, that enabled computer networks of dissimilar nature to seam together in ways invisible to its end users. That transparency and dissimilarity would extend over time to virtually all transmission media. It would also cover the world with a new, affordable web that would bring digital capability to everyone. Although bringing forth the modern Internet involved innumerable far-flung talents, there was one place and time where the Internet first saw the light of day—and SRI was involved.
It was August 27, 1976, and the new DARPA-funded packet radio project, the first mobile digital radio network, was linked through the 7-year-old wired ARPANET to its only hosts speaking TCP, one each in Boston and Los Angeles. The initiating terminal was in the West Bay foothills, and the bridge was the first TCP internetworking gateway located at SRI. Both the ARPANET and the PRNET had lots of contributors that made the connection possible, but SRI was the place of convergence for the PRNET, as it had been earlier for the ARPANET. testing had come to the point a real-life demonstration.It was Ron Kunzelman, one of the SRI leaders in PRNET development, who suggested Rossotti’s (now Alpine Inn, also known to locals as Zott’s), a popular watering hole in Portola Valley, west of the Stanford campus. SRI’s mobile bread truck van, containing both a packet radio and a TCP-housing microprocessor, had radio visibility from Rossotti’s to a PRNET repeater node atop the ridge on which also sat the big SRI-Stanford dish. It was one radio relay to the gateway and satisfactory for the two networks to work fully in tandem.
The task chosen for the test was the delivery to DARPA of the monthly progress report on the PRNET, a very lengthy transmission. The test/demo was successful, and we buttoned up. It was just a slightly more noticeable day in SRI research that was promptly forgotten. Fortunately, and with little anticipation, I took a few pictures.
Almost exactly two decades later, as the digital world and the Internet blossomed, the inquiries began to appear around its genesis. One of these came to me from the IEEE Spectrum, and I was forced to dig out what I could find. In short, it led to that day at Rossotti’s and to a bigger demo that also included a satellite link and other gateways.
Somewhere along the way, a small bronze plaque appeared on the wall at Rossotti’s commemorating that event, later to be replaced by a larger one, shown here, placed now on the front of the building by the California Historical Society, according to a Rossotti’s manager at a recent event. The event saw me taking a few visiting relatives to lunch there, where I written story of that day. The aim was also to give the somewhat blustery account on the plaque some grounding. For my effort, I am now the proud owner of a Rossotti’s cap and not much else, except serendipitous memories. 50 years have gone quickly.
My thanks to Joe Hamelin W7COM for bringing this development to my attention for inclusion in Zero Retries.
Please direct comments / feedback about ZR > BEACON to the Zero Retries email list with the hashtag #ZR0261. Paid subscribers can comment directly on the web version of this issue.
Request To Send
By Steve Stroh N8GNJ
Editorial, Commentary, and Occasional Digressions
ZRDC 2026 Ho!
Zero Retries Digital Conference (ZRDC) 2026 will be here before we (I) know it.
6 weeks until Zero Retries Digital Conference 2026
on Friday, October 16, 2026,
in San Ramon, California, USA.
N8GNJ For TAPR Board of Directors
After serious consideration, I’ve decided to nominate myself for a position on the TAPR Board of Directors. I’ve previously served on the TAPR BoD.
More details in a near future issue of Zero Retries.
Weekends Are For Amateur Radio!
Tina and I and our two cats Fiona and Shrek have decamped to a hotel room in Vancouver, Washington for a couple of weeks. We want to be close to Grandchild #1 (impending, as of publication date) and Grandchild #1’s parents. I packed a ridiculous amount of deferred projects that were “packable”, including a number of projects I want to demonstrate at ZRDC 2026, such as the new OpenTNCs mated and working with some inexpensive portable radios. And yes, one of them is the loaned MeshCore unit.
Have a great weekend, all of you co-conspirators in Zero Retries Interesting Amateur Radio activities!
Please direct comments / feedback about Request To Send to the Zero Retries email list with the hashtag #ZR0261. Paid subscribers can comment directly on the web version of this issue.
73,
Steve N8GNJ
Closing Thanks
My ongoing Thanks to:
Tina Stroh KD7WSF for, well, everything!
Jack Stroh, Late Night Assistant Editor Emeritus
Fiona and Shreky Stroh, Late Night Assistant Editors In Training
Founding Members who generously support Zero Retries financially:
Founding Member 0000 - Steven Davidson K3FZT (Renewed 2026, 4th year!)
Founding Member 0001 - Randy Smith WU2S (Renewed 2025, 3rd year!)
Founding Member 0002 - Chris Osburn KD7DVD (Renewed 2026, 4th year!)
Founding Member 0003 - Don Rotolo N2IRZ (Renewed 2026, 4th year!)
Founding Member 0004 - Bill Arcand W1WRA (Renewed 2026, 4th year!)
Founding Member 0005 - Ben Kuhn KU0HN (Renewed 2025, 3rd year!)
Founding Member 0006 - Todd Willey KQ4FID (Renewed 2025, 3rd year!)
Founding Member 0007 - Merik Karman VK1DF / VK2MKZ (Renewed 2026, 4th year!)
Founding Member 0008 - Prefers To Remain Anonymous 08 (Renewed 2025, 3rd year!)
Founding Member 0009 - Prefers To Remain Anonymous 19 (Renewed 2025, 2nd year!)
Founding Member 0010 - Merik Karman VK1DF / VK2MKZ (Renewed 2025, 3rd 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 - Chuck Hast KP4DJT (Renewed 2026, 2nd year!)
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)
Founding Member 0026 - Prefers To Remain Anonymous 32 (New 2026)
Numerous Annual and Monthly subscribers who also generously support Zero Retries financially!
You thousands of readers of Zero Retries without which there would be little point in publishing this newsletter.
The Usual Administrivia
Zero Retries About - www.zeroretries.org/about
Zero Retries Digital Conference - www.zeroretries.org/p/conference
Zero Retries (Substack Blanket) Privacy Policy - substack.com/privacy
Zero Retries Reprint / Reuse Policy - www.zeroretries.org/p/reprint-reuse
Fair Use - All excerpts from other authors or organizations, including images, are intended to be fair use and are fully attributed generally by author and link (URL).
Paid Promotional Content - Unless otherwise noted in the article or item, advertisement, or sponsorship notice, Zero Retries does not include paid promotional content. Exceptions:
Advertisements in Zero Retries,
Sponsorships in Zero Retries,
Zero Retries products,
Zero Retries events
Features and content exclusive to paid subscribers.
Zero Retries 2026 Index - www.zeroretries.org/p/index-2026
Zero Retries Archive - archive.org/details/zeroretries?sort=-date
⬅️⬅️⬅️ Previous Issue of Zero Retries | Next Issue of Zero Retries ➡️➡️➡️
Zero Retries 0261 was published on 2026-09-04. This issue was 10,577 words.
Footnotes For This Issue
To see the relevant sentence for the footnote, just click the footnote number.
I think the humorous Amateur Radio term for a grandchild is “subharmonic” as children of Amateur Radio Operators are humorously termed “harmonics”.
Just… astonishing… that the Kenwood USA Amateur Radio site doesn’t yet mention the TM-D750A. Kenwood folks… It’s for sale and is already in buyer’s hands!
NPR 3.0 also has versions for 144-148 MHz / 2m and 1240-1300 MHz / 23cm.
Except NPR / NPR 3.0 and (in development) NPR-NG
Obviously mesh networking is a feature of Meshtastic / MeshCore, and “kind-of” a feature of Packet Radio for those advanced nodes that implement Net/ROM / TheNET capability.
It’s not uncommon for issues of The Communicator to be more than 120 pages.
A big thank you to Hunter Inman KK7NQN and to Steve Stroh N8GNJ for their very kind words about my fiddling with Hunter's net transcription scripts. It has been a lot of fun to play with Hunter's first version, and his second iteration looks simply amazing!