When introducing my fellow Austrian hams to M17, I kept hearing the same question: “How does it sound?” This coincided with my desire to experiment with Rust and WebAssembly, creating the perfect opportunity to build a tool that would answer this question while expanding my programming skills.
How it works
m17web consists of three main components connecting to mrefd and working together to bring M17 digital voice to your browser. The system listens to UDP traffic from M17 reflectors, routes it through a proxy server, decodes the audio in the browser using WebAssembly, and presents it through a clean web interface—all without requiring any special hardware or software installation.
You can’t have your cake and eat it, a well-known proverb says. The state of this proverbial cake is strictly determined – it exists in exactly one of two possible states. This is very similar to the rules of Boolean logic – there are two (bi-nary) significantly different values for a logic sentence – true or false, or 1 and 0.
Real-world problems, including measurements, might not always have a strictly defined logical value. Imagine a blue square. The statement “the square is blue” is obviously true, whereas “the square is green” is undeniably false. But what if the square was turquoise, having a shade that’s a mix of both colors? What the logical value of “the square is blue” would be then? False? Or maybe something in between? This is exactly where Boolean logic fails, but soft logic offers a solution.
TYT MD-380 was one of the first platforms to receive M17 support through OpenRTX open-source firmware. A small modification was found out to be required to make it work with our protocol (its stream mode for digital voice). Many MD-380 users performed the required surgery.
Fast forward to Jan 2025: Rick KD0OSS provided a piece of code making it possible to receive and transmit M17 packets – text messages!
I recently came into possession of a C22 handheld transceiver from Retevis.
The C22 is an alternative version of the C62, which is believed to be the same (or a very similar) radio, just with different firmware (with its interface using cyrillic script)1. Both C22 and C62 are advertised as analog FM handhelds with some super-duper fancy AI noise cancelling technology. A fellow ham, Ferdy EB5DQ, recently shared a video on YouTube2 showing the C62 with a cryptic “Digital” mode enabled. The mode is undocumented and can only be enabled through the CPS.
After seeing how successful the M17 packet mode is becoming (and how everyone around seems to be interested in text messaging with M17) I decided to finally revive our forgotten and unmaintained CC1200 hotspot HAT. I quickly bumped up the KiCAD version to 8.0.8, cleaned up the PCB design, and reviewed its bill of materials. Looks like the device should be ready for testing! I already ordered a batch at PCBWay 🙂
The firmware for it is somewhat functional – it already allows for M17 signal transmission and reception. It might be buggy though, as it was created in a hurry before Pacificon 2023, where we showcased it.
Now, when all the hotspots (or at least a vast majority of them) support FM-based analog and digital modes only, we offer you a new solution. A truly all-mode hotspot with full quadrature (IQ) modulation/demodulation available. Want to go beyond 4FSK and try out TETRA’s pi/4-DQPSK or fancy 64QAM instead? With our shield, it is finally possible to do so, on the cheap. The hotspot works in full duplex.
SX1255 – inexpensive IQ mod/demod Raspberry Pi Zero shield.
You can finally run GUI-less GNU Radio flowgraphs on the Raspberry Pi with whatever back-end supporting M17 or any other mode. Sky is the limit. Supported frequency range covers the whole 420-450MHz (70cm) amateur band. The default sample rate is 125 kHz.
The device acts as an I2S master, meaning that it generates the sample and channel clocks for the RPi. You need to enable an appropriate (I2S-slave) GPIO overlay. Details are in the readme, see the link above.
On-Off Keying (OOK, also known as CW) is also possible. ↩︎
The ADF7021 is used by a vast majority, if not all, of amateur hotspots (RaspberryPi shields) out there. Back in the days when this kind of hardware was a novelty, this chip seemed to be one of the best options to choose. It supports 4FSK and raised-cosine (RC) baseband filtering out-of-the-box, the user only has to sustain a transfer of the symbol stream. Sounds good so far, but the problem is that the RC filter in the hotspot’s RF chip, when combined with a square-root-raised-cosine (RRC) filter at the user’s radio side, gives significant intersymbol interference. This is what renders the signal from hotspots unusable at longer distances – the eye plot is not opened wide enough, even at excellent signal-to-noise ratios. The signal transmitted with ADF7021 is just bad, right at the antenna.
Let’s take a closer look at my measurements taken a while back. The first comparison shows eye diagrams, as received with an SVA1032X with a reference RRC filter. The selected frequency, power, and SNR were roughly equal in both tests. A pseudorandom symbol stream was used.
Eye diagram for the CC1200Eye diagram for the ADF7021
Now, let’s take a look at adjacent channel power ratio (ACPR). It tells us how much power “leaks out” into adjacent channels, potentially interfering with the transmissions happening there. I performed two measurements: one for the channel immediately adjacent to the used radio channel (+/-12.5 kHz), the other for +/-25 kHz offsets.
Remember our CC1200 shield for Raspberry Pi Zero? After about a year of stall, I pulled it out of my drawer to test its M17 packet mode reception capabilities. Since the hardware bug in the PCB is minor and doesn’t even seem to affect the device’s operation, I was all set. By the way: all the open issues on its GitHub should be addressed soon.
Now, a quick reminder: CC1200 is a complete RF transceiver chip from Texas Instruments. It covers 70cm amateur band and allows for arbitrary frequency modulation schemes use. In our case, that’s M17 with its square root raised cosine filtered 4FSK. The chip has been proved to offer much better RF and baseband performance than the popular ADF7021. The latter remains popular, as there are numerous boards and shields using it along with a well-known software suite.
The transmitter was my modified Nokia 3310. I used my favorite (and actually IARU-R1 designated!) frequency of 433.475 MHz.
A new M17 library is now available for developers, the M17 Rust Toolkit, which aims to make it easy to build PC-based M17 applications in Rust. I have published the first version today and the crates are now available on crates.io. It is cross-platform and easy to integrate with any Rust software. Rust is an increasingly popular for language for systems and embedded programming, and for those who use it, I hope that a native library will reduce the friction to support M17.
The toolkit comes with a very high-level API. The goal is that a developer is freed from worrying about sound cards, PTT, and buffers. They only need to choose which devices they want to use and then they can start sending and receiving M17 packets and streams with very few lines of code.
The initial version has built-in support for sound cards, receiving with an RTL-SDR, and reading/writing RRC files on disk. The soundmodem uses standard M17 KISS which makes it interchangeable with other types of TNC. Core protocol functions such as encoding and decoding, the TNC, and KISS are located in a separate no_std crate.
It is new code and I am confident there will be bugs! Rust developers are warmly invited to test it out and share any feedback.
