M17 is an open-source digital voice and data protocol built for amateur radio. Its defining feature is that the protocol and the Codec2 speech codec are open, so experimenters can study, implement, modify, and build compatible hardware and software without depending on a proprietary AMBE-family voice codec.
Photo note: the featured image on this post is an authentic NJ2RQ amateur-radio equipment photo used as general station context. M17 compatibility is model-specific; do not assume every radio shown supports M17.
What M17 actually is
M17 is not simply another internet linking system and it is not a variation of DMR, D-STAR, or System Fusion. It has its own RF air interface, framing, addressing, voice encoding, error correction, and reflector network. The current published M17 air-interface specification, version 2.0.4 dated January 21, 2026, defines 4-level frequency-shift keying (4FSK) at 4,800 symbols per second. Because each 4FSK symbol represents two bits, the raw data rate is 9,600 bits per second. The specification targets about a 9 kHz occupied bandwidth with 12.5 kHz minimum channel spacing.
For voice, M17 uses the open-source Codec2 vocoder. In the stable version 2 specification, voice-only operation uses Codec2 at 3,200 bits per second. The protocol also includes forward error correction, packet mode, and metadata capabilities such as text and GNSS position information.
Why hams are interested in it
DMR, D-STAR, and System Fusion are well-established systems, but common implementations rely on licensed AMBE-family vocoders. M17 takes a different approach: the protocol is designed around open specifications and open-source software. That makes it especially attractive to operators who enjoy firmware, software-defined radio, custom hotspots, modem boards, and experimentation.
M17 is also still evolving. The M17 Project has been discussing a future version 3 specification, so a beginner should always check current project documentation before flashing firmware or following an older setup video. This guide deliberately sticks to the stable concepts that are useful today.
Ways to get on M17
1. Use a radio with direct M17 support
The easiest RF path is a radio that already supports M17. Current OpenRTX development information lists the Connect Systems CS7000-M17 and CS7000-M17 Plus as supporting M17 transmit and receive. OpenRTX also supports M17 on some TYT/Retevis models, but support differs by exact model and band. For example, the development-status page lists M17 transmit and receive on the MD-UV380/390 family, while some older MD-380/390 variants have model-specific limitations.
Important: do not flash a radio just because the model name appears in an old guide. Check the current OpenRTX support table first.
2. Use Module17 with a compatible analog radio
Module17 is an open-source M17 modem designed to turn a compatible 9,600-baud-capable transceiver into an M17 station. This is not the same thing as feeding digital audio through an ordinary microphone jack. M17 needs a sufficiently flat baseband/data path, so radio compatibility and cabling matter.
3. Use an M17-capable hotspot or gateway
M17 can also be used through hotspot and gateway software with compatible modem hardware. MMDVM-class hardware and dedicated M17 gateway projects can connect local RF users to M17 reflectors. The exact menu names vary between Pi-Star, WPSD, M17 Gateway, and other distributions, so follow the documentation for the software actually installed on your hotspot.
4. Use software for internet-side experimentation
Software such as DroidStar supports M17 reflector connections in addition to several other digital voice networks. That can be useful for learning the reflector/module structure before building an RF station. If you transmit through any system that ultimately places your audio on amateur radio RF, normal licensing and identification rules still apply.
How M17 addressing works
M17 is callsign-oriented. The air-interface specification encodes source and destination addresses in a 48-bit address field that can represent amateur callsigns and reflector destinations. A DMR Radio ID is not the basic identity used by the M17 air interface. For a normal amateur station, configure your callsign exactly as your radio, hotspot, or client documentation requires.
Reflectors commonly use names in the form M17-XXX and can provide modules or channels identified by letters. The specification itself gives reflector-style destinations such as “M17-M17 C” as an example. Do not assume one reflector or one module is the universal worldwide calling channel; reflector use and activity change over time.
Step-by-step: a safe beginner setup
Step 1: Choose your path
Decide whether you are using a native M17 radio, an OpenRTX-supported radio, Module17 with a compatible transceiver, a hotspot/gateway, or an internet client. Do not mix instructions from two different platforms.
Step 2: Update firmware and host files
Use the current release recommended by the project or manufacturer. Back up your existing radio codeplug or hotspot configuration before flashing anything. On experimental firmware, read the release notes because some functions may still be incomplete.
Step 3: Enter your callsign and RF settings
Configure your amateur callsign, frequency, power, and any required channel-access settings. If a radio requires OpenRTX or hardware modification, verify that the exact model and band support both M17 transmit and receive before attempting an on-air test.
Step 4: Configure the reflector and module
Select a current M17 reflector from your software’s host list and choose a module. UDP port 17000 is commonly used by M17 reflector software such as mrefd, but it is configurable and is not a magic value that every server must use.
For an ordinary hotspot or client, you generally should not start by opening inbound router ports manually. Most clients initiate outbound connections and receive replies through the existing NAT session. Only change firewall or port-forwarding rules when the documentation for your specific server or gateway tells you to.
Step 5: Listen before transmitting
Connect, confirm that the reflector/module shows the expected state, and listen for activity. When the channel is clear, make a short identification such as your callsign and that you are testing M17. Keep the first transmission brief so you can confirm that audio and routing are correct.
Step 6: Test locally when possible
Some reflector software provides a parrot or echo function. On mrefd, for example, a client can use a parrot destination to receive its own short voice stream back. This is an excellent way to check audio without repeatedly calling on a busy module.
Common M17 problems
- No transmit audio: a modified radio or external modem may not have the required flat baseband/data path.
- Receive works but transmit does not: some OpenRTX targets have model- or band-specific TX limitations. Check the current support matrix.
- Hotspot will not link: refresh reflector host files, confirm DNS and internet access, and verify the reflector name/module.
- Wrong identity: make sure your amateur callsign is entered correctly; do not substitute a DMR Radio ID where an M17 callsign is expected.
- Choppy audio: check RF level into the hotspot, frequency calibration/offset, packet loss, and CPU/network load.
- An old tutorial disagrees with your screen: hotspot dashboards and M17 software change. Use the current project documentation rather than forcing an old menu sequence.
What I corrected from the original draft
The earlier draft incorrectly mixed IAX Direct and a supposed “D-Link” mechanism into M17. Those are not core M17 protocol features and have been removed. It also described 9,600 as a baud rate without distinguishing it from the 4,800-symbol-per-second 4FSK symbol rate, treated a DMR-style Radio ID as required M17 identity, claimed a specific reflector/module was the universal calling channel, and told readers to open UDP 17000 on their router as a general client requirement. Those points have been corrected.
Bottom line
M17 is one of the most interesting open digital-radio projects because both the protocol and its Codec2 voice technology are available for experimentation. The practical entry points today are a native M17 radio, an OpenRTX-supported radio, Module17 with a compatible 9,600-baud-capable transceiver, or an M17-capable hotspot/gateway. Start with current hardware support information, use your callsign, choose a reflector/module from a current host list, and test with short transmissions before building a more complex station.