M17
It's been a while, and the last thread disappeared, so here's the latest. As a reminder, M17 is a new land mobile radio protocol like D-Star or DMR - but fully open including the vocoder, and informed from the mistakes of the previous generations of protocols.
It's under active development, so if you have skills and opinions both, you should join us and help out.

Ham radio is just VoIP now
There's well over 50 reflectors around the world, many of them linked - N7TAE forked XLX to make an M17 reflector and made a network client for it too, and that's gotten the most attention so far.
KC1AWV made a way to register reflectors for a one-stop-shop reflector directory.
DudeStar/DroidStar have M17 support thanks to AD8DP, so you can try out the IP layer and the reflectors. Doug also made M172DMR and DMR2M17 cross-moding tools, and got the audio sounding great (no small feat!).

We also transmit RF
M17 is now experimentally supported by MMDVM, including M17Gateway software, thanks to G4KLX - so all MMDVM repeaters and hotspots have a possible future as M17 nodes.
Rob of Mobilinkd has experimental M17 support on the TNC3 for radios that support 9600b packet, plus made an M17 baseband encoder and decoder library, which is successfully used with rtl_fm or with GNURadio.
Jakob of the surviving OpenWebRX fork has added M17 support (and it works very nicely!).

Some things cost money
There's also work on a couple RF daughterboards to drive the next open repeater and handheld designs like the TR-9 V3 portable radio.
And last but not least M17 project has sponsorship from Open Research Institute (that helps other 501(c)(3)s give us money, among other things), and M17 will be applying for some funding grants for test equipment and to defray the hardware costs associated with this kind of development.


The hard part for a project like M17 is about getting enough inertia to get anywhere: we have it now, enough that it's not likely to just stop, and we're gaining more with time.

As for me, I quit my corporate job to work on this and other radio projects, and life is good.

So are you retired now?

I would quit my job but I need an income. I could design stuff in my spare time.

Not retired, just giving the entrepreneur thing a shot.
Expenses are the lowest they'll ever be and I'd been saving up for two years to escape that place, so it was now or never.

I'm down here cheering you on!

Lemme know if you need a guinea pig

Thanks, yes! I'll post here when I'm ready

Good job! A few years ago I briefly put work into using the open source vocoder CODEC2 as a replacement for AMBE in DSTAR. I was going to rename it DOGESTAR

It's not too late to do that, but we'd rather have you on M17!

Apparently a bunch of people independently spent some time on shoehorning Codec2 into DMR through md380tools. I'm glad none of that succeeded!

Latest news: The OpenRTX group has absconded with the OpenGD77 source (and md380tools and others) and is reimplementing a new firmware on the MD380, MD-UV380, GD-77, etc radios.
We're working to figure out if we can shoehorn M17 into radios that use the HongRui basebands.

The baseband chip has two registers labeled I and Q that actually control the VCO and PLL, and those can be used to TX M17 and other modes, if we can reliably twiddle the bits fast enough.
Receiving it? We haven't figured that part out yet.

I could see the potential for a simple hardware mod enabling RX, and we haven't exhausted all possibilities, but that's where we are now.

I got firmware updates through WebUSB working for 1st and 2nd gen TYT radios last night.
Bonus is that it covers a couple aspects of firmware updates that my old md380tools implementations, radio_tool, editcp, and others didn't catch. Plus it's cleaner.
I also discovered a bug in radio_tool that I'll see about fixing later.

WebUSB firmware updates opens up some really interesting possibilities, like easily testing OpenRTX, or md380tools, and easily flashing back to OEM.
No software to install, nothing to compile, no drivers, "just works".

Does WebUSB still leave all the Windows and Firefox people out? Yep.
Windows for the way it handles USB device drivers, and Firefox for not implementing WebUSB (Which is the correct decision overall, I think).
Yes, this does kinda take the power out of the "no drivers" claim.
Can't do anything about that for now, though I do have a couple ideas on how to address that in the longer run.

One of the things I'll make with this new capability is a recovery option - every once in a while, someone somehow gets a codeplug corrupted during a write and ends up with a random power-on password.
None of the existing tools handle this for you, and this happenstance is the cause of the few "bricked" TYT radios you hear about.
And if you were using the OEM software and had the same problem? Just screwed. Only modified third party software could handle it, but even then it was not easily available in those tools because it's such a rare occurence.

The way to fix this corrupted password problem is to turn on the radio in firmware update mode (which is just the bootloader and doesn't have any password functionality) and erase the codeplug flash sectors, which clears the powerup password. Write a new codeplug, and problem solved.

Meanwhile there's work with igateing M17 RF to the APRS system, and they're doing over-the-air tests which is looking fun. I think they're also looking at 6m and maybe 10m tests but don't quote me on that.

Another group is twiddling the MD380 VCO and PLL values in software through OpenRTX, and in hardware with soundcard output from gnuradio (since we dont have a lot of nice signal generators ), and is getting some weird results. Understanding this weirdness is key to knowing if we can adapt the md380 series hardware at all.

My only radio with an accessory port doesn't appear to have modulator input, only demodulator, so my TNC3 languishes in a corner.
Meanwhile I got roped into the MD380 VCO and PLL twiddling.
You're looking at test points (and a ground) for the VCO and PLL.

Attached File

These are then controlled with output from a soundcard, fed by GNURadio.
Attached File



One of the problems (and why I got roped into this part) is that there's a hump on the demodulated FM (which is really just supposed to be a pure tone because we've disconnected the mic input) (someone elses graph here):
Note the 500Hz hump for this graph, from the MD380:

This is what the GD77 has:

Current suspicion is on the PLL, but that's still over my head for now, I was just trying to duplicate the results with my MD-380, which I think I did:
(I changed the audio bandwidth and some other stuff, so pay attention to the scale, sorry)
Attached File



Now, a 10dB peak in the -80dBc noise isn't really an issue, I would think, but it's still there when injecting noise into the VCO.
Smarter minds than me say this is a problem for our goals.
Attached File

This whole exercise is about transmitting arbitrary FSK (like APRS, or M17) by twiddling the VCO from the radio's processor. Receiving? Haven't solved that yet.
Naturally we're working on our own hardware at the same time, because the odds that the MD380 attempt pans out are pretty low.  Worst case we help the OpenRTX guys figure out APRS transmissions.
The TNC3 stuff continues among those members of the group that have suitable radios (or bought one), and there's been some other experimentation with the SA868, I think it was.
The ADF7021 RF daughterboards got put in for the first run a week ago, so cross your fingers for them being generally okay.

In other news, OpenWebRX has added experimental M17 support, which is pretty cool, and we're exploring avenues to get approval to experiment with M17 on a european hamsat.


On a related note, if anyones business or work is upgrading their RF test equipment, PM me. My team can give just about any piece of test equipment a good home.
We have sponsorship from a 501(c)(3) to handle donations, and I think that helps with donated property too, not just cash IIRC.
Tell your friends and coworkers, mention M17, PM me if you have any leads, and as always, join us and help out: https://m17project.org/

Remember how I said we should be able to move the VCO form the onboard microcontroller?
Today I did that by fiddling the qBias value written to the HR-C5000, and we should be able to get +-2KHz.
The OEM firmware tells the baseband chip this value as part of the OEM calibration process, if I understand correctly.

Purple trace was my first test, with values of 1 and 250. That was really disappointing, because they're 117Hz apart.
Yellow trace is the 256 possible values. Cyan is just 127 and 128, and was where I was figuring out what the ranges really meant.
Turns out the qBias value is signed after all, so "128" is really -128 and 255 is really -1. Seems obvious it would be signed, in retrospect, but there you have it.
iBias didn't seem to have as significant an effect, so I didn't capture any screenshots.

qBias is either MOD1 or MOD2 on the reverse engineered schematic, and which exactly it is, is something I'm going to look at.

Not exactly a beautiful spectrum, I'll grant you, but then I'm just a software dev with a specan.
Hopefully the guys with more RF experience replicate this test and we can get something workable.
There's also another connection, MOD2_BIAS (no relation to the other usages of "bias" here), that's connected directly to the STM32. That might be another path forward, or a better one.
Setting the iBias and qBias registers over SPI takes a long time relative to the symbol rates we want, but we'll see what happens.


Meanwhile, another team member has been transmitting M17 over the air with a TNC3 and a 9600 baud capable radio, receiving it with a modern fork of OpenWebRX fed by an RTL-SDR.
Ignore the left audio channel if you can, it's off frequency.
The right audio channel is correctly centered on the received signal because he hasn't calibrated the offset. He's transmitting from his truck, mobile, to the SDR at a house.
This is all experimental: the TNC3 firmware and apps, the M17 support in OpenWebRX, and of course the protocol - but it's working pretty well considering.
You can hear some "digital noises" in the decoded audio - don't get discouraged by it, none of us can stand it either.
Codec2 itself sounds surprisingly good to most DMR users, though microphone gain is pretty important (as all the DroidStar/DudeStar/mvoice users are discovering).

OST

Interesting project, although I am not claiming 100% understanding.

What advantage will M17 deliver over AFSK, QPSK, 8PSK, C4FM, etc ?

Biggest advantage I see, is the open source vocoder.  No more need for a specific chip to legally perform the encode / decode like with D-Star / DMR (but I am also not an expert).

See this write up on setting up a XLX relector: https://n5amd.com/digital-radio-how-tos/create-xlx-xrf-d-star-reflector/

At the end of the article it says:

"The AMBE vocoder chip is a proprietary standard that companies or people can build on and all digital voice 2-way radios use them, which means we do too. Big companies like Motorola hire software and hardware engineers to build radios and product lines around this chip and have capital to throw at pools of smart people. The amount of work required is no different for our hobby. At least until someone creates an open source Vocoder along with easily integrating it with some form of hardware, we will always have to jump this hurdle."

So, M17 may be a solution here.  But as OP stated, need enough people to jump on board to keep it going.

Those aren't protocols, just modulation types (well, C4FM seems to be ... both?), so the differences are hard to address.
M17 is 4FSK at 4800 baud, not too dissimilar from DMR, D-STAR, P25 etc. It's a little larger deviation than DMR, more like NXDN in that regard, and a little more ham friendly, like D-STAR. The voice codec sounds better than all of the existing vocodecs, provided you have a well-tuned microphone (which can be its own challenge!).

The most salient differences are in the protocol design, deviation, error correction, and primarily in the completely open source nature.

DMR, D-STAR, C4FM, etc have all been just that much harder to hack on and add to because of the legal issues around the vocoder. like 0100010 points out. Just about all projects doing cross-mode DMR are effectively ripping the MD-380 AMBE implementation out of the MD380 firmware image to try to avoid legal issues since TYT is the one that didn't (we assume) pay the licensing fees for the vocoder.

M17 has embedded callsigns like D-STAR, but with a much better voice codec. The currently popular reflector software is forked from XLX, so D-STAR users will feel right at home on the network side.
I'm more of a DMR fan, so I plan on throwing together a proof of concept in the DMR style later. (well, updating the existing private proof of concept).
Because Codec2 is fully open in all respects and not patent encumbered, there's a lot more flexibility around software handling M17.
This extends to the hardware and radio firmware, which is where most of the battle is, both in terms of user freedom and developer hackability.

And on that topic - imagine the success of MMDVM.
Multiprotocol repeaters, multiprotocol hotspots, cross-mode support, open source repeater linking that anyone can join, or stand up on their own -  tons of developers and open source efforts gave us something that now sells hardware for $20 on ebay, and the biggest problem people have with the hardware and software is typically their own lack of familiarity with the technology involved. There's a lot of FUD around the chinese implementations, and commercial hotspots that exploit the information gap (no judgement, that's often a good thing, and customer support has to get paid somehow),  but the ease of access and ease of hackability MMDVM represents is a huge step forward for just about every ham with a digital radio in the world.

I hope M17 has a similar level of success, but with a handheld and/or mobile radio, and that's exactly where a lot of our efforts are focused.

Most recently, the OpenRTX x M17 group (including me!) demonstrated M17 transmissions by twiddling the MOD2_BIAS pin from the MD-380 main cpu, and M17 RX and TX through the GM300 accessory port is working well using a couple command line tools and a raspberry pi.

We're hoping for a funding grant, which would make some of this testing quite a bit easier (and more accurate). I had an SSA, so I could look at the spectrum - but I don't have a signal generator, so I was limited to a soundcard - which can be made to work, it's just not ideal.
Funding or not, we're making progress, and that's because of the people involved. It's a cool group.

I think I see the light.

I was building the g4klx/mmdvm packages yesterday and noticed the author was M17 contributor.  So today I circled back to the mobilinkd/m17-cxx-demod package to build it and try the modulation demo.  I ended up building drowe67/codec2 and the cmd line tools.  That is very cool.

I ran a test .wav though the 'c2enc' and 'c2dec'.  The voice quality was pretty decent for a 40:1 compression ratio.  It sounded a bit froggy in the throat on playback, but was clearly understood.  Seems like you can transmit 16bit 8k samples in about 3200 baud if I calculated right.

By the way, K5TUX and friends interviewed one of our guys: https://lhspodcast.info/2021/03/lhs-episode-396-m17-deep-dive/
I haven't listened to the podcast, I hope it went alright.

The group is currently well and fully enamored with the MD-380/OpenRTX combo for M17 and GM-300 and similar models for M17. I understand the GM-300 has long been an MMDVM favorite, so it's friendly to yet another 4FSK mode.

Meanwhile, I'm trying to get my MD-380 codeplug editor and radio manager project to version 1 and ready to release when OpenRTX goes to v0.3.
OpenRTX uses the same codeplug format as OEM firmware, and my tool allows for easy firmware updates to OpenRTX releases and back to OEM, so timing my release with theirs will be just a little bonus to make testing OpenRTX easy.
Other than that, I'm currently working on adding simple codeplug editing to start, with more advanced features later.

Yesterday among other UI additions, I added the ability to reorder channels within a zone (feature request from my dad! TYT CPS can't do that.) and fixed a couple bugs from floating point errors (e.g. 147.015 -> 147.01499999...). Javascript.

I also ran into another issue that took some time to track down simply because I was looking in the UI, but it came from a mistake I made in the codeplug file proxy class.

So any given list has their data one after the other, all stacked end to end, e.g.

-----------------
| Channel 0 |
-----------------
| Channel 1 |
-----------------
| Channel 2 |
-----------------

If a structure is 64 bytes, and the beginning of Channel 0 is stored at some memory location p, then the beginning of channel 1 is p+64.
That's standard, nothing fancy. But each element in a list has its own data, which itself might be a list.
Zones, for instance, have an array of channel indexes within each zone.

Here's, for example, the first zone. A channel reference here of "0" actually means disabled, so Channel numbers are stored +1. This zone only has a single member, Channel 0.
---------------------------------------------------------------
| Zone 0                                                            
| Name: Boston                                                
| Channels: [1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]      
--------------------------------------------------------------

If you want to edit the list of Channels in a particular Zone, then you need the pointer to the zone array, the size of the zone*the zone index, the offset to the Channel list within the Zone, and then the offset to the correct index within the channel list.

I have a bunch of code that abstracts this out and makes it easy to work with. Settings are records, Zones and Channels are records in an array, zone names and other things within a record are fields, and things like Channels within a zone are field arrays.
Well, my bug was that in cases of record arrays (like Zones or Channels) that also have field arrays (like the list of channels within a zone) I wasn't passing through the record index, so any writes were being done to the first record.
But reads were fine. What this meant was that if you were dragging and dropping the third channel in Zone 3 to the first channel, it would overwrite the first channel of Zone 0.
Whoops.
Past time to write some tests, and maybe refactor some of that code.


I'm in a good spot to keep working on frontend UI stuff for the rest of this week, and then I'm switching to the codeplug management code and writing some unit tests.

Please tag me as well.  I love D-Star because it's currently the best thing for my use cases.  But I'd jump ship in a picosecond for an open source digital RF protocol that anyone can develop for and anyone can make radios for.

I'd be very interested in that.  Is M17 going to support use on HF as well a VHF and above?  I know there are bit limits on the lower frequencies, I just don't know what M17's needs are.

Will do! We're already at the "play with it with some computer knowledge" stage using SDRs, or ((soundcards or a TNC3) and a 9600 baud capable radio (e.g. modulator and discriminator taps)).

M17 is 9600 bits per second, and 4800 baud, moving 3200 bits/second of voice data.

However, to a mostly-casual reader, it looks like those baud limits may only be limited to data protocols - not voice, which means we should be good, since we're pretty bandwidth narrow relative to other voice modes in use.
That does imply the limitation applies to pure data M17, though.

I notice above that you said M17 will send the callsign with the voice, like D-Star.  

Will M17 also send additional info such as a brief text message, and GPS location info along with the voice?

Yes. M17 encodes the source and dest callsigns directly, which is very nice to have. :D

There are two obvious voice+data mechanisms, one is assumed and one is specified already.
First: LICH means Link Information Channel. It's the bits you need to recognize the rest of the frames. We send the LICH in full up front at the start of an RF stream, and then chunk it up and send those fragments with each subsequent frame so late joiners can decode.

First, is potential re-use of the encryption nonce bits in the LICH when not doing encryption (since many hams can't and/or won't use it). Might as well put those to use!
(Note: Keeping encryption support as first-class in the protocol is on purpose, and a larger discussion -- for now, let's just say that encryption is legal for hams in Poland, at least somewhat legal here despite the naysayers (don't @ me), and is a good thing to keep to allow for possible commercial adoption).
That's the assumed method. This isn't ideal because the LICH is sent once at the start, and then carved up into chunks across the voice stream, so the nonce payload is supposed to stay static across the voice stream for late joiners. Putting different data in there means it'll either be the same data over and over for the whole voice stream, or it'll be violating a couple of the assumptions we have for using the LICH.

Second, and much better, Codec2 has multiple "modes", different bit rates. Normally we use 3200 bits per second (the highest bitrate Codec2 mode).
That means there are two 20ms 8 byte Codec2 frames per 40ms M17 frame.
Switching to 1600 bits per second frees up half the payload, allowing for mixed data+voice for the low cost of a surprisingly minor difference in voice quality.

Easy and obvious things to put in 8 spare bytes of the M17 half-payload:
lat and lon at 32 bits each,
Speed and altitude, 32 bits each also,
A 64 bit precision timestamp for easy time/date sync,

Maybe less easy things:
APRS packets, DX spots, sunspot information, information on other active reflectors, SMS from APRS 144.39 so everyone can make snide remarks about the guy that won't shut up, codeplug and repeater updates, ...
There is no barrier other than implementing it, testing it, and getting people to use it. Which is still a decent barrier, but lower than all the others!

That's all simultaneous voice+data, and is besides whatever dedicated packet and streaming modes we settle on.

We're looking at a couple possible RX paths for the MD-380 to receive M17.
Our ADF7021 boards aren't assembled yet because foreign customs likes to ask lots of questions apparently. (Questions like "What are these 'quartz oscillators' and 'smd capacitors' made of?")

OpenRTX should release v0.3 soon, including FM support for the MD-UV380 (and maybe the MD-2017 soon after, which is extremely similar).

And I'm inching ever closer to v1.0 of my dream codeplug programming tool.
Which will be pretty bare bones at 1.0, but should be sufficient for most programming tasks, and a helluva lot nicer. More importantly, it lays the foundation for the more automated codeplug programming tools I want to build.
I've got TYT radio firmware updates through my tool working VERY nicely, and will have all OpenRTX releases included along with OEM firmware files. This makes it easy to try out replacement firmware, and easy to flash the OEM firmware again afterwards. And it works on any reasonably modern Android phone in addition to Chrome/Chromium on Linux/Mac.

I spent some time thinking about how to support USB devices for Windows, iOS, and dedicated Firefox users like myself.
There are a couple good options, so it's time to do some prototyping and see what I like best.
Once I release v1.0 I'll make this a priority.

I also spent a little bit figuring out what I'll need to do to get SGP4 on OpenRTX for doing satellite predictions, because that would be a neat feature and I want it!
That would allow for on-radio doppler correction (admittedly mostly pointless for FM, but I still want it) and a much better experience than holding up an antenna, a cell phone for pass predicting, and a radio and finding a fourth arm to push the PTT.  And OpenRTX is already the only way to get a true VFO on the TYT radios, so this would (for me, at least) take the TYT radios from unacceptable for satellite usage to top-choice.

Hams can't encrypt the conversation but theres nothing against cryptographically signing the transmission. Add that to the protocol as a way of verifying the person you are talking to and using the call sign is the owner.

It has been suggested, and may happen. It could easily imply a number of usability and other system management issues if we're not careful.
Especially because we want it to be distributed, no central authorities.

If you have ideas on that front, I'm all ears!

Meanwhile, we've been approached by a conference to give a video/zoom presentation on M17, and I'm having a hard time figuring out what I could present on, if anything.

Let's see, what's new...
We have a weekly net, that's pretty neat. It's always surprising to me how many people show up on the net that aren't in project chat like IRC or discord, though.

I've been porting sgp4 (orbit propagation algorithm) to the OpenRTX platform and getting used to working in C again, and improving the developer tooling for OpenRTX a bunch (screenshots, scripted keyboard events, etc).
We'll have satellite tracking, pass prediction, automatic doppler correction, and more - an MD-UV380 running OpenRTX will shortly be the best VHF/UHF FM ham satellite radio one can purchase.
Don't ask me when, I'm going as fast as I can. Right now there are some bugs in the date/time calculation, and I still need to do a big chunk of the UI, but the concept is well and truly proven, and on the hardware using the onboard GPS no less.

Tracking isn't too heavy, but pass predictions will take the whole CPU on the radio if I'm not careful, so I'm going to deal with that shortly and find the balance between caching pass details vs recomputing when needed.
I spent a lot of time figuring out that I was overflowing the stack on the radio. A 4k stack isn't enough, who knew?
That's a good indicator we need some better tooling for profiling and debugging, so we're working on that too.

OpenRTX+M17: Experiments continue with minor changes to VOX circuit to allow RX of APRS and M17.
The idea is that there's an audio path into an ADC on the main cpu, but it's low-passed.
The experiment is in how little can be removed to get a working M17 demodulator.
It looks like this will only work on single-band MD-380s, as all the other TYT radios have a slightly different setup and lack this path, but even that would be a huge leap forward in getting M17 onto a real radio.


OpenRTX folks figured out the FT-2D firmware updates are unencrypted when they're written to the radio - the firmware flashing program does the decryption and flashes the plaintext.
Why even bother with the encryption wrapper? I dunno, it's Yaesu
Oh, and OpenRTX are booting the MD-9600, now, too. They might have more than that, I didn't pay a lot of attention because I don't have one. Yet.

One member transmitted M17 over QO-100 in one of the wideband channels and discovered the joys of LNB clock accuracy (couldn't decode due to freq drift).
He neglected to grab an IQ recording, so there's been some lessons learned.

I firmly believe OpenRTX - or something very much like it - is going to become the Linux of radios.
It's been a joy to develop on compared to, say, md380tools, and I've been making some quality of life improvements to the developer tooling that should come in handy.
And M17, or something in the same spirit, is going to be as ubiquitous as APRS, or more so. An open protocol goes a long way.

Speaking of APRS, I think we're going to need a way to pass satellite TLEs in APRS. I don't think there's one already, I looked but it wasn't an exhaustive search, I just ctrl-f'd the APRS101.pdf for "satellite" and "TLE". No results.


Work continues on all fronts, and it definitely feels like it's accelerating - more people show up, more people doing work!
It's surprisingly easy to miss how much work is going on when you're in the thick of it, and that can make it hard to show just how much we're doing.
This is just what I remember, I know it's not everything. For instance, I just remembered there's work on designing an accessory for the GM300 and similar radios to turn them into M17 transceivers.




Edit: Almost forgot - the DMR codeplug tool is going to get a bunch more work this coming week, which should be fun.
I've used it myself a couple times on my phone, but it's not good enough yet - and the code is a little messier than I'd like.
As an example: Adding channels to zones is missing from the codeplug API, which is rather important.
I've hacked it in in the wrong place because I wanted a button to work now rather than later, so I've yet to move that to the right spot.

Set up an APRS server that will respond to a specifically formatted APRS message with satellite pass info?

Yep, there's no standard for TLEs over APRS yet, but if we're lucky, we'll have a need and we'll make one.

You guys should look at Lyra. It sounds spectacular in the samples.

https://ai.googleblog.com/2021/02/lyra-new-very-low-bitrate-codec-for.html

https://opensource.googleblog.com/2021/04/lyra-enabling-voice-calls-for-next-billion-users.html

Yes, we're aware of it! You can see some very good further discussion on Lyra.

In semi-related work, see this Wavenet + Codec2 paper and samples (!!), and David Rowe's more recent Codec2 experiments with NN vocoding. FreeDV2020 has an NN based decoder (decoder _only_, I think, so it's still decodable as "regular" Codec2!).
Codec2's NN modes generally work at even lower bitrates to fit in typical HF bandwidths, but 3kbps voice coding is right in the range for what M17 needs - I'm sure there'll be some interesting experiments coming up based around Lyra.

Lyra requires quite a bit more processor than we have available in these embedded systems - for now. I expect we'll get more cpu power and better, faster codecs in the near future.
Google, the open source community, even Microsoft are all doing some incredible work in this area.

Very familiar with Codec 2. Lyra clearly crushes it.

Right. But Lyra doesn't degrade nicely into something decodable on a microcontroller, and it takes a helluva lot more processing to decode than we have on any of these radios or other platforms.
Which is why I mentioned the Codec2 efforts, which make better decode quality available, but not required. All the better if the ML systems can improve the base vocoder.
Not that Codec2's ML stuff is even remotely close to Lyra quality, but I expect that to improve with time.

In other news, an experimental hardware mod for the MD-380 seems to be likely to work, and tentative mods have been found and need to be tested for the MD-UV380.
The QO-100 sat group has set aside a portion of their bandplan for experimental modes like M17.
And the GNURadio blocks have been started by someone who is very familiar with GNURadio, to put it mildly.

Also, some big news came through, but I'll announce that later when we go public with it.

The big news: ARDC gave us a grant of $250,000 to accelerate development. I wrote the grant proposal.

ARDC? What's that?

https://www.ampr.org/, they're the 44net operators.
They sold a big chunk of IP addresses to Amazon for several million USD and added grant-giving to their capabilities.

What kind of radio transceiver modules are capable of handling the physical layer?  Does a cc1101 have the capabilities to receive the correct 4fsk parameters?

https://m17-protocol-specification.readthedocs.io/en/latest/physical_layer.html#fsk-generation

As far as I can tell, it doesn't do RRC filtering. But I'm a liiiittle out of my depth there. Enough that I don't know what I don't know.

Your best bet for doing M17 RF right now is SDR: https://github.com/mobilinkd/m17-cxx-demod

The M17-on-MD380 project seems to be coming along nicely with just minimal hardware mods, but it's not usable yet.
I saw some eye diagrams go by in the chat that showed massive improvements on MD-380 and MD-UV380.

Otherwise, we've been doing ADF7021 so far, or piggybacking on existing transmitters with something like the TNC3.

If you're interested in building, hop in chat!

I started reading this thread but was totally confused??!!

Whatever this project is, best of luck!

Bill

The RRC seem like a reasonable answer.  I was driving the cc101 with an ESP8266 with 4fsk at 4800 baud, and I was able to get to about a 6KHz total freq deviation, and receive a valid message from unit #2.  I was trying to close in on 3.6Khz, but lost the signal.   Reading on the RRC it clearly helps with the interference on adjacent bands.  The cc1101 is just too sloppy to squeeze into a 3.6 or 2.4 Khz band.  I have a ADF7021 around that I haven't had a chance to look at.  The specs on that say 3.6Khz is doable, and it has RRC.