M17 is an open source land mobile radio digital voice and data protocol, and the M17 Project is a worldwide community implementing that protocol.
M17 is fully open including the voice codec. Competitor protocols have proprietary codecs, which limits their hackability and your freedoms.
This is M17. Experiment, innovate, learn, build and fix at your own will.
Benefit from others doing the same thing. Repeat!
Introduction
There are related projects, like MMDVM (the multi mode digital voice suite of software), and OpenRTX (an open firmware for radios), that are absolutely critical to the success of this effort.
Asking “Why M17?” is much like asking “Why open source?” in any other area - but amateur radio is far behind the regular software scene in terms of limitations from proprietary hardware and software. There was no Linux or Free Software Foundation for amateur radio that met with the same success as those projects.
This post is adapted from an excellent Discord conversation asking I thought was worth preserving and publishing.
I’ve made (I think) only formatting changes to Chip and Tony’s responses.
I modified mine much more extensively. I did cut out messages that are not relevant to the question, this is not a chat log.
The question (paraphrased):
What are the benefits, advantages, and attractions of M17 to hardware developers, software developers, and amateur radio operators?
Chip W0CHP’s response:
M17 has no single/centralized registration system for users, and no weird ID requirements; helping to eliminating barriers of entry. Usability is also greatly enhanced. Best of all, no encumbrances, licencing issues etc. Fully and truly open - all of it.
No code plugs! 🙂
Tarxvf’s response:
The short form is that because it’s fully open source including the voice codec, we can actually build and experiment with our own radios. That’s something you could not really do with anything else available.
The rest of it is network effects and practical considerations, but that requires a bunch of context.
The current state of the art voice codec from DVSI as used in YSF and DMR, among others, is patent encumbered and cannot be even reverse engineered without interesting licensing and royalty issues - and they don’t sell to individuals. Older codecs that are for various reasons not encumbered, mean that D-Star and P25 radios could be made, but they don’t sound as good.
Aside for details on the codecs: D-Star uses an earlier AMBE, which is no longer patent encumbered, but no open implementations exist that I’m aware of.
P25 (phase 1, which is the only one you really see in ham world) the codec is no longer patent encumbered and there are open implementations of it. The protocol is not really designed for hams. (P25 phase 2 uses the modern AMBE2+ codec, same as in DMR and YSF.)
Both the AMBE in D-STAR and IMBE in P25 sound a little worse than a modern codec like Codec2 or the latest DVSI offerings. The newer DVSI codecs are protected by patent and the company does enforce it.
There have been efforts to make a global Amateur Radio-wide licensing agreement with DVSI that have not met with success.
The availability of a high-quality and competitive voice codec from hams - David Rowe and friends - called Codec2 plus the current golden age of DIY electronics meant it was a good time to challenge the status quo.
So what you see here is a giant pile of people who’ve wanted to experiment, build, and tweek their VHF/UHF radios and were not able to for two main reasons - closed source firmware and a proprietary voice codec.
These go hand-in-hand: if you have the proprietary voice codec as software then you can’t open source the firmware. If you have the chip, that might still be covered by NDA and you still can’t open source the firmware, if you even wanted to. On that note, no major manufacturer will open source their firmware because that would change the market drastically.
Where Yaesu makes a big deal about their buggy bluetooth and their proprietary USB camera, an open implementation means the barrier to having a new camera is ‘just’ a software driver and working bluetooth is ‘just’ the engineering time to find the bugs and fix them. This is a much lower barrier than what we have now.
This proprietary and closed status quo is not friendly to hams. Hams are innovative - just look at the capabilities from projects like MMDVM, OpenHPSDR (and the many incredible related projects ), FLDigi, WSJT-X and derivatives like JS8Call.
This list doesn’t even scratch the surface of amateur innovation.
There’s open source implementations of many protocols, we just can’t use them on our radios easily. Similarly we could leverage a great many accessories like e-ink displays for daylight readability - but if you can’t change the firmware, you can’t add accessories.
Previous projects like Travis Goodspeed’s md380tools attracted a lot of attention because they opened up a platform and made it better suited for hams (md380tools started with a single byte patch to the firmware that would play audio for all incoming traffic regardless of talkgroup - something you wouldn’t want for commercial usage but hams effectively demand for cultural reasons. See PoC||GTFO 10:8).
M17 is meant to be a competitor specifically with DMR, YSF, P25, NXDN, etc. Right now the focus is on the voice mode, but the specification and a few implementations have all the usual packet capabilities you might hope for, and that side of things isn’t set in stone yet. The voice mode has several implementations and has been stable for some time now.
For practical reasons, M17 was designed to be used with existing hardware of the same class it’s meant to compete with. That’s why it’s not based around an OFDM modem, for example.
This makes it much easier for something like Module17 to be made, which is a smart-microphone adapter that plugs into the 9600 baud packet port on mobile radios and turns the whole ensemble into an M17 capable radio. Similarly it enables the hardware hacks on MD-380-derived radios.
But a mode means little without implementations, and implementations need a platform to run on. That’s where OpenRTX comes in.
OpenRTX is the Linux of embedded radios.
People are attracted to OpenRTX because they can write their own applications, tweak the UI, add features to better support blind hams, internationalize it to their own language, and much more.
Many of these are things that a commercial interest can’t justify spending the time and money on developing and because their firmware is locked down, it simply can’t be done by anyone without extraordinarily great expense and time to reverse engineer the whole thing.
This flexibility of an open firmware and the implementability and hackability of an open protocol are what brings these two projects together - they complement each other perfectly.
Additionally, there’s a strong attraction to the new horizons opening up. With open hardware designs, it’s easier to learn and modify for your own uses. With open hardware and software, the barrier to entry is absurdly low.
Many hams love being on the cutting edge. The hackability of open firmware and software brings unparalleled flexibility and a fast pace of innovation that you will never see from a major manufacturer - the motivations are different and so the outcomes are different.
This opportunity is attractive to the early-adopter types, and as the barrier to entry of getting your own M17 radio continues to lower, the feature set will be the main draw for the crowd that wants something off the shelf. Unlike the usual commercial venture, that will not require a higher barrier to contribution.
That difference is part of why TCP/IP won the protocol wars of things back in the day, and why Linux has absolutely dominated just about all of the most technical sides of computing.
Compare this to M17 and OpenRTX in the radio industry.
TCP/IP won out over several competing protocols because it was good enough, easy to implement, and not encumbered or proprietary. That there were openly available implementations cemented the win.
Hackers and makers want to build. And this is the network effects issue.
There are already entrenched networks of D-STAR, DMR, and everything else. That’s part of why you can’t just make a D-STAR radio with Codec2 as the voice codec - you’re already incompatible with the existing users, so you might as well start completely fresh if you have complaints about D-STAR. This also means you can’t just win overnight, there have to be good reasons to switch.
But entrenched networks make it harder to innovate, so it’s difficult to make good arguments for switching. Look at IRC and email. Major innovations often require a completely new network to replace the existing one, and likewise an entirely new network is capable of adapting to new changes much more completely even as it grows because it’s still small.
So this is the whole set of attractions and benefits for M17, OpenRTX, and all the related projects: a lower bar to create, a community of enthusiastic developers that offer mutual technical support and cameraderie, the room to create and maybe see your creations used, and the absolute and guaranteed freedom to hack things as you want them to be.
The real question is - why would anyone want a proprietary stack? There are bugs in my existing Yaesu and Icom radios that I simply cannot fix. I won’t even mention the features I now consider basic that are missing, that I could add myself if the system was open.
I have these proprietary radios because there is no better option. We work on this, here, because we desperately want those better options.
Tony VK3JED’s response:
I have a slightly different viewpoint. I’m not a developer, but a technical user who first and foremost simply wants to communicate by whatever means is at hand.
The existing DV modes have a number of issues, from a user’s standpoint. All of them use a proprietary vocoder, which the vendor won’t licence the software for individual users - they want to sell hardware.
This limits the places where the modes can be implemented and how - I have to send audio data on a 1500km round trip, simply to transcode audio for a multiprotocol bridge between the various modes - all so I can physically plug in hardware vocoders to make the system work.
M17 doesn’t have this issue, its free, unencumbered Codec2 vocoder is able to run on the server itself.
Secondly, a number of the DV modes (P25, NXDN, DMR) are designed for commercial use, and have a feature set that doesn’t align with ham use.
Hams have been pretty inventive with the protocols themselves and have bent them to their needs, but there’s a limit with how far you can go. Even the protocols designed for ham use (D-STAR and Yaesu System Fusion) have been designed by organisations or commercial vendors, and implemented originally by vendors, and hams have tweak their use in the field.
M17 is unique in that it has been designed collaboratively by the wider ham community itself - designers and developers in the community, community based developers and testers, and so on. And the user community can interact directly, just like users do in any other open source/hardware community.
The result is a protocol that’s not only extremely flexible, but also very user friendly.
Like @tarxvf I have the proprietary radios, because they’re what’s available, but I look forward to the day when I have a cutting edge open M17 radio.
Steve KC1AWV’s response:
I’m here because I was told there would be cookies.
Addendum:
While I was formatting this for the blog post, Tony’s response made me realize I missed a few major points.
M17 is simpler and easier to understand than all existing digital voice modes.
That’s not to say it always will be only simple - innovation breeds complexity - but everyone involved is fed up with the complexity of DMR, hates codeplug management (is there anyone who likes it?), and in general we have the will and ability to tweak the protocol and implementations to keep the simple things simple, standard, and understandable while retaining the flexibility for power users.
We’ve been doing that from the start and will endeavour to keep it that way.
OPV
Open source means we will see forks and other groups with their own desires.
Open Research Institute (ORI) already forked M17 to “Opulent Voice” (OPV) which is a wideband ultra-high-quality digital voice and data mode using the Free/Libre Opus codec.
Many in the anti-digital camp are (correctly) looking for a replacement to high-SNR 25KHz FM. Neither AMBE nor Codec2 can compete with that - but Opus can. One can’t generally play music over amateur radio channels, but Opus is more than capable of handling it. Something as simple as your voice is a cinch, and it sounds good.
There is no robot-effect here, and it’s a major improvement in voice quality over all amateur voice modes I’m aware of.
The Benefit of Forks
I want to talk about this because while the open source software people usually intuitively grasp this from experience, the amateur radio community is less familiar with this dynamic.
A single group can’t focus on too many things at one time, but work in one area often leads to improvements in others, and the open source culture means it all gets shared back and forth between everyone.
M17 loses nothing from a fork like OPV - on the contrary, the OPV fork reportedly made significant improvements on the DSP side of things. M17 can pull in those benefits with some engineering time (if it hasn’t already!).
M17 is no longer affiliated with ORI (they were previously the fiscal sponsor for M17), and that’s a huge loss to M17 and a damn shame. The goodwill and expertise in that group is far beyond most amateur radio groups, and M17 would not be where it is without the efforts of ORI’s many volunteer engineers.
Okay, so that’s Why. Now How?
Open source is non-zero sum because the marginal cost of copying software and information is effectively zero.
Making that information, code, or hardware design is emphatically not free, and funding open source is difficult - but once it is created, it can exist for as long as it is useful and people share it freely at no extra cost.
(Keeping it still useful on the practical level as computers and other systems progress is “sustaining engineering”, and that is again ‘making’.)
Funding this making and sustaining (and test equipment and infrastructure) is where funding from ARDC and others makes a difference.
The support we’ve received from ORI, the Open Collective suite of projects, and the wider community including developers, testers, writers, and donaters cannot be overstated and I believe has been even more critical.
Commercialization
Finally, nothing about open source prevents commercialization or profit. It’s not necessarily sustainable to be reliant on the giant hyperfund (relative to the ham radio market) that is ARDC.
I suspect most sustainable paths forward will involve selling hardware and some method of funding customer support. There’s a lot of space for this.
If you want to sell hardware designs, read the license terms of that project and have at it.
If you’re a manufacturer, we’d love to talk to you and discuss partnerships. People want open radios, we’d like to work with you to make this happen.
Rob, WX9O of mobilinkd, sells hardware directly implementing, among other things, M17. He is also the original author of m17-cxx-demod (now forked to m17-tools) among many other critical efforts.
As of right now I think mobilinkd is the only commercial seller of any specifically M17-related product. I hope that changes with the upcoming Module17 1.0 release.
All MMDVM devices can speak M17 with a firmware upgrade to 1.6.0 or higher, so we’re working on getting more of the MMDVM vendors to make M17 support via firmware upgrade easy and out-of-the-box. Some vendors are locking the update mechanisms, shipping outdated firmware, that sort of thing.
You’ve read this far
I’d like to see you join us and start building.