Every other digital voice mode arrived from the commercial world and was adapted for amateur use. M17 was designed the other way around — and the feature list shows it.
The other five modes on this site began life as commercial or public-safety products. Their capabilities are whatever the manufacturer chose to expose to amateurs, and their limitations are usually the residue of a business decision made somewhere else.
M17 has no manufacturer. The specification is published under the GPL, the reference implementations are open source, and the feature set was chosen by the people who intended to use it. That difference shows up everywhere in what follows.
Everything M17 does rests on a single structural decision: there are two fundamentally different ways to transmit.
| Mode | What it is | Used for |
|---|---|---|
| Stream | A continuous transmission that runs for as long as you hold the key | Voice, or a continuous data stream |
| Packet | A discrete, finite burst — sent, completed, done | Text messages, position reports, application data |
Stream mode gives a net bitrate of 3200 bps. You can spend that in one of two ways — and this is the design choice that separates M17 from everything else:
Read that second line again. Voice and data at the same time, in the same transmission, as a first-class feature of the protocol — not a side channel bolted on afterwards, and not a separate transmission you have to stop talking to send. The data path is designed in, and the cost is stated honestly: you halve the bitrate available to the voice.
Every other amateur digital voice mode treats data as an accessory. M17 treats it as a peer.
This is the section that surprises people, and it is worth sitting with for a moment.
An M17 packet begins with a data type specifier — a small number that says what kind of payload follows. The specification reserves a list of these identifiers, and the list is a statement of intent:
| ID | Protocol | What it means |
|---|---|---|
| 0x00 | RAW | Arbitrary binary data. Whatever you want, with no structure imposed. |
| 0x01 | AX.25 | The classic amateur packet radio protocol, carried inside M17. |
| 0x02 | APRS | Position, weather, telemetry — the existing APRS world, natively. |
| 0x03 | 6LoWPAN | IPv6 over low-power networks. Yes, really. |
| 0x04 | IPv4 | Internet Protocol packets, over the air, over a voice mode. |
| 0x05 | SMS | Text messaging — a null-terminated, UTF-8 encoded string. |
| 0x06 | Winlink | Amateur email and message forwarding. |
IPv4 and 6LoWPAN, in an amateur digital voice protocol. No other mode on this site has anything remotely like it. That single table tells you more about M17’s ambitions than any amount of marketing prose: the designers did not set out to build a voice mode with a text feature. They set out to build a data link that happens to carry voice extremely well.
A packet carries roughly 800 bytes of payload — small by internet standards, and entirely adequate for a message, a position report, or a short command.
A note on what is specified versus what is shipping. A reserved protocol identifier in a specification is a door, not a room. The fact that 0x04 is reserved for IPv4 does not mean your radio does IPv4 today. M17 is a young protocol and the gap between what the spec permits and what any given implementation supports is real. Treat the table above as the shape of the design, and check your own software for what it actually implements.
SMS is not an add-on in M17 — it has its own reserved protocol identifier (0x05), and messages are UTF-8 encoded and null-terminated. UTF-8 is worth pausing on: it means the message field is not limited to plain ASCII. The protocol was written by an international project, and the text encoding reflects that.
Because SMS rides on packet mode rather than stream mode, a text message is a discrete transmission with a defined beginning and end. It is not squeezed into the gaps of a voice transmission. It is its own event on the air.
Alongside the two modes above, M17 provides a low-rate channel for small, repeated pieces of data — GNSS position reports and telemetry being the obvious cases.
The purpose is different from packet mode. Packet mode is for sending something. The side channel is for continuously being somewhere — the small, boring, endlessly repeated facts about a station that want to travel along with the voice rather than interrupt it.
Buried in the data link layer of the specification is something no other amateur digital voice mode has: a standardized bit error rate test mode.
In BERT mode, a station transmits a preamble followed by an indefinite sequence of known test frames. A receiver compares what it got against what it should have got, and the error rate falls out. That is all it does. There is no voice, no data, no message.
The specification is explicit about why it exists: to make interoperability testing possible across independent M17 hardware and software implementations, and to help operators configure and tune equipment.
Think about what that implies. A commercial protocol does not need a standardized public test mode, because there is only one implementation that matters — the manufacturer’s, and they test it in a lab you will never see. M17 needs one precisely because anyone can build an implementation. BERT mode exists because the project assumed, from the beginning, that there would be many independent radios and many independent software stacks, built by people who had never met, that all had to work together on the air.
It is a small feature. It is also, quietly, the most revealing thing in the entire specification.
The word “open” gets used loosely. In M17’s case it has three concrete, checkable meanings.
You can read the entire protocol, for free, today. Not a marketing summary — the actual bit-level document: frame structures, error correction, callsign encoding, the lot. Compare that with trying to obtain the complete details of a proprietary mode.
You can read the code that encodes and decodes the protocol, run it, modify it, and build on it. Independent implementations exist and are expected to. This is also why BERT mode had to be invented.
This is the big one, and it is the hinge that the rest of the digital voice world turns on. DMR, D-STAR, C4FM and NXDN all depend on the licensed AMBE family, which is why transcoding between modes so often requires a hardware dongle. (P25's IMBE is proprietary too, but its patent has expired, so it at least runs in free software.) M17 uses Codec 2, which is free. That single choice is what makes a fully open, software-only M17 station possible at all.
The vocoder story is the thread that ties the entire digital voice world together — and it deserves more room than a paragraph. It is told properly in AMBE and Codec 2.
| Capability | M17 | The others, broadly |
|---|---|---|
| Simultaneous voice and data | Designed in — split the stream 1600/1600 | Varies; generally an accessory rather than a peer |
| Carrying other protocols | AX.25, APRS, IPv4, 6LoWPAN, Winlink reserved in spec | Mode-specific data features, not general protocol carriage |
| Text messaging | Reserved protocol ID, UTF-8 | Present in most, implementation-specific |
| Standardized test mode | BERT, written into the spec | None |
| Vocoder | Codec 2 — free and open | Proprietary; AMBE still licensed, P25's IMBE patent-expired |
| Specification availability | Public, GPL | Varies from partial to closed |
M17’s capability list is not the longest in digital voice. It has no equivalent of Fusion’s snapshot camera or its group-monitoring features, and it carries none of the operational polish that comes from a manufacturer with a product line to defend.
What it has instead is coherence. Every capability above follows from the same two decisions — that the protocol would be open, and that data would be a first-class citizen rather than an afterthought. The reserved protocol table, the splittable stream, the free vocoder and the standardized test mode are not a list of features. They are four consequences of one idea.
Whether that idea produces a mode you want to operate is a separate question, and it depends entirely on what you want from digital voice. But it is worth understanding on its own terms — because it is the only mode on this site that was designed by amateurs, for amateurs, with nobody else’s business model in the room.