Zero Retries 0155
2024-06-07 — 1800+ Subscribers, What Stalls Amateur Radio Development?, FlexRadio - APIs Include “Run In The Radio”
Zero Retries is an independent newsletter promoting technological innovation that is occurring in Amateur Radio, and Amateur Radio as (literally) a license to experiment with and learn about radio technology. Now in its third year of publication, with 1700+ 1800+ subscribers.
About Zero Retries
Steve Stroh N8GNJ, Editor
Jack Stroh, Late Night Assistant Editor Emeritus
In this issue:
Web version of this issue - https://www.zeroretries.org/p/zero-retries-0155
Request To Send
Commentary by Editor Steve Stroh N8GNJ
1800+ Subscribers!
In Zero Retries 0153, a mere two issues / weeks ago, Zero Retries achieved 1700+ subscribers. Now Zero Retries has 1800+ subscribers!
Welcome, new subscribers, to Zero Retries!
Nice Mention of Zero Retries on Amateur Radio Workbench
This rush of subscriptions was due in part to Zero Retries receiving a mention from George Zafiropoulos KJ6VU on his popular podcast - Amateur Radio Workbench, Episode 209:
The other one I want to mention is a blog called Zero Retries by Steve Stroh, N8GNJ. And Steve is really a super accomplished digital VHF UHF expert. And he's participated in various organizations like [TAPR] and made publications and delivered papers and is just a real authority around digital radio stuff.
And he's got a fantastic blog called Zero Retries. So go to zeroretries.org.
My thanks to Dave Cherkus, N1AI in the Zero Retries 0153 comments for mentioning KJ6VU’s shout out.
(Zero Retries didn’t make it into the show notes of HRWB 209 which is why I wasn’t initially aware of it.) Zero Retries is now mentioned in the HRWB 209 show notes.
That prompted me to do a bit of long-neglected housekeeping to the Closing the Channel section at the end of every Zero Retries. In addition to:
These blogs and newsletters regularly feature Zero Retries Interesting content:
and
These YouTube channels regularly feature Zero Retries Interesting content:
I’ve now added:
These podcasts regularly feature Zero Retries Interesting content:
Ham Radio Workbench by George Zafiropoulos KJ6VU (and friends)
(And will add other podcasts that regularly feature Zero Retries Interesting content as I identify them.)
Nice (Extended) Mention of Zero Retries in Hot Iron Newsletter
Zero Retries also got a nice (extended!) mention in HOT IRON #125.
* Similarly, Zero Retries has articles of interest:
- #140: Pwr Amp suitable for Software Defined Transmitters, AI in electronic warfare
- #152: Teensy SDR project, Photon Radio (!)
- #151: The Modern Ham, Raspberry Pi, Stuff You Should Know
- #150: MJF wind down, more
- #149: Jam-resistant Ukranian drones, new designs, IPv6
- #148: Meshtastic, Meshmail, more
- Look at the archived issues for much more
This issue of Hot Iron (The Journal of the Constructor’s Club) was largely references to websites and other publications, etc. and the majority are Zero Retries Interesting. Hot Iron is free, delightful to read every quarter, and recommended!
That mention reminded me to do another bit of long-neglected housekeeping to add Hot Iron to the Closing the Channel section at the end of each Zero Retries:
These blogs and newsletters regularly feature Zero Retries Interesting content:
Hot Iron - The Journal of the Constructor’s Club is a delightful quarterly newsletter.
Paid Subscribers Update
My thanks to Prefers to Remain Anonymous 31 for becoming a Paid Subscriber to Zero Retries this past week!
My thanks to Prefers to Remain Anonymous 32 for becoming a Paid Subscriber to Zero Retries this past week!
Financial support is a real vote of confidence for continuing to publish Zero Retries.
Major Conference Countdowns
HAM RADIO 2024 in Friedrichshafen, Germany on 2024-06-28 thru 30, in 03 weeks!
JARL Ham Fair 2024 in Tokyo, Japan on 2024-08-24 and 25, in 11 weeks!
See other events at the Zero Retries Guide to Zero Retries Interesting Conferences.
M17-Users email List Off to a Great Start
The M17-Users email list is off to a great start with 75 subscribers to date. We’re self-educating each other on topics relating to getting M17 more widely out into the real world. One example is the current thread about M17 (Wide Area) repeaters? where I learned that Bridgecom sells an off-the-shelf MMDVM option for its repeaters.
73,
Steve N8GNJ
What Stalls Amateur Radio Development?
By Wojciech Kaczmarski SP5WWP
w.kaczmarski@teletra.pl
An open letter exposing the current state of the amateur radio world, and roadblocks on the way to making it technologically up-to-date.
Warsaw, June 2024
Background
I’ve been a licensed amateur radio operator since 2016. In 2019, I started the M17 Project (1), a highly successful and widely acclaimed international endeavor. A few years later, in 2021, I was honored with the ARRL Technical Innovation Award for my contribution to the technical development of our hobby (2). M17 has become a large, overarching ecosystem, offering both software and hardware, open-source solutions (3). Through this time, I have worked with many people from all around the world. Most of them were exceptionally brilliant, but since M17 is based on volunteers’ work, our team members rotated constantly.
The current status of Amateur Radio
It’s not a secret that most of the amateur radio community depends on large companies (Icom, Yaesu, Kenwood) and solutions they provide. The status quo is all about keeping hardware and software proprietary, minimizing users’ chances to modify it. While there are new models of radios being advertised all the time, they do not offer anything new. This keeps the amateur radio world in a state of artificially sustained technological stagnation, short-sightedly throttling down the progress in order to maximize someone’s profit. It’s been already shown that community-driven projects can lead to technological advancements - the advent of MMDVM (4), M17, OpenRTX (5), WPSD (6), OpenWebRX (7), and many others. The purpose of this open letter is to show that cutting-edge, open-source solutions can only be successfully proliferated by a group of skilled amateur radio developers.
Stock, commercial firmware mostly lacks functionalities amateur radio operators seek. The reason behind that is simple - large corporations often don’t have a clue what amateur radio operators want. A solution to this seems very simple - let skilled users write their own replacement firmware, then release it under an appropriate open license, for the rest to use. Sounds easy, but as always, there’s a catch. The firmware flashing process is not always easy (binary files are almost always obfuscated) and requires a fair amount of reverse engineering effort.
The most popular digital voice mode is DMR (8) (looking at the users count and radio infrastructure size). It had to be adapted for ham radio use cases, as it was originally designed for professional use. DMR is based on an open standard released by ETSI. The standard by itself does not mention what voice coder should be used, but the de facto protocol seen “in the wild”, enforced by manufacturers, uses AMBE.
Linking radio access networks (RAN) using IPv6 and geostationary satellites and utilizing remote radio units (RRU) with powerful I/Q modems is without a doubt a technological advancement. Wouldn’t it be amazing to see Daniel Estevez’s (EA4GPZ) 32APSK modem (9) “move out” from the shacks of a few and be used in real hardware and by hams worldwide? Or at least in the QO-100’s footprint? This is just the tip of an iceberg of ideas to implement in the real world. We can’t just passively wait and expect major manufacturers to pick up on it. It is something we can do on our own.
The pitfalls of volunteer-based work
Volunteering is a wonderful work model - you get excellent, qualified workforce for free. It allowed many amazing projects to appear - MMDVM, OpenRTX, WPSD, M17, to name a few in the amateur radio community. There is a big problem behind it though - volunteers can rarely be bound with any obligations or time constraints. This also means no one can have any expectations against volunteers. They can be distracted, their reliability and commitment can span from anything between extremely enthusiastic to hardly interested. It is understandable that people prioritize tasks in their lives - family and daily job is by far more important for most of us than hobby-related projects (10).
This reveals the first issue of volunteer-based work: the difficulty of scheduling work when there aren't reliable resources available (11). Moreover, one’s good will is not enough to maintain focus on the less fun and more administrative sides of the project. Lifespan of a project can be short regardless of the level of technological advancement offered, due to lack of workforce.
Second issue relates to long term commitment required for sophisticated projects. Many complex functions require more than one person to be involved (12). This implies project management, reporting, planning and documentation, tasks seldom attractive for volunteers. People come and go, leaving unfinished tasks behind. The turnover rate varies mostly between days and, more rarely, months.
A volunteer-powered project works well when each task can be handled by a single person and when there are not too many interconnections with other functional blocks or submodules. This, of course, only applies with the assumption that there are no deadlines or other expected time constraints. The project basically has to “live its own life”, at its own pace, dictated by its contributors.
Third issue is maintainer burnout (13), widespread in the open-source community. Volunteering contributors come and go, but maintainers bear the long-term responsibility for the project's health and sustainability. This burden grows quickly with the project's popularity, leading to a form of burnout that leaves maintainers with emotional exhaustion and a decreased sense of accomplishment. One of the major contributors to maintainer burnout is loneliness (14).
As mentioned by Artem Sapegin (15):
“Open source became a synonym of free labor, not just free code, and it’s not only harmful for the whole community, but mostly for the maintainers of open source projects.”
The seemingly free labor suddenly turns expensive in terms of management and commitment sustenance.
In conclusion, this reasoning shows the difficulty of foreseeing a project's future in terms of development, funds management and allocation. That also makes any granting request process extremely hard or even unfeasible, leaving the following questions open:
Why are there so few developers paid for their work?
Is there an entity out there having enough funds and willing to change this?
“They all want, but do not commit”
Project’s followers usually have brilliant ideas and provide valuable feedback, but when it gets to implementation, suddenly everyone turns impotent. There are also those affected with severe non-committal disorder, who still keep repeating that they "would love to help", but for some reason nothing ever fits their specializations. Frequently, empty promises appear. Sooner or later, ideas are written off as “not having enough developers to implement” - there’s simply no one to perform the required task - an inherent developer shortage. Most projects just don’t have enough staff (are under-resourced) (16). This causes frustration and breaks down existing developers’ morale - they are overwhelmed by the number of pending tasks to do.
Another example is the shortage of educational and explanatory materials created by the community, despite the fact that the community has enough knowledge to create it.
For this exact reason, most subprojects are run by a single person, or mostly by a single person [vide: M17 specification document (17), WPSD (18), the Remote Radio Unit (19), OpenRTX (20)]. This burden causes significant emotional stress, easily deteriorating the lone developer's psyche. The effect is further amplified by the pressure coming from the user base, with its never-ending requests and expectations (21).
A possible solution
To be a real threat to the aforementioned status quo and bring amateur radio back to its open-source tinkering roots, it is not enough to rely on volunteers, as this model is too inefficient for large, high-impact projects. There is a significant, consistent effort required to provide the critical mass needed to bring products to market.
Justification
There are some good examples of companies that are the owners of open-source products (22). They all have paid staff to drive the vision and schedule for products, while maintaining good relationships with volunteers contributing to the projects. There must be a clear vision of the for-profit company to help align the volunteers who wish to remain incidental contributors.
Monetary profit is a human motivator that can be used to push the state-of-art forward faster than it would otherwise move. There seems to be a wide assumption that technology will continue to improve, however, that is not a certainty. Hiring an engineer who believes in the goals and vision of the organization relieves the pressure for the individual to have to work elsewhere to earn a living. The engineer’s priorities will naturally align with the priorities of the organization. This will help the organization to consistently drive to keep striving.
To sum it up, financial support:
allows contributors to stay focused on tasks (strong monetary incentive)
allows the team to make necessary purchases - equipment, licenses, etc.
makes management easier, as the workforce allocation can be adjusted
fixes timeframes for tasks
makes work efficient by making human resources engaged over extended periods of time.
Potential pitfalls
There should be no apologies for making a profit as this allows the organization to increase R&D efforts and add individuals to the engineering workforce. It can be a difficult transition from a non-profit volunteer based organization, as misunderstandings and hurt feelings can occur. However, by ensuring the vision is communicated clearly to the entire organization, both paid and volunteers, many of the issues are avoided.
Footnotes:
M17 Project’s homepage - https://m17project.org
M17 Project’s repositories - https://github.com/M17-Project
Multimode Digital Voice Modem - https://mmdvm.com
OpenRTX project’s homepage - https://openrtx.org
W0CHP Pi-Star Dashboard - https://w0chp.radio/wpsd/
Homepage - https://www.openwebrx.de/
https://www.repeaterbook.com/repeaters/niche/index.php?mode=DMR
https://destevez.net/2021/05/32apsk-narrowband-modem-for-qo-100
https://networkingnerd.net/2024/04/26/on-open-source-and-volunteering
IARU “Shaping the Future” programme - https://storage.iaru-r1.org/index.php/s/DAtTorPyFaNFdXK/download?path=%2FInput%20documents%20incl%2 0amendments&files=ZL23_C3_54%20Shaping%20the%20Future%20programme.docx&downloadStartSecret= 5bs5djy8c13
https://stackoverflow.blog/2021/01/07/open-source-has-a-funding-problem
https://opensauced.pizza/blog/the-lonely-journey-of-open-source-maintainers
IARU “Shaping the Future” volunteers and contributors - https://storage.iaru-r1.org/index.php/s/DAtTorPyFaNFdXK/download?path=%2FInput%20documents%20incl%2 0amendments&files=ZL23_C3_59%20Shaping%20the%20Future%20volunteers%20and%20contributors.docx &downloadStartSecret=9qjobuk5o3v
https://repo.w0chp.net/WPSD-Dev/WPSD-WebCode/commits/branch/master
https://en.wikipedia.org/wiki/Business_models_for_open-source_software
FlexRadio - APIs Include “Run In The Radio”
By Steve Stroh N8GNJ
An update on the ability of FlexRadio units to run non-FlexRadio software in the radio - putting the (User) “Software Defined” into FlexRadio units. And a few impressions of the updated FlexRadio Maestro Control Console.
In Zero Retries 0153 - FlexRadio 8000 Series HF Radios - Even More Capable… Except for FreeDV, I took FlexRadio to task for not including the FreeDV mode as a feature of these new, more powerful radios:
No matter what the “advanced features” of the FlexRadio 8000 series, the lack of FreeDV as a native feature in SmartOS, is (in my mind) a significant failing on the part of FlexRadio. That FlexRadio can’t, or won’t, implement such a fundamental (in the mid 2020s) new mode says to me that FlexRadio is focused on the past of Amateur Radio:
Emission Modes - USB, LSB, CW, RTTY, AM, Synchronous AM, FM, NFM, DFM
RTTY isn’t quite a century old; but the rest of those modes are more than a century old.
At SEA-PAC 2024, I spoke to a person knowledgeable about FlexRadio who clarified a major point in my understanding of user customization of current FlexRadio units and current versions of FlexRadio’s SmartSDR software (the operating system of the radio units).
I did know that FlexRadio provides an Application Programming Interface (API) that allows external devices (and software running on external devices) to integrate with a FlexRadio, allowing those external devices / software to “appear native” on a FlexRadio. This capability is apparently implemented via the SmartSDR TCP/IP API. This is how the EZDV external unit is currently able to integrate with FlexRadios to operate FreeDV on a FlexRadio unit, such as shown in the illustration below:
Waveform API
When I explained my perspective that FreeDV should be able to run on the (sophisticated, powerful, Software Defined) FlexRadio units, the person knowledgeable about FlexRadio explained that FlexRadio offers another API, that allows software to run on the radio - the Waveform API:
For those wishing to experiment by creating their own digital mode or waveform, FlexRadio Systems offers the SmartSDR Waveform API. The Waveform API allows developers to create their own digital modes and integrate directly into SmartSDR. When a waveform module is loaded, the module registers with SmartSDR and delineates the modes it supports. These modes are then available in the standard mode selection interface inside SmartSDR. The operator simply selects the mode and beings operating. The Waveform API exchanges commands and status with the developer written waveform module as well as streaming samples. Completed modes may be run both outside and inside the radio with virtually no changes!
OK, now we’re talking! That sounds like exactly what was needed to implement FreeDV as a “native” mode on the radio. But, the person knowledgeable about FlexRadio disclaimed that because FreeDV is constantly being iterated, FreeDV is a “moving target”, and thus a low priority for FlexRadio to implement as a native mode in SmartSDR.
But, again, the Waveform API is there for anyone to use, such as FreeDV’s developers.
Thus, my understanding of this issue settled out into good news / bad news points:
Good News - The FlexRadio Waveform API exists, and could, in theory, makes my “ask” of adding FreeDV as a “native” mode on a FlexRadio unit / Smart SDR, running on the radio actually possible.
Bad News - The person knowledgeable about FlexRadio said that basically there isn’t enough (remaining) computing power on the current FlexRadio 6000 series units to actually add FreeDV (or other modes) as native modes via the Waveform API. (Almost all of the computing power of the FlexRadio 6000 series is now used to run the native SmartSDR functions.) Thus, adding FreeDV to FlexRadio 6000 units can only be implemented externally via the EZDV or equivalent unit (where the FreeDV processing happens outside the FlexRadio unit).
Good News - The newly announced FlexRadio 8000 units1 with …
4x the CPU power of the 6000 series and twice the performance in the FPGA over the FLEX-6000 series…
Will easily accommodate (again, per the person knowledgeable about FlexRadio) incorporation of FreeDV (and more) to run on the 8000 series radios.
Bad News - With the introduction of the FlexRadio 8000 series, the FlexRadio 6000 series is now obsoleted (but still highly functional, and very good HF radios).
Good News - The FlexRadio 8000 series is now the standard (only) product line available from FlexRadio, and it looks like FlexRadio maintained (at least, approximately) the same price points as the FlexRadio 6000 series.
So… apparently, my initial plaint about the FlexRadio 8000 series - that they wouldn’t / couldn’t run FreeDV (and other data modes) on that new radio product line… will be possible after the FlexRadio 8000 series begins shipping in August, 2024.
It probably won’t be FlexRadio that will implement FreeDV (and other modes) natively on the FlexRadio 8000 series, but apparently it’s doable by others via the FlexRadio Waveform API.
…
The New FlexRadio Maestro Control Console is Gorgeous!
At SEA-PAC, FlexRadio was showing off pre-production units of the FlexRadio 8000 series, along with the current (second generation?) version of the FlexRadio Maestro (Remote) Control Console. I… liked… the original Maestro Control Console… but I love the (new) current version of the Maestro Control Console. Apparently I was so infatuated with it I didn’t take a photo of it - argh! (The photos of the new Maestro on the FlexRadio website don’t do it justice.) The newer Maestro was just so… bright… and high resolution, and seemingly larger. It was just… compelling! When I (likely) purchase a FlexRadio unit, I will definitely purchase the Maestro Control Console.
Excellent job on the new Maestro, FlexRadio!
ZR > BEACON
By Steve Stroh N8GNJ
Short mentions of Zero Retries Interesting items.
44Net VPN Beta Test Open for Applicants
Rebecca Key KO4KVG on the ARDC:44Net email list - 44Net Update, June 7, 2024:
For those of you interested in being a beta tester for the 44Net VPN, reach out to Adam at adam@ardc.net to get set up!
My email has been sent! Kudos to ARDC for finally getting to this point with the 44Net VPN project.
How the Army Handled D-Day Communications
The Allied invasion of continental Europe 80 years ago was a logistical tour de force. Its success hinged on an operative communications network unifying the invading armies and their support systems.
The U.S. Army Signal Corps, or “SigC,” was tasked with establishing massive, reliable, multi-channel high-speed voice and “data” networks. These networks would support a mission buildup of more than a million troops in a hostile environment.
That meant two-way voice circuits to keep decision-makers in touch and high-speed channels to exchange reconnaissance photos and situation maps evaluating the impact of aerial and ship-launched ordnance.
SigC’s design baselines were high capacity and agility, with low latency. Communications with the beach had to be established speedily using whatever gear made it to shore in the contested landings. The system had to be mobile: radio supplemented by ad-hoc wire telephony. Contact within operating units had to survive when troops mistakenly landed in one another’s sectors.
SigC had estimated it would need some 90,000 transmitters for the job. This mandated frequency coordination. The radios were largely short-range “hand-helds” but also included short- and medium-distance radio links to naval and air elements and Allied headquarters.
This is an excellent Zero Retries Interesting article by Mark Durenberger in RADIOWORLD, appropriate for the 80th anniversary of D-Day yesterday.
My thanks to Amateur Radio Weekly Issue 333 and Frank Barnes W4NPN (Hot Iron [Newsletter] Co-conspirator) for a special issue of Hot Iron Newsletter that alerted me to this story.
EggNOGS Antennas in Beta Test
Mark (Smitty) Smith N6MTS of Halibut Electronics is developing an easy kit (see the link for photos) for constructing an inexpensive, receive-only (at present) Eggbeater antenna. Eggbeaters are omnidirectional antennas where the energy (or receive focus) is focused “up” instead of “out” to better receive signals from satellites whizzing by overhead. The basic EggNOGS design has been proven out, but improvements are being made to the instructions, and correcting a few minor issues. EggNOGS kits will likely be available for sale in the next few months. The purpose of EggNOGS is to help construct SatNOGS stations for receiving telemetry from research satellites such as cubesats built and launched by university students or other small, not-for-profit project entities that don’t have global infrastructure to receive telemetry from their satellite.
Apparently the tricky bit about building your own eggbeater antenna is getting the phasing harness correct for developing the desired directivity of the antenna. N6MTS figured out that a printed circuit board would help with the most demanding parts of an eggbeater antenna, with only some small coax, and some wire (such as solid copper household interior electrical wire) to build your own low-cost eggbeater antenna. There will apparently be several versions of EggNOGS for specific frequencies depending on your desired satellite reception.
N6MTS has discussed the development of EggNOGS on the Ham Radio Workbench podcast and the Halibut Electronics support email list.
TheModernHam Blog - Zero Retries Interesting Articles
Billy Penley KN4MKB of Modern Ham YouTube channel and TheModernHam Blog has pushed out a streak of Zero Retries Interesting articles lately:
Host your own FCC Ham Radio Database for Offline Use with HamDB
Connect to a Packet Radio BBS Node with KISS or AGWPE TNC Windows/Linux
And those… were all written / posted in May, 2024!
KN4MKB’s energy (and breadth of Zero Retries Interesting knowledge) is inspiring!
Note that you can subscribe to TheModernHam newsletter (one email per month, summarizing blog articles) in the lower right corner of the blog.
Kudos KN4MKB!
Pico SDR (I have never built a radio before.)
From the blog nanoseconds of curiosity:
As a software developer I have had my share of building networking applications. Even ones that made use of WiFi or cellular networks. But I have never really understood how those radios worked at the level where software met the electromagnetic field.
I have looked into some of the lower frequency, DIY amateur stuff. Everyone seemed to be building “Manhattan-style” analog boards. That was putting me off, because I am rather clumsy with my hands, lack the patience to carefully “dead-bug” solder the parts and most importantly, I don’t really find circuits without a programmable controller attractive enough.
On the transmitting side, it ends up being fundamentally pretty simple. Just toggle a GPIO pin at the correct frequency, connect piece of wire as an antenna and get on the air. Besides the desired signal, you will pollute the spectrum with a lot of unwanted harmonics and mixing products, so add a filter or use more pins to shape your signal to more closely resemble sine wave. There is a lot more to it, but most of the complexity lies at the receiving end.
Receivers are hard.
How would one even go about building a digital receiver? And I am not talking about buying a ready-made module and connecting it to an Arduino. How would one even begin building a receiver using general purpose microcontroller from scratch?
Surprisingly, it has been done and documented multiple times before. Some super smart people who have actually made radio receivers using FPGA and some passives have left the breadcrumbs for us to follow.
The only issue is that their FPGA always had a high speed comparator to use as a 1-bit ADC. And the chip I currently enjoy messing around with does not have one. So how would one build a digital radio receiver using RP2040, heart of the Raspberry Pi Pico?
This is a different approach to building a software defined radio, and the author explains their learning progression very well.
My thanks to Jenny List and Hackaday for mentioning this article.
ARDOP added to HF [BBS] Backbones
Jeff Mein KP3FT on the EastNetPacket email list:
If anyone's interested, N3MEL and I have added the ARDOP mode to our HF backbone setup. It's a good mode for anyone who doesn't want to use VARA, plus it is Linux-native (as well as Windows). I'm using the latest ARDOPCF version which was released a few days ago. Glenn N3MEL is using the oriogional ARDOP. They're compatible with each other.
…
There's some good info here on the older ARDOPC version: https://www.cantab.net/users/john.wiseman/Documents/ARDOPC.html
If you want to try the latest version, the downloads are here: https://github.com/pflarue/ardop/releases/tag/1.0.4.1.2
They're stand-alone binaries, so no installation is required. Just put in in any folder and run it from there. The Linux version needs to be made executable in permissions before running it. Also, renaming the download to just "ardopcf" makes things easier. It's command line in Linux and Windows, so in my case I use for Linux:
ardopcf -G 8514 8515 plughw:1,0 plughw:1,0
and for Windows, I use:
ardopcf -G 8514 8515 USB USB
The -G 8514 switch enables a web browser interface (127.0.0.1:8514) that shows a nice waterfall and some settings. 8515 is the default ARDOP port for BPQ, Winlink, etc. to link to.
The command-line will be different for others, depending on your setup. USB USB works fine in WIndows if you're using only one USB sound device for digi-modes. In Linux, the plughw:1,0 plughw:1,0 is my USB sound device. The plughw:1,0 plughw:1,0 forces 12000hz sampling since ARDOP works better with that rate.
Make sure your radio's filter passband audio is at least as wide as ARDOP's bandwidth, otherwise ARDOP will show "BUSY". ARDOP can use four bandwidths: 200, 500, 1000, and 2000. We're using 1000 since it allows decent BPS speed but still without being very wide. 200 is way too slow for forwarding BBS mail.
The only ARDOP-interfacing I'm familiar with is BPQ and Winlink, no idea what's possible with interfacing it with, say, JNOS or others.…
Oops, I left out KN4LQN in Virginia. He's also running the new ARDOPCF on his node, backbone-linked the N3MEL. It's not strictly Eastnet, but we're using HF to link some Eastnet to some BPQ and JNOS nodes and vis-versa.
Latest ARDOPCF release: https://github.com/pflarue/ardop/releases/tag/1.0.4.1.2
The developer is looking for users to give feedback.
VARA works great, but some folks don't want to use closed-source, proprietary or non-Linux modes, so ARDOP is a good alternative to use for HF backbones.
Wow… sounds like ARDOP is now evolving quickly to be an open source alternative to VARA HF for reasonably fast data communications on Amateur Radio HF.
Open Headset Interconnect Standard (OHIS)
Open: Any individual or company may make devices compliant with this standard, with no obligation.
Headset: Describes the signaling commonly found between a user and a radio: Microphone, Headphones, and Push To Talk.
Interconnect: Describes both the physical and electrical connection of those signals between the user and radio.
Standard: Devices built to this standard will work with other devices built to the same standard.
Introduction, The Elevator Pitch
The Amateur Radio community has standards for DC power (13.8v +/- 15%, Anderson Powerpole connectors, etc) and RF (50 ohm coax, PL-259/BNC/SMA connectors, etc). But we have no such standards for the interface between the user and the radio. Is the microphone a dynamic, or electret? Is it balanced, "pseudo" balanced, or unbalanced? Is the audio out from the radio at speaker level, headphone level, or line level? Is it push-pull, or ground referenced single ended? Is push-to-talk (PTT) triggered by a contact closure to ground, completing the Mic loop, or by a serial digital command?
There are so many different standards for microphone, headphone, and PTT that it is improbable that one could take their preferred headset and connect it to any radio without an adapter. In a multi-user environment, such as a club shack, Field Day type event, or an EOC, they would need a full-mesh of adapters to ensure any user can connect their own headset to any radio: O(N^2) adapters.
With the Open Headset Interconnect Standard, or OHIS, the club/EOC can build/buy one adapter for every radio which stays with that radio, and the user only needs to build/buy one adapter for their specific headset which stays with their headset, and now they can achieve full interoperability with only O(N) adapters.
This standard builds on the work done by Tom Tengdin WB9VXY, with his Proposed ARES Standard Headset. This standard is different than his proposal in a few places to make it more generalized, and provides more detail and clarity around several points.
Mention of OHIS is one of way too many “deferred too long” topics to I intended to mention in Zero Retries. (I gotta clear out that backlog, somehow.) I met Mark (Smitty) Smith N6MTS of Halibut Electronics at SEA-PAC 2024, and seeing the HE products on display reminded me of the excellent work (and energy) N6MTS has put into OHIS including offering OHIS products based on the Open Source OHIS standard.
Three Zero Retries Interesting Mentions in Amateur Radio Weekly Issue 333
2024: Ham Radio in China, Soon Chinese Hams in Space
A group that accounts for only 1/10,000 of the country's population – Amateur Radio enthusiasts.
We (at least in the US) just don’t hear much about Chinese hams. We know they exist and this answers a few questions. There have been a number of interesting Chinese Amateur Radio systems put into space in the last few years.
…
So what's all this HaLow Long-Range WiFi about then?
HaLow or IEEE 802.11ah protocol are starting to edge into the realm of affordability.
Amateur Radio data communications in the 902-928 MHz band is “a fertile area for development”.2 I hope to feature an interesting article on this subject by a highly qualified guest author in Zero Retries soon. The link is to a (typically good, conversational) Hackaday article, which links to a great YouTube video by Andreas Speiss (HB9BLA, though this is his “non Amateur Radio” YouTube channel).
…
A History of Amateur Satellites and Project OSCAR
A detailed history of Amateur Radio satellites from 1961-2003.
This is really good, and as ARW says, detailed! A bit sad that it doesn’t continue through the present day. Kudos to Steve Bible N7HPR for compiling this.
…
Kudos to Cale Mooth K4HCK - he’s doing a great job of sourcing Zero Retries Interesting mentions in Amateur Radio Weekly and Amateur Radio Daily! Both recommended!
FDIM 2024 - zBitx - Bringing CW into the 21st Century by Asher Farhan VU2ESE
I’ve only watched this video in spurts and skipping around; I haven’t watched it all the way through (though I will).
VU2ESE has a refreshing approach to his (proposed? prototype? future product? - not sure) zBitx radio (of which there is no other mention on the web, that I can find), which despite the prominent mention of CW, will actually support SSB and some data modes. He makes an interesting (and, highly relevant, in my opinion) case for a “CW” radio to include FT8 as a fast, automated way to “sound” the bands to insure that the radio and antenna are working. I think that’s the best argument for an automated method of making contacts, similar to WSPR / WSPRnet, to be able to rapidly and iteratively test antennas, radios, modifications, changing antenna orientations, etc.
This is yet another Zero Retries Interesting development coming out of (adjacent to) Hamvention 2024 that hasn’t been widely mentioned.
My thanks to Garth Kidd VK2TTY on Mastodon for mentioning this video.
kissutil - Man Page - KISS TNC troubleshooting and Application Interface
kissutil can be used interactively for troubleshooting a KISS TNC. It is usable with direwolf and other generic KISS TNCs connected to a serial port. It can also be used as an application interface where each side places files in a directory for the other to process. See User Guide for more details.
Given the very wide usage of KISS in Amateur Radio applications, this utility might be very handy for troubleshooting when KISS… isn’t quite so simple.
Apologies, I didn’t record the source of this mention.
Feedback Loop
Of late, limited editing time for Zero Retries hasn’t permitted me to provide excerpts of comments in previous issues. That said, comments have been very (and delightfully) active and informative in recent issues of Zero Retries! Comments in these issues are still open:
Comments in earlier issues of Zero Retries are now closed.
If you provide feedback via email, I may excerpt your feedback or include it in full. Unless you specifically grant me permission to include your name, I won’t do so. Feedback may be lightly edited for clarity.
Join the Fun on Amateur Radio
If you’re not yet licensed as an Amateur Radio Operator, and would like to join the fun by literally having a license to experiment with radio technology, check out
Join the Fun on Amateur Radio for some pointers.
Zero Retries Frequently Asked Questions (FAQs) — In development 2023-02.
Closing the Channel
In its mission to highlight technological innovation in Amateur Radio, promote Amateur Radio to techies as a literal license to experiment with radio technology, and make Amateur Radio more relevant to society in the 2020s and beyond, Zero Retries is published via email and web, and is available to everyone at no cost. Zero Retries is proud not to participate in the Amateur Radio Publishing Industrial Complex, which hides Amateur Radio content behind paywalls.
My ongoing Thanks to:
Tina Stroh KD7WSF for, well, everything!
Founding Members who generously support Zero Retries financially:
Founding Member 0000 - Steven Davidson K3FZT
Founding Member 0001 - Prefers to Remain Anonymous 01Founding Member 0002 - Chris Osburn KD7DVD
Founding Member 0003 - Don Rotolo N2IRZ
Founding Member 0004 - William Arcand W1WRA
Founding Member 0005 - Ben Kuhn KU0HN
Founding Member 0006 - Todd Willey KQ4FID
Founding Member 0007 - Merik Karman VK2MKZ
Founding Member 0008 - Prefers to Remain Anonymous 14
Founding Member 0009 - Prefers to Remain Anonymous 19Numerous Annual and Monthly subscribers who also generously support Zero Retries financially!
Want to Support Zero Retries?
The most effective way to support Zero Retries is to simply mention Zero Retries to your co-conspirators that are also interested in knowing more about technological innovation that is occurring in Amateur Radio and encourage them to become a fellow subscriber.
One particularly effective method of promoting Zero Retries is to add a mention of Zero Retries to your QRZ page (or other web presence) and include a link:
If you’d like to financially support Zero Retries, becoming a paid subscriber is greatly appreciated and helps offset expenses incurred in publishing Zero Retries. Paid subscriptions for Zero Retries are entirely optional, as explained in this special issue of ZR:
Zero Retries Administrivia - Activating Payment Options.
These blogs and newsletters regularly feature Zero Retries Interesting content:
Dan Romanchik KB6NU mentions “Zero Retries Interesting” topics so regularly on his blog (that I otherwise wouldn’t know about) that I’ve bestowed on him the honorific of Pseudostaffer.
Jeff Davis KE9V also mentions “Zero Retries Interesting” topics so regularly on his blog (that I otherwise wouldn’t know about) that I’ve bestowed on him the honorific of Pseudostaffer. (As of 2024-06-01, KE9V’s blog seems to be on hiatus.)
Amateur Radio Weekly by Cale Mooth K4HCK is a weekly anthology of links to interesting Amateur Radio stories.
Experimental Radio News by Bennet Z. Kobb AK4AV discusses (in detail) Experimental (Part 5) licenses issued by the US FCC. It’s a must-read-now for me!
RTL-SDR Blog - Excellent coverage of Software Defined Radio units.
TAPR Packet Status Register has been published continuously since 1982.
Hot Iron - The Journal of the Constructor’s Club is a delightful quarterly newsletter.
Other Substack Amateur Radio newsletters recommended by Zero Retries.
These YouTube channels regularly feature Zero Retries Interesting content:
HB9BLA Wireless by Andreas Spiess HB9BLA
KM6LYW Radio by Craig Lamparter KM6LYW (home of the DigiPi project)
Modern Ham by Billy Penley KN4MKB
Tech Minds by Matthew Miller M0DQW
These podcasts regularly feature Zero Retries Interesting content:
Ham Radio Workbench by George Zafiropoulos KJ6VU (and friends)
Zero Retries is currently using the Substack email publishing platform to publish Zero Retries. It’s particularly suitable for small newsletters as you can get started for no cost.
If you’re reading this issue on the web and you’d like to see Zero Retries in your email Inbox every Friday afternoon, just click below to join 1800+ other subscribers:
Please tell your co-conspirators about Zero Retries — just click:
Offering feedback or comments for Zero Retries is equally easy — just click:
If you’re a fellow smart person that uses RSS, there is an RSS feed for Zero Retries.
Social Media:
Zero Retries (N8GNJ) is on Mastodon — n8gnj@mastodon.radio — just click:
Zero Retries (N8GNJ) is also on Bluesky — @n8gnj — just click:
Email issues of Zero Retries are “instrumented” by Substack to gather basic statistics about opens, clicking links, etc.
More bits from Steve Stroh N8GNJ:
SuperPacket blog — Discussing new generations of Amateur Radio Data Communications — beyond Packet Radio (a precursor to Zero Retries)
N8GNJ blog — Amateur Radio Station N8GNJ and the mad science experiments at N8GNJ Labs — Bellingham, Washington, USA
Thanks for reading!
Steve Stroh N8GNJ / WRPS598 (He / Him / His)
These bits were handcrafted (by a mere human, not an Artificial Intelligence bot) in beautiful Bellingham (The City of Subdued Excitement), Washington, USA, and linked to the Internet via Starlink Satellite Internet Access.
2024-06-07
Blanket permission is granted for TAPR to use any Steve Stroh content in Zero Retries for the TAPR Packet Status Register (PSR) newsletter (I owe them from way back).
Blanket permission is granted for Amateur Radio use of any Steve Stroh content in Zero Retries for Amateur Radio newsletters and distribution via Amateur Radio such as (but not limited to) Packet Radio Networks, Packet Radio Bulletin Board Systems, Repeater Nets, etc.
In such usage, please provide appropriate authorship credit for the content.
If you’d like to reuse an article in this issue for other uses, just ask.
All excerpts from other authors or organizations, including images, are intended to be fair use. Unless otherwise noted in the article, there are no paid promotional items in any Zero Retries articles.
Portions Copyright © 2021, 2022, 2023, and 2024 by Steven K. Stroh.
Footnotes For This Issue
Oddly, there is still no press release by FlexRadio in their News section with the specifics of the improvements of the 8000 series over the current 6000 series. But apparently there was a press release - PileupDX mentioned it - The Next Generation of SDR Solutions to the Amateur Community.
Very fertile area for development; I’ve lost count of the attempted, and failed, projects doing Amateur Radio data for 902-928 MHz.
I think the theme of this issue is "interoperability."
I was recently visiting my parents. Dad's got a fairly substantial antique radio collection. One of his more prized pieces is an Atwater Kent Model 10 he restored, which is a "breadboard" radio where the components are screwed to a wood base and wired up. Radios used to be called sets because all the components needed to be assembled before you could use it (although I believe the Model 10 was sold as a complete unit). This modular approach to radio design is still normal, just that the components are microscopic now. Sure, the process allows for some amazing tech to be squeezed into a tiny package, but at what cost? I recently decided to do a little rig consolidation and picked up a Kenwood D75. I'm not as happy with the purchase as I would have liked (I knew Bluetooth wasn't going to pair with iOS, but why won't it pair with my car either?). But again, the point was to sell on a few older radios and combine D-Star and APRS/Packet into one device, along with SWL. I really haven't gained much functionality, just consolidation.
But do I need a radio that has all that packed into an almost pocketable package? What if the engineers were tasked with fitting all that and more into a box the size of an FT-817 or KX3? Would the design be able to be adaptable? Would there be an option for an expansion bus? Or a much larger battery, paving the way for a more powerful processor? Sure, it wouldn't look like an HT. And maybe that's important. Maybe even a deal-breaker for many/most hams.
What if the radio was a simple base unit (a breadboard) that had standard interconnects between modules? Sure, it might not be pure enough for some, but breaking down the radio into different modules would allow for small groups or individuals to work on their projects, assuming they could throw the signal to the next device in the path. And hams would only have to get used to thinking about, for example, buying a 5 watt amp that isn't a complete unit, but will be able to fit into the cavity available. Or having a robust interface running on the smart device they already are carrying around anyway? Why add more speakers and microphones to your hip, even if they only add a few cents to the product? But then is it still an HT? Will the community put up with a box that doesn't have knobs and keypads and a color display? Even though they already have one of the most well designed and thought out devices in history in their pocket already?
Anyway, don't want to turn this into a pitch. Just a few thoughts I've had recently.
Awesome article by SP5WWP, and I completely agree. As it turns out, a company still has to earn enough money, somehow, to pay salaries and overheads. There lies the rub: how to earn money. There is a Darwinian process that weeds out tasks that cannot be monetized, regardless of how interesting, useful or innovative. Many of us are not good businesspeople, so volunteer work is the only affordable option, even at the expense of personal health.
I don't have a solution, but of course I'd like to see one (or more).