Nostr notes by M17 Project (Unofficial)

An unmodified C62 can not decode TETRA… Or can it? Am I crazy? ...

2026-10-27T13:49:32Z

An unmodified C62 can not decode TETRA… Or can it?

Am I crazy? Without a doubt, but at least I focus my craziness on a good purpose. My last idea was to find out if all of the following assumptions are viable:
demodulating pi/4-DQPSK is possible with a plain, analog FM demodulator that works wide enough
Beken BK4819 chip can work wide enough to demodulate 25kHz channels
the CSK6011B MCU can run the whole TETRA stack plus the vocoder on top of it
The answer is… yes to all.
Let’s analyze it step by step.
The modulation is differential (note the D in its name, it stands for Differential), meaning that we only need to care about phase transitions. Phase transitions are nothing but frequency changes, therefore pi/4-DQPSK can be treated as 4-level FSK after frequency demodulation.
It turned out that BK4819 can indeed work with 25kHz-wide channels, it is a matter of setting a single register. Its response is not completely flat, but can be equalized using a simple FIR filter.
Yes, but that required dumping osmo-tetra and ETSI’s vocoder reference code completely. I had to replace both with libtetra and OpenACELP. They are based on ETSI EN 300 3xx-x TETRA standards and are optimized for 32 bit MCUs, including our beloved Cortex-M4/M33 (seen in most of OpenRTX targets).
I wrapped it all up on top of turnrye’s OpenRTX fork (this one is focused on M17 and uses the DSP firmware part setting the baseband sample rate to 48kHz). My fork is here. The build process pulls ETSI’s codebooks for their ACELP vocoder, so make sure you do not distribute the binaries (as they are embedded). TETRA is available through the quick menu key, the [5] key switches between M17, FM, and TETRA.
Below, I attach a video showing a successful TETRA decode using a TMO transmission sample from the HamTETRA group. Big shout out to Manoel ON6RF for granting me access to their samples database.
Have fun!

https://m17project.org/2026/10/27/an-unmodified-c62-can-not-decode-tetra-or-can-it/

#tetra #etsi #differential #yes #phase

#rss #feeds #linksharing #qwibbit

OpenACELP update OpenACELP vocoder has been updated to pull ETSI ...

2026-10-26T04:59:02Z

OpenACELP update

OpenACELP vocoder has been updated to pull ETSI EN 300 395-2 tables at build-time. It is now a clean-room implementation of the TETRA voice coder.
The build process offers two solutions:
a speech corpus file can be used to generate user’s own LSP codebooks, the gain codebook remains WIP
download and use ETSI’s codebooks making OpenACELP TETRA-compatible
When using ETSI’s codebooks, make sure you do not distribute the compiled binary, as distribution of the codebook tables is prohibited. More details in the repository’s readme files.

https://m17project.org/2026/10/25/openacelp-update/

#etsi #lsp #wip

#rss #feeds #linksharing #qwibbit

Neural Codec2 decoding for DroidStar Our experimental fork of ...

2026-10-18T12:56:49Z

Neural Codec2 decoding for DroidStar

Our experimental fork of DroidStar can now decode M17 voice with a neural vocoder. The new decoder comes from Codec2-mod-neural, which uses the FARGAN network from the Opus project. It takes the same Codec2 3200 frames every M17 radio already sends and turns them into wideband 16 kHz speech instead of the classic 8 kHz sinusoidal synthesis. Nothing changes on the transmitting side, the bitstream is untouched, so you get the improvement on every 3200 bps M17 stream you receive, no matter who is talking.
Installing
Download the zipped APK file below.
Unpack it and open the DroidStar.apk file. Android will ask you to allow installs from your browser or file manager – allow it.
If you already have DroidStar installed and Android refuses to update it, uninstall the old version first and install again. Your settings (callsign, hosts) will need to be entered again.
Download DroidStar with Codec2 neural enhancer
To enable the neural synthesizer, go to Settings and scroll down to “Neural Codec2 decoder (M17 3200)” – tick it. Connect to a reflector afterwards, as usual.
Tell us how it sounds and which phone you use. Waiting for comments!

https://m17project.org/2026/10/18/neural-codec2-decoding-for-droidstar/

#neural #droidstar #download #settings #khz #opus #apk #installingdownload

#rss #feeds #linksharing #qwibbit

Codec2 3200 meets FARGAN Codec2 3200 carries M17 voice, and its ...

2026-10-17T16:01:54Z

Codec2 3200 meets FARGAN

Codec2 3200 carries M17 voice, and its classic decoder is the weak spot. It’s limited to 8 kHz and has that recognizable buzzy, synthetic sound. Instead of designing a new codec, I wanted to know how far a better receiver could go with exactly the same bits on the air.
The answer is FARGAN, the low-complexity neural vocoder from Xiph’s Opus codec (Valin et al.). The idea is simple. The Codec2-mod decoder unpacks each 8-byte frame into its usual parameters: pitch, voicing, energy and LSPs. Instead of feeding those to the sinusoidal synthesizer, we map them to 20 features per 10 ms and let FARGAN generate 16 kHz speech.
Data: the Opus speech corpus, processed with Opus’s own augmentation recipe, but with features computed by the real Codec2-mod encoder and decoder. An important early lesson: never pair noisy features with a clean target. The network can’t denoise, and my first attempts sounded like speech through a pipe.
Training: Opus’ two stage recipe on rented GPUs1. Stage 1 was 400 epochs (about 14.5 hours), and stage 2 was 50 adversarial epochs (about 37 hours on an RTX 5090). The adversarial stage made a clearly audible difference from its first few epochs.
C library: the model uses about 818,000 parameters, runs on Opus’ own C inference code, and takes about 1.6 ms of CPU time per 20 ms frame on a single x86 core. The ARM64 NEON build compiles and produces matching output, real hardware timing test will follow.
The result is Codec2-mod-neural, a drop-in alternative to codec2_decode(): 8 bytes in, 320 samples at 16 kHz out. Nothing changes for transmitters, and every existing Codec2 decoder still works on the same stream.
Code, training scripts, and the model: https://github.com/M17-Project/Codec2-mod-neural
Next up: integration into DroidStar and mvoice, and later a look at running it on LinHT. ViSQOL benchmarks will also be ran along with synthetic BER tests to assess synthesizer’s noise immunity.
M17 Foundation covered the expense (200 USD) with most of it left for future runs. ︎

https://m17project.org/2026/10/17/codec2-3200-meets-fargan/

#fargan #opus #stage #khz #instead #training #valin

#rss #feeds #linksharing #qwibbit

libm17 updates Two recent commits make libm17 (versions 1.4.0 and ...

2026-10-16T19:28:48Z

libm17 updates

Two recent commits make libm17 (versions 1.4.0 and 1.4.1) a better fit for small microcontrollers, such as the Cortex-M4-based radios OpenRTX runs on.
The first, 5214d99, reduces memory and code size without changing any output. The receive front-end and the Viterbi depuncturing now work in a single pass, and the four convolutional encoders became one. On a Cortex-M4F this reduced the Viterbi decoder context from 1,596 to 620 bytes, decoder stack from about 1.5 KB to 800 bytes, and flash by about 840 bytes. The decoder context changed size, so this is a slight ABI change.
The second, 0c92621, replaces the soft Golay(24,12) decoder used for the LICH with a Chase-II decoder that rejects ambiguous codewords. In simulation, LICH sensitivity improved by about 1 dB, and wrong LICH chunks are accepted 20–80x less often. As a result, decode_str_frame() will report a failed LICH (lich_cnt = 0xFF) more often at low signal levels. On a Cortex-M4, decoding a stream frame takes roughly 30-40% more CPU than before, which is still less than OpenRTX’s own decoder. The same commit uses a hardware popcount where the target has one and makes the unit tests compile without warnings.
LSF, payload and transmit output are unchanged, and the public API is the same. In simulated tests against OpenRTX’s hard-decision frame decoder, libm17 needed about 3 dB less SNR for a successful decode.

https://m17project.org/2026/10/16/libm17-updates/

#lich #viterbi #openrtx #golay #abi #lsf

#rss #feeds #linksharing #qwibbit

LinHT Rev C – ready for tests! Vlastimil OK5VAS just sent me a ...

2026-10-16T19:00:03Z

LinHT Rev C – ready for tests!

Vlastimil OK5VAS just sent me a nice set of photos (click to enlarge).
Coffee and a PCB – such a great combo
Front side
Back side
Standby for test results!
The LinHT project is proudly supported by the M17 Foundation and their generous donors.

https://m17project.org/2026/10/16/linht-rev-c-ready-for-tests/

#linhtrev #pcb #back #front #coffee

#rss #feeds #linksharing #qwibbit

CARI 2.1 is out, along with new libcari Version 2.1 of CARI, the ...

2026-10-16T05:14:28Z

CARI 2.1 is out, along with new libcari

Version 2.1 of CARI, the Common Amateur Radio Interface, has just been released. The biggest change as compared with the previous 1.3 is a clean way to end a transmission. The master sends an empty uplink (UL) message, and the device plays every buffered sample, ramps down, and disables its transmitter on its own. The release also turns the remaining open points into firm rules: status precedence, socket binds, supervision edge cases, TX stop, and UL underrun trips. Rebinding or closing the UL socket now discards any unread data. A more complete changelog is available in the commands.md file.
CARI spec: https://github.com/M17-Project/CARI
The protocol now has its own C library, libcari. It covers frame encoding and decoding, capabilities, sample scaling and baseband compression (based on FLAC), plus ready-made ZeroMQ slave and master layers. Both tools below are built on it.
libcari repository: https://github.com/M17-Project/libcari
cari-dummy-device now emulates the planned SX1255-based RRU v2: one full-duplex I/Q subdevice at 400–510 MHz and 125, 250 or 500 kHz, with FLAC compression and supervision. Its emulated hardware runs in real time, so backpressure and underruns behave as they would on the real board. The tool can be used to develop and test CARI masters without hardware.
cari-dummy-device repository: https://github.com/M17-Project/cari-dummy-device
cari-ctrl has been rewritten for CARI 2.x. It can inspect and configure a device, capture RX samples, transmit files or test tones, and monitor supervision data, all from one command line. cari-host is now obsolete and the repository is archived (read-only).
cari-ctrl repository: https://github.com/M17-Project/cari-ctrl
Bug reports and pull requests are welcome. Have fun while we are working on RRU v2

https://m17project.org/2026/10/10/cari-2-1-is-out-along-with-new-libcari/

M17 WPSD fork now supports SMS In July 2025, G4KLX removed M17 ...

2026-10-16T04:30:22Z

M17 WPSD fork now supports SMS

In July 2025, G4KLX removed M17 from MMDVMHost and M17 was removed from WPSD. The M17 Project responded by creating forks of the code that kept M17 working, but those forks had fallen behind upstream. Working with Claude Code, I (Jim Ancona N1ADJ) brought the underlying code up to date. With these updates, the M17 Project forks of MMDVMHost and M17Gateway are now current with the upstream repositories. In addition, M17 packet mode (SMS) works from end to end: radio, hotspot, gateway, reflector and dashboard. WPSD users will see the changes with their next nightly update or they can trigger a manual update to get them sooner.
MMDVMHost Branches
Earlier this year, upstream started to add MQTT functionality to MMDVMHost. Those changes broke backwards compatibility, so the last compatible release is tagged as v1.0. Dashboard software like WPSD and Pi-Star hasn’t moved to the MQTT release yet. The M17 Project’s MMDVMHost has these branches:
v1.0: G4KLX’s last release before the move to MQTT, with M17 restored. It still talks to dashboards through log files, which is what WPSD uses. It also includes a set of bug and security fixes backported from G4KLX’s current code.
master: G4KLX’s current code, with M17 restored. This is the version with MQTT (next section).
archived-master: The fork’s previous code. We don’t plan to modify this branch. If you cloned the repo before October 2026 you should review the README.
Each branch is G4KLX’s code plus a small set of M17 commits. That makes future upstream updates straightforward and easy to review.
The M17 WPSD fork now uses the v1.0 branch. If you’re running a custom hotspot or repeater setup and want to try the MQTT approach, master is the branch to use. On master, MMDVMHost publishes its status and activity as JSON over MQTT instead of writing log files for dashboards to parse. M17-related messages are documented in the repository’s schema.json. They include:
M17: voice and data activity including callsigns, source (RF/network), action (start/end/lost…), type (voice, data or packet), duration, ber, and rssi with min/max/average.
M17Packet (new): one message per packet, with protocol, length, and text for SMS or data (hex) for anything else.
M17 Packet Mode (SMS)
M17 packet mode allows sending SMS messages and other data over the air with M17. It’s been in the M17 spec and supported in other software for a while, but now it’s available in MMDVMHost-based software like WPSD.
The new code:
receives and decodes M17 packet transmissions, including SMS
repeats them on repeaters and duplex hotspots
forwards them to reflectors on the network
transmits packets received from the network
You need SMS-capable radio firmware to use this. The OpenRTX developers are working on it, so keep an eye out for a release.
M17Gateway
M17Gateway, the component that communicates with M17 reflectors like mrefd, got some updates as well:
Packet support: carries packets (M17P) between the hotspot and reflectors that support it, and ECHO returns packets as well as voice.
Reflector protocol update: We now support both legacy and current releases of mrefd along with urfd and other reflectors that support the M17 INet spec. (Thanks to Tom, N7TAE for his help with the design!)
Voice announcements: give the full reflector name and module letter for all reflectors.
WPSD
The updates to M17 are live now. New binaries arrive through WPSD’s normal nightly update, and the dashboard will show SMS in the last heard list. The binaries are now built automatically with GitHub Actions from the M17 Project repositories, so future fixes will reach users quickly and easily.
One caveat: SMS also needs modem firmware with M17 packet support. For MMDVM_HS_Hat, Dual Hat, generic GPIO and MMDVM repeater boards, you will need to update the firmware with WPSD’s firmware updater, unless you’ve already done that using m17-hotspot-installer. Other hotspot boards (ZUMspot, Nano hotSPOT, NanoDV, SkyBridge…) don’t have packet-capable firmware yet.
Another known limitation: ADF7021 hotspot boards (ZUMspot, MMDVM_HS_Hat, the dual hats…) can only listen for one mode at a time. With multiple modes enabled, they take turns, so they hear M17 only part of the time. M17 voice can recover from a late start, but a short SMS can be lost completely. So our recommendation is that for reliable SMS you only enable M17. Full MMDVM repeater boards don’t have this problem.
The code is on GitHub in the M17-Project organization:
MMDVMHost: https://github.com/M17-Project/MMDVMHost
M17Gateway: https://github.com/M17-Project/M17Gateway
WPSD-Binaries: https://github.com/M17-Project/WPSD-Binaries
WPSD-WebCode: https://github.com/M17-Project/WPSD-WebCode
I’ve tested the v1.0 branch on M17 and DMR, but the community can help a lot by trying different branches, modes and hardware. If something doesn’t work or you have questions, we’d like to hear about them on the M17 Discord or by creating an issue in the corresponding GitHub repository.
Acknowledgements
Thanks to the developers and projects that this work builds on, including:
G4KLX for MMDVMHost and M17Gateway
CA6JAU for the MMDVM_HS firmware
W0CHP and the WPSD developers
The OpenRTX developers
KD0OSS for the original packet work, which the firmware support builds on
Ember for the backported MMDVMHost fixes

https://m17project.org/2026/10/13/m17-wpsd-fork-now-supports-sms/

Codec2 neural enhancer tests To keep the post short, I will only ...

2026-10-16T03:31:45Z

Codec2 neural enhancer tests

To keep the post short, I will only focus on what kind of work has been done so far and provide a few samples for your judgment.
Rationale: we often hear that Codec2 does not sound good, or that it is “no better than other DV modes”, or plain “analog FM sounds better”. Well – sure, Codec2 might not really offer anything better than AMBE/IMBE in the technical sense – all of these vocoders are based on LPC and simple glottal excitations. They sometimes perform better, sometimes worse. A solution to that, while keeping the whole M17 protocol intact, is to change how the speech is reproduced at the receiver.
Motivated by earlier research conducted by Felix Schäfer (DD8SF) – Applications of Neural Vocoding Techniques in Amateur Radio (as presented at the M17 Conference 2025), I decided to train a full GAN network using a LibriSpeech corpus (English). Thank you very much for the groundwork in this field. I decided to pick FARGAN as the reference approach, and apply it onto Codec2-mod, 3200bps mode. Codec2-mod has been selected because it is much more computationally efficient than the reference Codec2 implementation written by David Rowe, VK5DGR, et al. The last step of the FARGAN approach has been intentionally omitted for now (additional fine-tuning with low learning rate).
The idea is this: at the receiver-side, take the Codec2 frame parameters (simply tap in) and pass them to a neural speech synthesizer, instead of the one provided by Codec2. This way the bitstream transmitted over RF stays the same for every M17 user. The only thing that changes is that you can chose the speech synthesizer – the one provided by Codec2, or the neural-network-based one. This enhances the sound quality on your side only. The only limitation is that it requires some computational power, and therefore can not be executed on a plain STM32 (OpenRTX targets). To put it simple – the enhancer works on top of Codec2, without changing or modifying anything else. It can be ran in realtime on smartphones and PCs (vide: DroidStar, mvoice, etc.) at very little CPU cost.
Audio samples, starting with the source recording:
Reference input audio, sampled at 16kHz
The sample below is more or less what the microphone would pick up at the transmitter side.
Reference input audio, resampled at 8kHz
And this is roughly how M17 sounds today. Plain Codec2, 3200bps:
The 8kHz audio sample, Codec2-encoded
The next two files show how FARGAN behaves when it is used as a replacement to Codec2’s synthesizer.
FARGAN-based synthesizer, 8kHz
FARGAN-based synthesizer, 16kHz
The 16kHz sample shows how the network reconstructs the missing spectral information from the available 8kHz of bandwidth. The bitstream stays the same – 3200bps.
The next step is to bring the finely-tuned enhancer and perform some adversarial training and apply it to the output to, hopefully, make it sound even better and less metallic. After that, I might want to try it on top of DroidStar to see how it works with real Codec2 bitstreams.
Comments are welcome.

https://m17project.org/2026/10/13/codec2-neural-enhancer-tests/