The NinoTNC also uses an inexpensive microcontroller (dsPIC33EP512GP502) to execute DSP algorithms that modulate and demodulate, as well as handle the protocols and FEC.
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.)
Ken - M17 "relied" on MMDVM because M17 support was there (thanks to G4KLX). Kind of the same as some of the other obscure modes in MMDVM. I'll guess that other than DMR, other DV modes supported in MMDVM aren't in wide use and if you want to experiment with, say, NDXN, then you probably don't have a nearby NXDN repeater, so you "rely" on that support in MMDVM.
M17 is kind of a litmus test in Amateur Radio Digital Voice. Folks say, OK, cool, M17 is entirely open source, but other than that, why should I care about M17 versus all the other DV systems (that seem to work better)? The answer is that M17 IS OPEN SOURCE. That's the entire point. In my research, I discovered that folks get involved in M17 to experiment with some new capability in Amateur Radio (a minority) but most get involved in M17 because IT'S OPEN SOURCE. Put it this way - the open source advocates are doing digital voice with M17, but wouldn't have bothered with digital voice using the other modes because those weren't open source. If you want functional digital voice in Amateur Radio, you have a plethora of choices. If you want to open source digital voice in Amateur Radio, there's currently only one choice - M17.
As an example of the extensibility of an open source digital voice mode, is that SP5WWP did some experimental work to create cryptographic transmission signatures using public / private keys. The idea being that you could verify, cryptographically, that a transmission was from who it was claimed, or not.
The verifying sender type of extensions sounds interesting. Being Open Source makes that possible, but being Open Source alone makes no difference to people that have no plans to experiment, in my opinion.
My pushback against just "it's open source" is that by itself it's a weak argument, just as "Run Linux, because it's Open Source" was/is a weak argument to many/most people.
Ken - Glad you "got it" :-) Really. Linux on the desktop is kind of a parallel that might be instructive. The vast majority of users of desktop computers don't know about Linux, don't care about Linux. But those that do care about Linux (or other open source, like BSD) REALLY care about it. And those folks tend to be pretty capable about contributing technological innovation... such as running Linux on really small computers (appliances like Raspberry Pi) scaling up to servers, clusters, etc. Thus, M17 as an open source Digital Voice system for Amateur Radio VHF / UHF really matters to those people. And because M17 is entirely open source, I've seen it mentioned for embedding into other systems as the digital voice option for IP400, and even a proposed new satellite system. With support for M17 removed from "mainstream" MMDVM software, it won't be as easy for people to experiment / use M17 with their MMDVMs, but that issue alone won't "kill" M17 because M17 is much bigger than just one of the many modes supported in mainstream MMDVM software.
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.
It's not entirely clear to me what your thesis is here vis-a-vis open source, but to be clear, there would be no "path forward" if MMDVM was closed source. The move now is exactly what it is anytime there's a rift in an open source project (and what you suggested): fork! Since it's apparently integral to the M17 community, there must be someone willing to take on the maintenance of a fork. If the fork has success, it often leads to a merge down the line.
Also, with respect to whoever suggested things like dynamic linking to maintain support in mainline MMDVM, G4KLX was very clear he didn't want to spend any more effort on M17 and all the things in that section would represent effort to create and maintain. Perhaps less effort than maintaining built-in M17 support, but still nonzero.
I agree this whole episode is regrettable and we should not engage in friendly fire like this. But I have hope that things will move forward.
It might be a chance to reevaluate the code base and perhaps build a little more modularity into it. More like a network stack or abstraction layer for mode developers to build on? Even if it might not make economic sense now, in another 24 months it probably will.
Eric - With AI being able to assist us in just about everything, especially in obscure technical areas like the hardware and software that drives MMDVM, I suspect that everything is going to be very different in 24 months. I don't personally have the skills to design MMDVM hardware, or software, especially to comprehend the protocols. But the AI capabilities in 24 months might enable me to do so.
Justin - The main thesis (opinion) is that G4KLX's choice of actions will likely have effects far beyond his intention to "simply" remove M17 support from his MMDVM code. The "dynamic linking" was mentioned solely to illustrate that it could have been possible to "make room" for the new addition of dPMR, and keep some support for M17. But as was made clear, G4KLX's actions weren't solely about "making room", they were to rid himself of supporting M17.
This is kind of what happens with amateur radio. People work on projects "at will" and might stop at any time. While pulling the M17 functionality seemingly without warning wasn't very sporting, at least it got attention on the project and some of the internal infighting.
A few years ago, a club member had a complaint about how the repeater is being managed, they voiced their opinion very publicly and the primary repeater tech promptly quit in a huff. Another club member stepped up to fill that role, but there's still the memory of the event casting a shadow. I'm pretty good friends with both of the people involved and can see how, with a little more tact, the complainer might have had a point... and maybe the tech should have had a little thicker skin too. But in the end the club has put a lot of changes in place, including regular status updates to the club, so that the system is much less opaque.
I'm not familiar enough with M17 to have an opinion either way. It is encouraging to see Connect Systems build a handset that could use M17. But without the "big three" and Chinese manufacturers including the mode I don't see where it will get enough traction for repeater builders to add the necessary hardware, so it will probably remain a hotspot mode for a long time to come. One reason why I'm still encouraged by D-Star is because of Kenwood's decision to include it in the TH-D74/75 and their new mobile. That's two major manufacturers that are including it, so there's going to be more choice. .Even if maybe the people buying Icom's radios aren't necessarily going to use D-Star, the fact that it is included "no extra charge" might be enough to produce more activity. Any new modes are going to have to be "yes and" modes where you get it for free. Hopefully it won't look tacked on or get in the way of basic operation either. Icom's HTs including dedicated DV/DR buttons that could be put to better use and the separate memory banks for DR mode that radically change the operation of the handset come to mind.
But for sure this is a major setback for M17, even if it is only a tempest in a teapot.
Eric - I tried to consistently make the point that G4KLX absolutely didn't owe it to M17 to continue to support M17 in his personal work or in the version of MMDVM that he maintained. But the way G4KLX removed his support - unannounced, allowing the "damage to propagate" and folks literally waking up to their MMDVM hardware no longer including support for M17. Even a week's worth of notice would have changed this into a hiccup rather than a crisis for M17. So, lessons learned.
That's my point. No one person should have that much control(?) over a communications mode. And of course with great power comes great responsibility. Taking your ball (the only ball on the field) and going home doesn't help anyone.
Too often I think these new mode projects get stalled when the whole thing is dependent on one developer. I'm reminded of IU-View and the untimely death of G4IDE leaving a lot of Windows users frozen in time. What happens when K1JT retires or leaves the Earthy realm? Hopefully there are enough people familiar with the WSJT-X source code to keep it going, but it's still one software package that "does it all." Even though it has a lot of hooks for other programs and interfaces most people still run it as a standalone application, which could get messy down the road.
Eric - Literally... :-) In writing this story, I've started to type the "with great power...." line several times, but deleted it as I lapse into popular culture references too often. But glad someone said that! I think we had assumed that "open source leaves it as a legacy" , where yeah, someone like K1JT does an incredible amount of work and then stops doing so (for whatever reason). But with open source, the work remains for others (potentially) to pick up and carry on. But this was a different thing - deliberately removing functionality (and then making that removed part unaccesible - which fortunately was reversed).
Steve, thank you for doing this write up. I was working on something similar, but you did it much more justice than I ever could, while touching on important angles I was unaware of.
IMO, M17 needed (and still needs) a Baofeng very early on. By that, I mean an inexpensive and field ready HT that could be made to do M17 with a simple firmware revision. The Lilygo T-TWR was starting to approach that point, but even they need some hardware hacking and a case.
Kevin - Given the amazing efforts of https://openrtx.org/#/ I wouldn't count out an M17 capable inexpensive Baofeng or equivalent. The trick isn't the electronics, it's the overall package including batteries, display, etc. Now that some vendors have created Li-Ion portable batteries that can be recharged with USB-C... heck, adopt those and call it good enough!
The NinoTNC also uses an inexpensive microcontroller (dsPIC33EP512GP502) to execute DSP algorithms that modulate and demodulate, as well as handle the protocols and FEC.
Chuck - Point taken. I should have mentioned the NinoTNC.
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.)
Ken - M17 "relied" on MMDVM because M17 support was there (thanks to G4KLX). Kind of the same as some of the other obscure modes in MMDVM. I'll guess that other than DMR, other DV modes supported in MMDVM aren't in wide use and if you want to experiment with, say, NDXN, then you probably don't have a nearby NXDN repeater, so you "rely" on that support in MMDVM.
M17 is kind of a litmus test in Amateur Radio Digital Voice. Folks say, OK, cool, M17 is entirely open source, but other than that, why should I care about M17 versus all the other DV systems (that seem to work better)? The answer is that M17 IS OPEN SOURCE. That's the entire point. In my research, I discovered that folks get involved in M17 to experiment with some new capability in Amateur Radio (a minority) but most get involved in M17 because IT'S OPEN SOURCE. Put it this way - the open source advocates are doing digital voice with M17, but wouldn't have bothered with digital voice using the other modes because those weren't open source. If you want functional digital voice in Amateur Radio, you have a plethora of choices. If you want to open source digital voice in Amateur Radio, there's currently only one choice - M17.
As an example of the extensibility of an open source digital voice mode, is that SP5WWP did some experimental work to create cryptographic transmission signatures using public / private keys. The idea being that you could verify, cryptographically, that a transmission was from who it was claimed, or not.
Oh, it's OPEN SOURCE! Got it (LOL, just kidding)
The verifying sender type of extensions sounds interesting. Being Open Source makes that possible, but being Open Source alone makes no difference to people that have no plans to experiment, in my opinion.
My pushback against just "it's open source" is that by itself it's a weak argument, just as "Run Linux, because it's Open Source" was/is a weak argument to many/most people.
Ken - Glad you "got it" :-) Really. Linux on the desktop is kind of a parallel that might be instructive. The vast majority of users of desktop computers don't know about Linux, don't care about Linux. But those that do care about Linux (or other open source, like BSD) REALLY care about it. And those folks tend to be pretty capable about contributing technological innovation... such as running Linux on really small computers (appliances like Raspberry Pi) scaling up to servers, clusters, etc. Thus, M17 as an open source Digital Voice system for Amateur Radio VHF / UHF really matters to those people. And because M17 is entirely open source, I've seen it mentioned for embedding into other systems as the digital voice option for IP400, and even a proposed new satellite system. With support for M17 removed from "mainstream" MMDVM software, it won't be as easy for people to experiment / use M17 with their MMDVMs, but that issue alone won't "kill" M17 because M17 is much bigger than just one of the many modes supported in mainstream MMDVM software.
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.
Yoram - I agree with your points.
It's not entirely clear to me what your thesis is here vis-a-vis open source, but to be clear, there would be no "path forward" if MMDVM was closed source. The move now is exactly what it is anytime there's a rift in an open source project (and what you suggested): fork! Since it's apparently integral to the M17 community, there must be someone willing to take on the maintenance of a fork. If the fork has success, it often leads to a merge down the line.
Also, with respect to whoever suggested things like dynamic linking to maintain support in mainline MMDVM, G4KLX was very clear he didn't want to spend any more effort on M17 and all the things in that section would represent effort to create and maintain. Perhaps less effort than maintaining built-in M17 support, but still nonzero.
I agree this whole episode is regrettable and we should not engage in friendly fire like this. But I have hope that things will move forward.
It might be a chance to reevaluate the code base and perhaps build a little more modularity into it. More like a network stack or abstraction layer for mode developers to build on? Even if it might not make economic sense now, in another 24 months it probably will.
Eric - With AI being able to assist us in just about everything, especially in obscure technical areas like the hardware and software that drives MMDVM, I suspect that everything is going to be very different in 24 months. I don't personally have the skills to design MMDVM hardware, or software, especially to comprehend the protocols. But the AI capabilities in 24 months might enable me to do so.
Justin - The main thesis (opinion) is that G4KLX's choice of actions will likely have effects far beyond his intention to "simply" remove M17 support from his MMDVM code. The "dynamic linking" was mentioned solely to illustrate that it could have been possible to "make room" for the new addition of dPMR, and keep some support for M17. But as was made clear, G4KLX's actions weren't solely about "making room", they were to rid himself of supporting M17.
Makes sense. Truly an unfortunate turn of events.
This is kind of what happens with amateur radio. People work on projects "at will" and might stop at any time. While pulling the M17 functionality seemingly without warning wasn't very sporting, at least it got attention on the project and some of the internal infighting.
A few years ago, a club member had a complaint about how the repeater is being managed, they voiced their opinion very publicly and the primary repeater tech promptly quit in a huff. Another club member stepped up to fill that role, but there's still the memory of the event casting a shadow. I'm pretty good friends with both of the people involved and can see how, with a little more tact, the complainer might have had a point... and maybe the tech should have had a little thicker skin too. But in the end the club has put a lot of changes in place, including regular status updates to the club, so that the system is much less opaque.
I'm not familiar enough with M17 to have an opinion either way. It is encouraging to see Connect Systems build a handset that could use M17. But without the "big three" and Chinese manufacturers including the mode I don't see where it will get enough traction for repeater builders to add the necessary hardware, so it will probably remain a hotspot mode for a long time to come. One reason why I'm still encouraged by D-Star is because of Kenwood's decision to include it in the TH-D74/75 and their new mobile. That's two major manufacturers that are including it, so there's going to be more choice. .Even if maybe the people buying Icom's radios aren't necessarily going to use D-Star, the fact that it is included "no extra charge" might be enough to produce more activity. Any new modes are going to have to be "yes and" modes where you get it for free. Hopefully it won't look tacked on or get in the way of basic operation either. Icom's HTs including dedicated DV/DR buttons that could be put to better use and the separate memory banks for DR mode that radically change the operation of the handset come to mind.
But for sure this is a major setback for M17, even if it is only a tempest in a teapot.
Eric - I tried to consistently make the point that G4KLX absolutely didn't owe it to M17 to continue to support M17 in his personal work or in the version of MMDVM that he maintained. But the way G4KLX removed his support - unannounced, allowing the "damage to propagate" and folks literally waking up to their MMDVM hardware no longer including support for M17. Even a week's worth of notice would have changed this into a hiccup rather than a crisis for M17. So, lessons learned.
That's my point. No one person should have that much control(?) over a communications mode. And of course with great power comes great responsibility. Taking your ball (the only ball on the field) and going home doesn't help anyone.
Too often I think these new mode projects get stalled when the whole thing is dependent on one developer. I'm reminded of IU-View and the untimely death of G4IDE leaving a lot of Windows users frozen in time. What happens when K1JT retires or leaves the Earthy realm? Hopefully there are enough people familiar with the WSJT-X source code to keep it going, but it's still one software package that "does it all." Even though it has a lot of hooks for other programs and interfaces most people still run it as a standalone application, which could get messy down the road.
Eric - Literally... :-) In writing this story, I've started to type the "with great power...." line several times, but deleted it as I lapse into popular culture references too often. But glad someone said that! I think we had assumed that "open source leaves it as a legacy" , where yeah, someone like K1JT does an incredible amount of work and then stops doing so (for whatever reason). But with open source, the work remains for others (potentially) to pick up and carry on. But this was a different thing - deliberately removing functionality (and then making that removed part unaccesible - which fortunately was reversed).
Steve, thank you for doing this write up. I was working on something similar, but you did it much more justice than I ever could, while touching on important angles I was unaware of.
IMO, M17 needed (and still needs) a Baofeng very early on. By that, I mean an inexpensive and field ready HT that could be made to do M17 with a simple firmware revision. The Lilygo T-TWR was starting to approach that point, but even they need some hardware hacking and a case.
Kevin - Given the amazing efforts of https://openrtx.org/#/ I wouldn't count out an M17 capable inexpensive Baofeng or equivalent. The trick isn't the electronics, it's the overall package including batteries, display, etc. Now that some vendors have created Li-Ion portable batteries that can be recharged with USB-C... heck, adopt those and call it good enough!