MMDVM runs seven modes including digital voice on one ARM microcontroller

One firmware, seven voice modes

The opening line of the README is the whole scope of the project. This is the source code of the MMDVM firmware that supports D-Star, DMR, System Fusion, P25, NXDN, POCSAG and FM modes. That is a notable amount of protocol work in one program, and it is what makes the project interesting, because each of those digital modes is a separate specification with its own framing, signalling and error correction, and a radio amateur normally needs different hardware or different firmware for each. Running them all on one microcontroller means one box, one antenna feed and one power supply cover the modes in the list. POCSAG and FM are included so the same hardware can also receive pagers and analogue FM, which is a practical addition rather than a technical one.

The hardware requirement is spelled out precisely

The supported platforms are the Arduino Due, the ST-Micro STM32F4xxx and STM32F7xxx processors, and the Teensy 3.5 and 3.6. The README then explains what these platforms have in common, and it is a proper specification rather than a vague statement. They use ARM Cortex-M3, M4 or M7 processors with a minimum clock speed greater than 80 MHz, and they have access to at least one analogue to digital converter, one digital to analogue converter, and a number of GPIO pins. The clock figure matters for digital modes because the sampling rate of the voice codec has to be exact, and the M3, M4 and M7 range is what tells you the DSP and memory budget available. The presence of both an ADC and a DAC is what makes the board a modem rather than a transmitter, since the received audio has to come in and the transmitted audio has to go out through the same digital path. A board that meets the specification can run any of the modes; one that does not cannot run any of them.

Three build paths, and the Arduino one is unusual

The build story differs per platform in a way worth reading before you start. To build the software for the Arduino Due, you need to edit a file within the Arduino GUI, and that is detailed in the BUILD.txt file in the repository. The STM32 support is supplied via the ARM GCC compiler. The Teensy support uses Teensyduino. So the Teensy path is the conventional embedded path, with the Arduino IDE plus a board package, the STM32 path is a standard cross-compile, and the Arduino Due path is the odd one out because the Due is not a native target for either of the other two toolchains. The Makefile at the repository root reflects that structure with separate include paths and object directories for the two STM32 families, with F4_LIB_PATH pointing at ./STM32F4XX_Lib and F7_LIB_PATH at ./STM32F7XX_Lib, and separate object directories obj_f4 and obj_f7. It also links the CMSIS math libraries for each core, and it declares the external clock frequencies the code is compiled against, with CLK_MMDVM_PI at 12000000, CLK_NUCLEO at 8000000 and CLK_12MHZ at 12000000, which are the values you change when your board's clock differs from the reference design.

The source tree shows the signal chain in file names

The repository root is a flat list of C++ sources and headers, and the naming makes the architecture legible without opening a single file. Each mode has its own set. The DMR family is DMRRX, DMRTX, DMRDMORX, DMRDMOTX, DMRIdleRX, DMRSlotRX and DMRSlotType, plus DMRDefines.h. The D-Star family is DStarRX, DStarTX and DStarDefines.h. The FM side is the largest group by file count, with FM, FMBlanking, FMCTCSSRX, FMCTCSSTX, FMDownSampler, FMKeyer, FMNoiseSquelch, FMSamplePairPack.h and FMTimeout, and the FMDirectForm1.h header hints at how the FM demodulator is implemented. The other modes have their own Cal files, CalP25, CalNXDN, CalPOCSAG and CalFM, which suggests calibration rather than a separate demodulator per mode, and CWIdTX, CalRSSI, Config.h, Debug.h and an FMCTCSS pair complete the list. The RX and TX split in the file names is the key structural insight, since a digital voice modem is a receiver and a transmitter sharing a codec, and separating them is what lets a mode be added without touching the other. The tree also carries a .gitmodules file, so parts of the tree come from elsewhere, most likely the STM32 peripheral libraries.

Licence terms, including the ARM code and the stated intent

The licensing section is worth reading in full because it contains more than the usual single file. The software is licensed under the GPL v2 and is primarily intended for amateur and educational use. The GPL v2 choice means that if you distribute the firmware, the corresponding source has to be available, and the README makes the intent explicit rather than leaving it to the licence alone, which is a friendly thing to do given the project sits in a community with shared hardware designs. Portions of the ARM support code carry a separate copyright, ARM LIMITED 2011 to 2013, under a BSD style licence with the usual three conditions, that source redistributions retain the notice and conditions, that binary redistributions reproduce the notice in the documentation or other materials, and that neither the name of ARM nor the names of its contributors may be used to endorse or promote products derived from the software without specific prior written permission. The Makefile carries a matching GPL v2 header naming Andy Uribe CA6JAU and Jim McLaughlin KI6ZUM as copyright holders. The repository is not archived, the last push was on 2026-08-16, and there are no GitHub releases.

Editorial conclusion

Adopt MMDVM if you are an amateur radio operator who wants one hardware platform covering several digital voice modes rather than a separate radio for each, and you are comfortable with embedded C++ and flashing firmware onto a microcontroller. Do not adopt it for commercial deployment, because the project states it is primarily intended for amateur and educational use and is licensed GPL v2. Verify first that your board has the peripherals the firmware needs, since the requirement is an ARM Cortex-M3, M4 or M7 above 80 MHz with at least one ADC, one DAC and a set of GPIO pins, and that your build path matches your processor, since the Arduino Due needs a file edited in the Arduino IDE while the STM32 and Teensy builds use the ARM GCC compiler and Teensyduino.

Frequently asked questions

Official sources

1. g4klx/MMDVM on GitHub
2. Issues
3. License: GPL-2.0
4. README