Building an M17 Hotspot

Most hotspot guides start with Pi-Star or WPSD. This one doesn't. This is a dedicated, single-mode M17 hotspot built on the M17 Project's own software stack — a Raspberry Pi, a USB modem stick that was never modified, and about four repositories from one GitHub organization.


Why not Pi-Star or WPSD

The usual multi-mode distributions are built around MMDVMHost. In July 2025 M17 support was removed from MMDVM upstream, and WPSD followed. Pi-Star kept it, so a Pi-Star hotspot can still do M17 alongside everything else.

But a general-purpose distribution carries a lot of machinery you don't need if M17 is all you want. The M17 Project publishes its own gateway and its own dashboard. Running those directly gives you a machine that does one thing, with a much shorter path between the radio and the reflector — and no dependence on whether the next MMDVMHost release still speaks the mode.

The hardware

ComputerRaspberry Pi 4B
ModemZUM USB stick, completely unmodified — stock firmware, no reflash
AntennaThe standard stub antenna supplied with the stick
ConnectionUSB, presenting as /dev/ttyACM0 at 460800 baud
BandUHF, simplex

On the USB bus the stick appears as a Leaflabs Maple serial interface (1eaf:0004) — the STM32 development identity that most MMDVM modem hardware reports. Nothing about it was changed for this build.

The modem firmware

You do not have to guess what firmware a stick is running. The gateway asks it at startup, and the modem answers with a description string. On this one:

GetVersion response

ZUMspot-v1.6.1 20231115_WPSD 14.7456MHz ADF7021 FW by CA6JAU, G4KLX, W0CHP. GitID #7e16099

FirmwareZUMspot v1.6.1
Build date15 November 2023
FlavorWPSD build (W0CHP)
Reference oscillator14.7456 MHz TCXO
RF chipADF7021
Git ID#7e16099

The one thing worth knowing

That build date is the whole story. November 2023 predates the removal of M17 from MMDVM upstream in July 2025 — which is exactly why this stick still speaks M17 on its factory firmware, with no reflash. A stick carrying a newer build may not. If you are buying hardware for an M17-only machine, ask what firmware is on it before you order, and read the version string as soon as it arrives.

Worth noting where the two parted: the modem firmware on this stick still carries M17, while the host software above it no longer does. Firmware and host are updated separately and do not have to support the same set of modes.

Where to get the firmware

Before anything else, read the version string off your own stick. The gateway logs it at startup, and on a Pi-Star or WPSD machine the dashboard displays it. You cannot decide what you need until you know what you have.

SourceWhat it is
M17‑Project/MMDVM_HSThe M17 Project's own fork of the hotspot firmware. The maintained path for M17 today, and the one to build from if your stick's firmware has no M17.
juribeparada/MMDVM_HSThe original MMDVM_HS by CA6JAU, with tagged releases going back years. Where the ZUMspot firmware line comes from.
WPSD modem firmwareW0CHP's builds and update procedure — the flavor running on this stick.

If you are chasing an M17-capable build

Note the date, not just the version. M17 left MMDVM upstream in July 2025, so a build from before that point is the one that carries the mode. If you would rather not depend on an old binary, build from the M17 Project's fork instead — that is the version kept current specifically for this mode.

The software

Everything comes from the M17 Project organization on GitHub. There is no third-party distribution image involved, and no apt repository to add.

ComponentWhat it does
m17-gatewayThe core. Talks to the modem over the serial link, and to the reflector over UDP. Distributed as a prebuilt binary.
rpi-dashboardThe web interface — status, recent activity, gateway configuration, a map, and text messages. Served by nginx.
MMDVMThe M17 Project's fork of the MMDVM modem firmware.
MMDVM_HSThe hotspot variant of the same, for stick-style modems.
CC1200_HAT-fwFirmware for the CC1200 HAT — present for the alternative radio front end, not used in this build. See mspot below, which is the software written for that board.

The operating system underneath is a current Debian — nothing unusual, nothing pinned. The gateway and the dashboard API run as their own unprivileged users, and nginx serves the dashboard on the local network only.

Configuration

One file does the work: /etc/m17-gateway.ini. It is short enough to read in a minute, which is a large part of the appeal.

SettingValue
CallsignThe station callsign
RX / TX frequencyThe same UHF simplex frequency for both — entered in hertz, e.g. 430000000
Power10.0 — the gateway's own 0–100 scale, not watts
Frequency correction+5
ReflectorName and module, e.g. M17-JET module B
Host fileThe reflector list the dashboard maintains
ModemType mmdvm, port /dev/ttyACM0, 460800 baud
LevelsRX and TX level, TX delay, TX hang

There is no codeplug and no programming software. The dashboard's own configuration page edits this file, and the gateway reloads when it restarts.

Watch this one

The reflector module in the config and the destination your radio transmits to must match. If the radio calls module B while the gateway is linked to module A, the hotspot receives your audio perfectly and then discards it — no error, no dashboard entry, nothing on the reflector. It looks exactly like a dead hotspot.

A second M17-only option: mspot

The build above is not the only way to make a single mode M17 machine. mspot, by Tom Early N7TAE, is the other one, and it is worth knowing about before you commit to hardware. The same author wrote mrefd, the M17 reflector software that a good many M17 reflectors run.

It is an independent application. Not a distribution, and not an MMDVMHost front end. Its README calls it "An M17-only hot-spot for amateur radio" and elsewhere describes a "repeater/hot-spot", so it covers both roles. The M17 Foundation's own hotspot page lists it alongside the other options: "N7TAE has created MSPOT an M17-only hotspot (or repeater)."

What it wantsDetail
Computer and radioA Raspberry Pi running trixie, plus the M17 CC1200 Raspberry Pi hat
Other boardsThe README allows that it may work on other single board computers with a Pi compatible 40 pin GPIO header
MMDVM sticksSupported, but in a separate mmdvm branch of the repository, for modems on firmware version 1.6
SX1255 hatListed in the README as future work
DashboardYes, a deliberately small PHP one: "The entire PHP code is contained in this single file. There are no dependencies, except for your .ini file."
ConfigurationOne ini, mspot.ini, copied from the repository's config/ directory, with an inicheck utility that validates it before you run
Buildgit clone, edit mspot.mk, make, sudo make install

Note which way round the support runs

On this page's build, the MMDVM stick is the hardware and the M17 Project software speaks to it directly. mspot is the other way round. Its main line targets the CC1200 hat, and MMDVM support sits in a side branch. That is worth understanding before you buy: mspot is the software written for the CC1200 hat, and m17-gateway is the software that speaks to an ordinary stick out of the box.

If you already own a ZUM stick

mspot's mmdvm branch is documented as supporting modems on firmware version 1.6. The stick in this build reports ZUMspot-v1.6.1, which sits in that line, so it looks like a candidate. That has not been tested here and this page is not saying it works. If you try it, read your own version string first, the same as for everything else on this page.

So the choice for an M17-only machine is between two stacks, and neither of them is Pi-Star or WPSD. m17-gateway from the M17 Project, which is what this build uses. mspot from N7TAE, which is aimed at the CC1200 hat. If you are buying a CC1200 hat, mspot is the software written for it. If you already have a stick, the build described above is the shorter road.

Duplex hotspot

The build above is simplex. One frequency, used in both directions, so the hotspot cannot hear anything while it is transmitting. A duplex machine receives on one frequency and transmits on another at the same time, which is what lets a hotspot work as a repeater rather than a one at a time relay.

The stick in this build cannot do it. A simplex board is called simplex because it carries one transceiver, and no configuration setting adds a second one. Going duplex means different hardware, and there are two routes.

RouteWhat it is
SX1255 Pi hatThe M17 Project's own shield, built around the Semtech SX1255 transceiver. Full quadrature IQ modulation and demodulation, so the modulation happens in software on the Pi rather than inside the radio chip. The project's own wording: "The hotspot works in full duplex."
Duplex MMDVM boardAn ordinary duplex MMDVM hat, the kind already sold for the other modes. The installer's wording is "To run a Duplex HAT in duplex mode", so it is the board that has to be duplex, not the software
CC1200 Pi hatNot a duplex route. The M17 Project describes it as half duplex, frequency modulation and demodulation only, about 20 mW

Software support is recent. m17-gateway added the SX1255 hat on 2 March 2026 and now covers three platforms: the CC1200 hat, the SX1255 hat and MMDVM modems. The project's summary of what that buys you: "Both the SX1255 and MMDVM platforms support full duplex operation, which means they can be used as full M17 repeaters, not just hotspots."

SettingValue
Duplextrue. The installer's own line: "For duplex operation, Duplex must be set to true"
RX and TX frequencyThey must be different: "To run in Duplex mode, the RXFrequency and TXFrequency must be different." Entered in hertz, the same as the simplex build above
Modem baud, MMDVM onlyOften 115200 rather than the 460800 this build uses. Read what your own board supports rather than copying either number

The shield's own README carries a worked example of exactly that split, receiving on 435.000 and transmitting on 438.000: ./sx1255-spi -s 500 -r 435000000 -t 438000000

SX1255 hatDetail
ChipSemtech SX1255. The vendor's own feature list reads "Half or full-duplex operation", on a part covering 400 to 510 MHz
BandTuning range 400 to 510 MHz, and 356 to 562 MHz out of spec, from the shield's own README
HostRaspberry Pi Zero, shield form factor, two SMA connectors
RF power+5 dBm typical, at the 1 dB compression point. About 3 mW. See the note below
License and filesCreative Commons BY-NC-SA 4.0, hardware files in the M17 Project's own repository
Getting oneOrdered through PCBWay as a shared project, minimum quantity five

Less power than the CC1200

+5 dBm is about 3 mW, against the CC1200 hat's roughly 20 mW. The SX1255 board buys full duplex and IQ, not output power, so anything beyond a desk needs an amplifier behind it. The figure was added to the shield's README after this page first went up.

Not tested here

Nothing on this page has been run in duplex. The build described above is the simplex one, on a simplex stick. Everything in this section comes from Semtech's datasheet and the M17 Project's own documentation, not from a bench. Read it as a map of what the hardware and the software say they do.

What it does, and what it doesn't

What M17 uses instead of squelch

An M17 receiver has no squelch in the traditional sense. It decides a transmission has started by detecting a sync pattern in the noise.

Noise can trip that detection, but it does not reach the dashboard as a transmission. There is a mechanism filtering it out, in both the hotspot software and OpenRTX.


The short version

A Raspberry Pi, an unmodified USB modem stick, four repositories from one GitHub organization, and a config file you can read in a minute. If M17 is the only mode you care about, this is a considerably simpler machine than a multi-mode hotspot — and one whose every moving part is maintained by the people who wrote the protocol.


Return to n6jet.com  —  73 de N6JET

A noncommercial hobby reference compiled by N6JET, gathered from public sources and shared freely for anyone interested in amateur digital voice.