Zero Retries 0211
2025-07-18 — MMDVM Versus M17, Comments to FCC re: AST SpaceMobile Claiming 430-440 MHz For Its Use Are Due Monday 2025-07-21
Zero Retries is an independent newsletter promoting technological innovation in and adjacent to Amateur Radio, and Amateur Radio as (literally) a license to experiment with and learn about radio technology. Radios are computers - with antennas! Now in its fifth year of publication, with 2800+ subscribers.
About Zero Retries
Steve Stroh N8GNJ, Editor
Email - editor@zeroretries.net
On the web: https://www.zeroretries.org/p/zero-retries-0211
Substack says “Too long for email”? YES
In this issue:
Request To Send
MMDVM “Versus” M17
Disclaimer - I’m a Fan of Both G4KLX / MMDVM and SP5WWP / M17
M17’s Alleged Deficiencies, Compared to Other Digital Voice Systems… Isn’t a Valid Comparison
The Aftermath of G4KLX’s Decision to Remove Support for M17 from His MMDVM Software
The Long Term Fallout of G4KLX’s Decision to Remove Support for M17 from His MMDVM Software
Zero Retries Boilerplate
Permission for Reuse of Zero Retries Content
Keywords for this Issue
Footnotes for this Issue
Comments for This Issue (redirect to Comments page)
Request To Send
Commentary by Editor Steve Stroh N8GNJ
Paid Subscribers Update
My thanks to Merik Karman VK1DF / VK2MKZ for renewing as Founding Member Subscriber 0007 to Zero Retries this past week (for the third year)!
Founding members are listed in every issue of Zero Retries!
My thanks to Prefers to Remain Anonymous 38 for one year of being a Paid Subscriber to Zero Retries as of this past week!
Financial support from Zero Retries readers is a significant vote of support for the continued publication of Zero Retries.
# # #
Comment Period Open for Three More Days re: AST SpaceMobile Claiming 430-440 MHz For Its Use - Last Day is Monday 2025-07-21
Please see the article in Zero Retries 0210 about this. Please say something!
My apologies that I couldn’t offer my comments in advance in this issue. If my hands uncramp to the point where I can finish my comments on Saturday in time to do some good for you Zero Retries readers, I may push out a special issue with just that.
Also, in my last comment submission was a subtle test. I submitted my comments on the last day of the comment period within the specified date… but after business hours in the Eastern Time Zone (where Washington, DC is located). Thus for one’s comments to be recorded as being receive by the specified date, they have to be received no later than normal business hours (ending at 17:00 Eastern?) in Washington, DC.
# # #
Bets on Steadily Improving Technology Are Generally Good Bets
I had an interesting conversation this week regarding the future of “hard coded” voice CODECS (Coder / Decoder) such as Codec 2 versus the amazing capabilities of RADE (Radio Autoencoder - Machine Learning) in FreeDV.
Codec 2 is well established and can be easily implemented in the processors of typical radios. For example, it’s the CODEC used in the M17 Open Source Digital Voice / Data system for Amateur Radio VHF / UHF.
However, RADE shows enormous potential and flexibility and it was recently ported from software run on a typical Windows / Mac / Linux desktop class computer… to a Raspberry Pi 5, as demonstrated at Hamvention 2025.
Thus it’s evident from those host computer requirements that RADE is compute intensive. To most engineers working on radio systems for Amateur Radio VHF / UHF, that “rules out” RADE for “practical” use because it’s more compute intensive than what’s feasible on typical microcontrollers used in portable radios. The thinking goes that compute capability of that class isn’t practical - too expensive, not efficient enough (heat, etc.), and especially consumes too much power.
In my opinion, that’s a technically valid, but historically invalid perspective.
Look at the history of Blackberry. Their devices were well optimized for the environment of that moment - small form factor, excellent battery life, economical data communications suited for narrowband data communications on mobile networks.
But in conceiving the iPhone (video), Apple saw the bigger trends - more capable processors with more memory (enabling a much more sophisticated operating system distilled from the Mac), and emerging broadband data networks. Apple bet on technology continuing to improve exponentially and they were proved right.
One of the lesser noted aspects of the iPhone versus Blackberry, in my opinion, was the power budget of the iPhone was greater because Apple invested in new generations of higher capacity batteries. Imperfectly matched at first - the battery life of the first few iPhones wasn’t great, but mobile device battery technology has improved to the point where my iPhone 13 rarely dips below 50% battery capacity in typical daily use.
I had a similar moment last night (see next article) where we were discussing how capable that typical, cheap microcontrollers are in this era. I related my surprise discovery that in the (now discontinued) TNC-Pi9k, there was no conventional audio interface chip or even a DSP chip. A Teensy 3.6 microcontroller was used, essentially “bit banging” the incoming and outgoing data signals. That was a better approach than using a conventional audio interface or a DSP.
Those trends, writ large, I think… can… apply to Amateur Radio. We’ve already got several portable (battery powered, embedded display) Software Defined Radios. Thus implementing RADE in a portable or mobile radio isn’t out of the question, in my opinion. We just have to be willing to try to keep trying to live up to…
Amateur Radio as (literally) a license to experiment with and learn about radio technology
# # #
Ham Radio Workbench Podcast Episode 242
Tina KD7WSF and I spent a delightful few hours this week being interviewed (and going down numerous “ratholes” (their term) with the crew from the Ham Radio Workbench podcast - George Zafiropoulos KJ6VU, Vince d'Eon VE6LK / AI7LK, and Mark (Smitty) Smith N6MTS. Our interview will be Episode 242 which will be available on Tuesday, 2025-07-29.
The primary reason for our interview on HRWB was to discuss the Zero Retries Digital Conference but there was lots of fun discussion about this newsletter, what’s on my workbench (including my “virtual workbench” solution), and lots of other fun discussion; the time just flew by.
# # #
Single Topic Issue of Zero Retries This Week
Despite a few interesting developments this week, and some “double duty” of my regular volunteer work at a charity, and our chat with the good folks at HRWB, I’m just wrung… out… “butt numb”, cramped hands from so much typing in one stretch… about the MMDVM versus M17 issue, working behind the scenes all week, then writing this issue. That I’m publishing this so late on Friday is indicative… this issue is all I’ve done all day today (Friday).
As I began this article, it was obvious that the single topic would consume the entire issue. Thus, frustratingly, I decided I had no choice but to punt many paragraphs of several interesting articles in progress into the next (I hope) issue of Zero Retries. This situation has absorbed effectively all of my available writing time this entire week, mostly with private emails to individuals and groups trying to explain my perspective about this development… and candidly, to damp down the sense of panic in the small M17 community.
That includes making little progress on formulating my comments to the FCC about AST SpaceMobile’s use (and grant of experimental license)1 of the 430-440 MHz band.
Until this week, I would have never have envisioned writing such an article / issue. But, I feel that someone has to attempt to provide a balanced perspective of the realities of this situation, in some depth.
Thus I’m forgoing the usual other sections of Zero Retries such as ZR > BEACON, comment summary, etc. They’ll return next week.
# # #
Weekends Are For Amateur Radio!
Have a great weekend, all of you co-conspirators in Zero Retries Interesting Amateur Radio activities! I’ve got to make some progress on the projects I named during the HRWB interview.
Steve N8GNJ
MMDVM “Versus” M17
By Steve Stroh N8GNJ
That headline might be considered inflammatory… but that’s the distilled reality of the situation that has developed this week.
TL:DR - When many (many…) folks learned over the course of this week that support for M17 had been dropped from MMDVM, they considered that announcement to be, if not the effective death of M17, at minimum, the “beginning of the end of M17”.
In my opinion, that’s not the case. While that development certainly handicaps the progress of M17… I don’t consider this development to be “THE END OF M17”.
Disclaimer - I’m a Fan of Both G4KLX / MMDVM and SP5WWP / M17
I consider myself an interested observer and admittedly a fan of both Jonathan Naylor G4KLX and the MMDVM Project, and Wojciech Kaczmarski SP5WWP and the M17 Project. In my opinion, both have contributed novel and technically innovative solutions into Amateur Radio (and beyond) that, until they created their respective projects, most would not have thought their ideas to be feasible.
Until G4KLX created Multi Mode Digital Voice Modem (MMDVM), the idea of integrating the various “dialects” of Digital Voice systems on VHF / UHF and make them interoperable… at low enough cost to be affordable by Amateur Radio Operators… just didn’t sound feasible. But G4KLX figured it out and made the idea work. Now we take multi mode Digital Voice to be routine.
Until SP5WWP decided to attempt to create a new Digital Voice mode, pretty much from a clean sheet of paper (but studying how other DV modes had been implemented), that would integrate the Codec 2 open source CODEC, and be based entirely on open source technology… from scratch… to not be feasible. I was surprised that such an audacious project was not only possible, but had been actually implemented within an ecosystem.
Thus I’m truly, personally, saddened at this situation.
Background Information on MMDVM Versus M17
I admire that Cale Mooth K4HCK of Amateur Radio Daily offered rapid, impartial, and balanced perspective of these developments this week, from both sides:
MMDVM Project Drops Support for M17 Mode
and
M17 Foundation Responds to Statements made by MMDVM Project Maintainer
Thank you K4HCK!
G4KLX Announcement of the removal of M17 support from his MMDVM software on the OpenDV email list:
Removal of M17 from the MMDVM Project
There was some followup discussion on this thread, but the discussion thread is now locked - replies are no longer permitted.
Response fromM17 Foundation / SP5WWP:
M17 Foundation Rebuttal to Jonathan Naylor G4KLX Statements Regarding M17
I began a discussion thread about this topic on the m17-users email list (which is sponsored by Zero Retries, and I administer):
M17 Foundation Rebuttal to Jonathan Naylor G4KLX Statements Regarding M17
Note that this discussion thread is not locked.
For those that have a LinkedIn account (to see all the comments beyond the first few - change “Most relevant” to “Most recent” and click on any “View all comments), this post by Bruce Perens K6BP, and the comments exchanged (some by me), might be instructive:
There seems to be a cooordinated effort to kill the M17 project.
My Synopsis of the MMDVM Versus M17 Situation
As of mid-July, 2025, the primary distribution of Multi Mode Digital Voice Modem (MMDVM) software maintained by G4KLX, which is embedded in most MMDVM radio hotspots and MMDVM modems (such as used in repeaters)
no longer includes support for M17.
How We Got To This Point
In my perspective and discussion that follows… there is no absolute “right” side and “wrong” side in this matter. Claims of past poor behavior have been made against the principal of the MMDVM Project - Jonathan Naylor G4KLX and the principal of the M17 Foundation / Project - Wojciech Kaczmarski SP5WWP.
Without intimate knowledge of the long timeline of the support of M17 within the MMDVM project (which I don’t have, and I don’t want to try to unwind), it’s impossible to access “who threw the first punch”.
There are also G4KLX’s claims about the two ARDC grants to perform work on behalf of M17. As with all grants from ARDC… that organization is the only entity with solid information about what happened ARDC grant funding. From my observations of ARDC, they’re unlikely to offer any followup regarding the M17 grants, and especially not about G4KLX’s accusations. Thus that’s all G4KLX’s accusations are… accusations.
But such recriminations and history are now inconsequential. The task from this point forward is to deal with the situation as it is now and going forward.
As you’ll read in the background information, there were technical issues claimed, and rebutted, by both parties. I don’t have a deep enough technical background to attempt to adjudicate such claims, and I consider both “claimants” to have reasonable standing to make such claims and counterclaims. As with the “behavior” issues, I think such points / counterpoints are now moot in comparison to the magnitude of the task ahead of continuing, and then advancing M17. But I will offer some perspective on the “meta” of the claims of technical issues by G4KLX.
M17’s Alleged Deficiencies, Compared to Other Digital Voice Systems… Isn’t a Valid Comparison
The basic perspective of G4KLX regarding M17 is that there were poor technical choices made, and poor technology implemented in M17… in comparison to other Digital Voice systems in use in Amateur Radio including DMR, D-Star, System Fusion, NXDN, and others. Perhaps G4KLX’s points against M17 are valid.
But in my opinion, such a comparison of M17 versus other DV systems is a specious comparison.
Perhaps it’s not stated as such, but in my opinion and perspective, the overriding goal of the M17 Project was …
Create an open source digital voice system for use in Amateur Radio VHF / UHF bands. Of necessity, given no commercial (profit) motivation, it would have to be done by Amateur Radio Operators who were open source advocates.
Note the chosen constraints:
Open source
Amateur Radio
VHF / UHF
By necessity, implemented
by non-professionals2 (please see footnote) without benefit of large teams of engineers and large budgets.
That’s a niche (those to whom open source matters), of a niche (Amateur Radio) of a niche (those who operate on VHF / UHF… compared to those who operate on HF).
To that last point, consider the superior (per G4KLX) systems that M17 is “competing against”. All of those - DMR, D-Star, System Fusion, P25, NDXN, TETRA, and others…
Were developed with the benefit of tens or hundreds of millions of dollars of development funding, the resources of big corporations, the collective work of dozens, if not hundreds of professional engineers, and a commercial market willing to reimburse all that investment by buying expensive radios expensive infrastructure systems.
The goal of M17 was to develop a digital voice system for Amateur Radio that was entirely open source. Against the odds, and however imperfectly it was accomplished and implemented, whatever the skillsets and biases of the implementers, it worked!
M17 is a usable Digital Voice system for Amateur Radio operations on VHF / UHF bands, and it’s entirely open source technology.
Thus, (again, however imperfect it is), I consider M17 an overall success.
The Aftermath of G4KLX’s Decision to Remove Support for M17 from His MMDVM Software
Jeff Scoville AE5ME on the OpenDV email list:
I respect that you no longer want to support M17 on MMDVM. However, the changes you made last Wednesday have now propagated on the WPSD platform, since it compiles the current github version with updates. Therefore repeater owners and hotspot owners got ZERO notice before things stopped working. I would ask you restore the M17 code for now and give us 30 days to get things sorted out before everyone gets shut down on the repeater and hotspot side.
Keep in mind that literally hundreds, if not thousands of us are getting impacted by these changes. The majority of which had nothing to do with the issues you've raised in your message. If you want to work on future DV modes, a gentle transition will help keep the community intact. If everyone's radio suddenly can't work with hotspots or repeaters, that is a look that will drive a lot of people away.
Like AE5ME, I agree that G4KLX has the absolute right to decide what he wants to work on and support. I respect his choice to no longer support M17.
Also like AE5ME, I’m critical of G4KLX’s manner of making such an abrupt, unannounced change that “broke” so many systems that were using, or potentially might want to try M17 in the future. Before G4KLX’s decision, they could do so. Now they cannot… and they had no warning that such an abrupt change was coming.
Unlike AE5ME, I feel it unlikely that G4KLX will reverse his decision, even temporarily.
However, with due credit to G4KLX, he offered a thin reconsideration of completely removing the M17 components:
Considering the pain that this move has caused to some people. I have made the M17 Gateway and M17 Client GitHub available as read-only archived repositories. I will not be accepting pull requests or any other issues for them, they're [there] to enable people to clone them and do with them what they will within the confines of the GPL.
So, there’s that. Kudos to G4KLX for that goodwill gesture.
Jim Ancona N1ADJ did a great summary of the current situation at this moment on the M17-Users email list - The Path Forward (part 1 of 2):
In the aftermath of the removal of M17 from MMDVMHost, I thought I'd try to sum up our current status and start on a plan to move forward. Feel free to reply with changes, additions or corrections! Also, if you might be interested in volunteering for any of these, please reply. The "Longer Term" options don't really fit my skill set, but I've done some research and can try to answer questions.
Current Status
M17 has been removed from MMDVMHost, and the M17Gateway repository has been archived.
M17 has been removed from WPSD, and the change pushed via auto-update. All WPSD repeaters and hotspots with auto-update enabled
WPSD images containing M17 available at https://m17project.org/wpsd/
Current Pi-Star images work, but they've announced that M17 support will go away in a future update.
G4KLX has indicated that M17 will eventually be removed from MMDVM and MMDVM_HS. These are the modem/hotspot firmware repositories.
In the aftermath of the removal of M17 from MMDVMHost, I thought I'd try to sum up our current status and start on a plan to move forward. Feel free to reply with changes, additions or corrections! Also, if you might be interested in volunteering for any of these, please reply. The "Longer Term" options don't really fit my skill set, but I've done some research and can try to answer questions.
The Long Term Fallout of G4KLX’s Decision to Remove Support for M17 from His MMDVM Software
This statement was shared with me in a private email, so I won’t attribute it. I think it pithily sums up the long term fallout of this situation:
This is a horrible event for the whole Amateur Radio Open Source community, exposing a threat not identified before - a single person canceling over 5 years of efforts.
David Colburn KD4E on the M17-Users email list:
These sort of events are why I've always been uncomfortable with many of the apps/modes in use for Amateur Radio emergency communications support.
Single developer and/or narrowly-controlled development and/or non-open source and/or platform-specific (e.g. Microsoft-only) - all of that is contrary to the key values of long-term reliability, support, and broad adoption.
That a single individual can sabotage a long-developed, and rapidly growing, mode (in this case M17, but who else might follow this lead), is intolerable.
FreeDATA and FreeDV are excellent modes in constant development - and they exist independently of arbitrary 'gatekeepers'.
FreeDATA is a 'server' base upon which all manner of purpose-specific apps may be stacked (as I understand it, it's not only for HF but also VHF & UHF).
If someone can develop a store-and-forward app, and one that (RF-only) bridges VHF/UHF to HF, MMDVM and other current intermediate interfaces (as well as some less 'open' modes, may be rendered unnecessary.
Perhaps M17 developers might migrate to FreeDATA?
I’m including this excerpt because in my assessment of the fallout of this development, I hadn’t even considered the potential impact to the various modes that are used widely in Amateur Radio emergency communications.
As an aside, is I understand FreeDATA, it was specifically developed to make use of the strong modulation and forward error correction of FreeDV.
I wrote on M17-Users email list:
This development will test the strength of the open source model in Amateur Radio.
The decision to remove M17 Support from G4KLX’s official MMDVM distribution was his decision alone.
There’s an old expression from the Internet - "The Internet treats censorship as damage and routes around it”. I think that, writ broadly, applies here. G4KLX can do as he wishes with his version of MMDVM, but MMDVM is open source so there’s no reason that MMDVM can’t be forked in disagreement with G4KLX’s decision to re-include support for M17.
Thus G4KLX’s decision isn’t the final word, and what happens in the coming weeks will be instructive for future Amateur Radio open source projects to be supported by commercial companies.
THIS DECISION (BY G4KLX) ISN’T JUST ABOUT M17… IT’S ABOUT WHETHER A SINGULAR DECISION BY A SINGLE INDIVIDUAL CAN “CRASH” AN OPEN SOURCE PROJECT AND COMMUNITY.
If G4KLX’s decision to remove support for M17 from his MMDVM software, and from that decision the majority of M17 users decide that M17 is dead, then that has ripples throughout the entire Amateur Radio ecosystem.
Writ large, if a single individual’s decision to remove their support can essentially kill an entire project, then it’s likely too big a risk for a commercial company to invest resources in Amateur Radio open source projects / communities.
I’ve been copied on some private conversations regarding interest in M17 by commercial companies that have been… “chilled” by this development.
It’s not just those companies possibly reconsidering their involvement in M17. The question, very rationally, has to be going through their minds as to whether it’s a reasonable business decision to get involved with an open source project that can be so fundamentally affected by the decision of a single individual.
Any Amateur Radio open source project.
Including the MMDVM Project3.
And future projects of G4KLX like (sadly, for me, MMDVM-TNC).
We’ve all experienced situations with open source projects where they sometimes… coast to a stop and cease being maintained. We consider that a normal situation. Individuals developing an open source passion project just sometimes just can’t work on it any more. Progress stops. But work already done in open source projects doesn’t go away, functionality isn’t stripped away like was just announced by Belkin removing support of Wemo devices.
That’s considered to be one of the strengths of open source.
But the “Belkin Wemo” situation is exactly the same thing that happened4 with G4KLX’s decision - M17 users who were using their MMDVM units suddenly discovered that their MMDVM unit had been “bricked” - the M17 functionality that they depended on was just suddenly gone.
From my perspective and memory, I don’t recall an open source project that went backwards from a singular decision to remove functionality and breaking existing systems that an entire ecosystem (automatically updated MMDVM hotspots and modems) have grown to depend upon.
That’s the long term fallout of this situation - trust in open source projects in the small community of Amateur Radio has been damaged. I can’t imagine that was G4KLX’s intention, but that is the actual effect. That’s the big picture that apparently wasn’t considered. To wit:
G4KLX on the OpenDV email list - Re: Removal of M17 from the MMDVM Project
…
It has no far reaching implications, this is a decision made under particular circumstances on one project/protocol.
…
The fact that M17 is so badly affected by my decision goes to show how shallow the development pool on M17 is.
It may be that the “development pool on M17” is shallow… but again, M17 is a small niche of a small niche, of a small niche.
But what’s done is done, and again, I don’t see any reason to hope that G4KLX will reconsider his decision to remove M17. He’s moving on in his development of MMDVM. In the same message as above:
dPMR is the next protocol to go in, and the MMDVM_HS firmware in duplex mode is getting near to its code limit.
To this point, one email correspondent offered this assessment (from considerable technical depth):
The removal was not technically necessary. There were multiple ways that M17 could have remained in the system. These include:
Dynamic linking of the user chosen drivers,
Conditional compilation,
(Simplest) provision of drivers in object code format with a script allowing the user to link the ones they want.
It seems likely that in the aftermath of this situation, someone will provide one of those facilities for support for M17 continue in MMDVM.
The Path Forward for M17 and MMDVM
Jim Ancona N1ADJ did a great summary of the current situation at this moment on the M17-Users email list - The Path Forward (part 2 of 2):
Near Term
Document options for running a working M17 hotspot. For WPSD and Pi-Star, this should include how to disable auto-updates.The M17 Hotspot page on the wiki is a good start, but it might make sense to publish a page on https://m17project.org/
Archive current working Pi-Star releases
Archive MMDVM and MMDVM_HS version 1.6.1
Longer Term
Fork Pi-Star or WPSD in order to keep (Pi-Star) or restore (WPSD) M17 functionality.
Maintain forks of MMDVMHost, M17Gateway, MMDVM and MMDVM_HS with working M17.
Ongoing
Develop alternative M17 and multi-mode hotspot and repeater options. M17-only examples include:
mspot for MMDVM hardware
rpi-interface for the CC1200 HAT
m17-gateway, also for the CC1200 HAT and hopefully other hardware in the future
None of these are as full-featured as WPSD or Pi-Star.
I don’t have the depth of knowledge necessary to comment on N1ADJ’s assessment, but it rings true to me. In my opinion, it will be hard to recover the popularity of M17 in the aftermath of removal of mainstream support for M17 in most MMDVM units.
Previously, it was easy to dabble with M17 if you had an MMDVM unit. You could use a modified radio, or an FM radio with an M17 modem, or buy a Connect Systems CS7000 M17 or CS7000 M17 Plus, or for data experimentation, buy a Mobilinkd TNC4.
Now, at best, those that want to experiment with M17 with an MMDVM unit will need to load an alternative software / firmware from the mainstream MMDVM for their MMDVM units. That will significantly reduce the “help from my local buddies” effect.
It’s the reality that with this development, it’s going to be difficult to recover the popularity of M17… but not impossible. My perception is that the fans of M17 may well be willing to invest in a MMDVM hotspot specifically to use M17. In fact, a cottage industry may form to offer M17 support in MMDVM.
I hope that this is a “teachable moment” for the M17 community… all of us individuals in that community… consider expanding our support for the M17 Foundation. Not just financially (thought that would be a big help) but active participation as N1ADJ outlines. Write documentation, create YouTube videos, participate more actively on the M17-Users email list and the OpenDV email list. There are Discord channels, and social media to evangelize M17.
And, for those companies that invested significantly in the M17 ecosystem, such as Connect Systems, Mobilinkd, and Lilygo… consider supporting them with a purchase of their M17 capable units. Vote for M17 with your wallet.
And you can vote for M17 with your “feet”. If you’re anywhere near Dwór Mazowiecki, Poland on 2025-09-06 and 07, consider attending the inaugural M17 Conference 2025. And, if you’re anywhere near Everett, Washington, USA on 2025-09-13, consider attending the inaugural Zero Retries Digital Conference 2025 where Jeff Scoville AE5ME will do the M17 Presentation.
In general, if we want M17 to overcome this situation, we need to advocate for M17 as an open source project within Amateur Radio that’s actually working (again… however imperfectly).
The Long Term Future… and Evolution… of M17
M17 isn’t the be-all-and-end-all… the ultimate open source digital voice systems for VHF / UHF in Amateur Radio.
This is tacitly acknowledged by the Bylaws of the M17 Foundation (Statute Of The M17 Foundation). With assistance from ChatGPT Plus translating from Polish to English, in
II. Goals and Principles of the Foundation, §7
in the 18 points of that section, supporting M17 technology isn’t mentioned. I’ll guess that was a strategic decision, because… technology advances. And Foundations can easily outlive specific technologies. So this is actually forward looking.
So let’s look forward for M17 and open source digital voice (and data!) systems for Amateur Radio VHF / UHF in general.
As I discussed in Request to Send in this issue (Bets on Steadily Improving Technology Are Generally Good Bets), improving technology continually creates new opportunities. Things that weren’t feasible a year ago may now be feasible with better, less expensive technology - cheaper FPGAs, faster processors, amazing new radio chipsets, even regulatory changes (we can hope), etc.
“Open Source” AMBE?
AMBE is the CODEC developed by Digital Voice Systems, Inc. (DVSI) that is used, in some form, by all (that I’m aware of) Digital Voice systems used in Amateur Radio VHF / UHF. The benefit of using AMBE is that it’s well suited for purpose (low bitrate, reasonably robust), it’s ubiquitous and thus well understood, and the audio quality ranges from usable to good.
I’ve been told that the patents of some versions of AMBE have expired. Thus DVSI cannot (at least in theory) sue for patent infringement on the use of the technology of those older versions of AMBE (whose patents have expired). But I’ve also been told that DVSI is litigious and dismissive of the entire Amateur Radio market (far below their threshold of serious, or even casual attention). Just the threat of a lawsuit from DVSI (lawyers on speed dial) is too chilling for an Amateur Radio project. From my very, very imperfect understanding of this situation, that effectively renders the potential of “Open Source AMBE” to approximately nil.
Open Research Institute’s Opulent Voice Project
Opulent Voice is an open source high fidelity digital voice and data communications protocol. It’s available for 70 cm and higher bands. It’s easy to try out with a custom firmware build for the PLUTO SDR. Directions on how to install this implementation can be found at https://github.com/OpenResearchInstitute/pluto_msk
Custom hardware is in development right now, with production no earlier than late 2025.
There is an update on Opulent Voice dated 2025-07-08 - Opulent Voice Protocol Development:
Opulent Voice is an open source high bitrate digital voice (and chat, and data!) protocol developed by ORI. It’s designed as the native digital uplink protocol for ORI’s broadband microwave digital satellite transponder project. Opulent Voice (OPV) is good for both space and terrestrial use.
…
The modem in an excellent “rough draft” state. There are positive results in over-the-air testing.
Sounds promising… especially that its target hardware is the well supported PLUTO SDR Software Defined Transceiver. But at the moment, Opulent Voice doesn’t seem equivalent to the usability, or the ecosystem, or the community of M17.
FreeDV Radio Autoencoder (RADE) on VHF / UHF
RADE is discussed above, but I’m also mentioning it here for completeness and to broach the possibility that if RADE is “instructed” (it’s a machine learning application) to use wider bandwidths that are available on VHF / UHF, then perhaps the voice quality could be improved even more, or the compute requirements of RADE could be reduced. In a word, RADE is adaptive, so perhaps this is feasible.
Given that RADE is compute intensive, perhaps RADE is a near term solution for the combination of VHF / UHF Software Defined Transceivers are more common and less expensive, and RADE’s ability to use narrow bandwidths can be taken advantage of as is the case of RADE’s use on HF. And Raspberry Pi 5 class compute capability gets even less expensive (but in my opinion, it’s hard to beat the current price performance of a 16 GB Raspberry Pi 5).
G4KLX - Towards a better open source DV mode
Having renounced any further involvement or support of M17, G4KLX speculated on the OpenDV email list about a new project (?) to develop a next generation Open Source Digital Voice system for Amateur Radio VHF / UHF:
I've been asked about how I would design a good open source DV mode. So here are my thoughts:
Modulation, 9600 bps C4FSK which is pretty much the standard for most DV modes.
Addressing, we are hams we use callsigns, and that is what I would use. Given enough characters the callsign field can be used for useful commands. How many callsigns and how long they are, are open to discussion.
Something akin to a Color Code/RAN/NAC would be used for channel sharing.
There would be a special message format for the header and trailer, maybe with its own sync word. The data in this would be callsigns, payload information, and control flags. It would be protected by FEC and a checksum. This is in keeping with DMR, YSF, NXDN, dPMR etc.
Subsequent frames would include a portion of this header data, split over multiple frames to allow for late entry with its own FEC and checksums. This is pretty standard.
The payload and its format would depend on the technology used and would be indicated in the header and its copies in the payload frames.
One payload type would be a fixed pattern for BER tests.
Other payload types would use various vocoders as they become available, and would define their own layout, FEC, etc. as appropriate. Once standardised they would appear in the specification.
If possible, any spare data bytes in the payload would be used for extra data, such as short free form text messages (like D-Star and DMR), GPS data, and extra callsign data.
There would be no possibility of encryption with this mode.
I think that item 8 is the bit that would make the mode exciting as it could use new vocoders as they become available. Currently RADE from David Rowe is making great strides, but requires a lot of processing power. Therefore it would be possible that the initial version of the mode would define a less good vocoder, and those with a technical bent could create mode client code that runs on PCs which would allow for testing with RADE. Essentially it would both be a useful DV mode with good performance, and the basis for experimentation.
A followup by G4KLX dampened my interest a bit:
I don't want a DV mode to try and reproduce packet radio functionality, the packet world can do some pretty impressive speeds these days and DV modes are not the best for moving data. However there will be a raw data payload type.
The idea of having side-by-side text, GPS, and callsign data with the voice data comes from D-Star and DMR where it allows for extra functionality like on screen text data about the other station, and any GPS data is transmitted to the partner station and gatewayed to APRS-IS without having to do a separate transmission.
This may be purely wishful thinking on my part, but I wish radio technologists could embrace the wisdom of the Internet that we’ve enjoyed for decades now - a good enough protocol that accommodates a wide range of uses. Voice - yep, it does that. Data - yep, it does that. Video - yep, it does that too. In the 21st century, I it just makes sense to me to stop creating highly optimized… thus highly restricted radio modes. Another example is the highly optimized use of Digital Video in Amateur Radio… that’s just yet another high bandwidth bitstream, but cannot be for data. But perhaps that’s just me.
As with Opulent Voice, “G4KLX-DV” (solely my imaginary name for such a project) sounds interesting, but this is at the moment just a wish list. In comparison, M17 is a working, usable (but yet, again, imperfect) system, ecosystem, and user community.
But that said, we need people, especially very talented people like G4KLX to work on new systems - that’s what Amateur Radio is for - experimentation.
Zero Retries Boilerplate
The Zero Retries Store is now open for business with quality Zero Retries branded merchandise and items being retired from Steve’s N8GNJ Labs.
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.
See the Zero Retries Boilerplate page for significant acknowledgements and other information relevant to Zero Retries. For new readers of Zero Retries, that page, and the About Zero Retries page has useful information to check out.
My ongoing Thanks to:
Tina Stroh KD7WSF for, well, everything!
Jack Stroh, Late Night Assistant Editor Emeritus
Shreky Stroh, Late Night Assistant Editor In training
Annual Founding Members who generously support Zero Retries financially:
Founding Member 0000 - Steven Davidson K3FZT (Renewed 2024, 3rd year)
Founding Member 0001 - Randy Smith WU2S (Renewed 2024, 2nd year)
Founding Member 0002 - Chris Osburn KD7DVD (Renewed 2025, 3rd year)
Founding Member 0003 - Don Rotolo N2IRZ (Renewed 2025, 3rd year)
Founding Member 0004 - William Arcand W1WRA (Renewed 2024, 2nd year)
Founding Member 0006 - Todd Willey KQ4FID (Renewed 2024, 2nd year)
Founding Member 0007 - Merik Karman VK1DF / VK2MKZ (Renewed 2025, 3rd year!)
Founding Member 0008 - Prefers to Remain Anonymous 14 (Renewed 2024, 2nd year)
Founding Member 0009 - Prefers to Remain Anonymous 19 (Renewed 2025, 2nd year)
Founding Member 0011 - Rick Prelinger W6XBE (New 2024)
Founding Member 0012 - Ryan Tolboom N2BP (New 2024)
Founding Member 0013 - Newton White N4EWT (New 2025)
Founding Member 0014 - Joe Hamelin W7COM (New 2025)
Founding Member 0015 - Rich Stocking N7OP (New 2025)
Founding Member 0016 - Prefers to Remain Anonymous 77 (New 2025)
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.
Permission for Reuse of Zero Retries Content
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. Specific blanket permission is granted to TAPR to use any Steve Stroh content in Zero Retries for the TAPR Packet Status Register (PSR) newsletter (I owe them from way back).
In such usage, please provide appropriate authorship credit for the content (especially for guest authors) and mention that it was first published in Zero Retries newsletter, preferably in this format:
This article is reprinted with permission. It was first published in Zero Retries newsletter, issue Zero Retries (number), (date) - (include full web link of the specific issue).
It’s appreciated (a courtesy, but not required) to notify Zero Retries Editor Steve Stroh N8GNJ of any reuse of Zero Retries content - stevestroh@gmail.com
If you’d like to republish 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, 2024, 2025 by Steven K. Stroh.
This issue released on 2025-07-18
Keywords for this Issue
Zero Retries 0211 dated 2025-07-18:
Amateur Radio, Data Communications, Digital Communications, Digital Voice, DV, G4KLX, Ham Radio, Jonathan Naylor, M17 Project, MMDVM Project, N8GNJ, Packet Radio, Radio Technology, Software Defined Radio, Software Defined Receiver, SP5WWP, Steve Stroh, Wojciech Kaczmarski, Zero Retries, Zero Retries Digital Conference, ZRDC 2025
Keywords in Bold are regular mentions in each issue.
Footnotes for this Issue
To see the relevant sentence for the footnote, just click the footnote number.
My thanks to Caryn Eve Murray KD2GUT, one of the staff members of Amateur Radio Newsline for reaching out to me with this unique bit of news. I have not seen this information mentioned anywhere else.
Post Publication Update: Private comment via email: Note that David Rowe is a professional communications engineer with a Ph.D. in digital voice compression. Wojciech Kaczmarski is also a professional communications engineer. This has been a common insult directed to Open Source and thus often disproved.
Point taken, and no insult to either Rowe (VK5DGR) or Kaczmarski (SP5WWP) or the many other contributors to Codec 2 or M17 was intended. I hope that the revised phrasing clarifies my intent to reflect that Codec 2 and M17 were developed without large teams (of professionals) and large budgets.
This decision may well become a “self own”. An older version is Hoist with his own petard. I take no pleasure in this observation - it’s just the reality of the situation.
Other than the fact that Belkin provided advance notice…
G4KLX has a place in ham radio hall of fame. Without his efforts, DV modes were still stuck with commercial infrastructure. Having said that, the email exchange shows a serious ego problem. Like anyone else he may have criticism on any topic, but the distance between this and killing other people investments is great. His support for M17 contributed greatly to its development, and he may have private audience with SP5WWP. However, his expectations that everything he said will be immediately and blindly accepted, is not mature. Unfortunately it is the ham community that is going to suffer from this dispute. If G4KLX wants to stop supporting M17, he is entitled to do so. But in the true spirit of open source, he should leave it to someone else to carry the torch.
I wish M17 team success, but from your telling of the saga to date, it seems like they over-relied on MMDVM to make their work function (without M17 on PI-STAR, WPSD, or MMDVM we're unable to operate). I think staying on the last working pi-star et al releases that supported should buy the M17 team some time to figure something out...
The key to M17 success is to be something greater than just another "me too" digital mode, offer something special - merely being open source isn't enough to get most interested.
The problem with DStar or Fusion C4FM (or even DMR) isn't the use of DVSI Vocoder, so simply using something in place of the DVSI Vocoder isn't really enough to get me interested.
Aside from embracing Open Source principles/practices, what did M17 offer users to woo them off DSTAR, Fusion C4FM, or DMR? (I'm asking because I want to know, it's an honest question.)