News feed

  • New hardware: Raspberry Pi shields with CC1200 and SX1255 chips!

    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 repository with the CC1200 shield is here:
    https://github.com/M17-Project/CC1200_HAT-hw

    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.

    Firmware is available through a separate repository:
    https://github.com/M17-Project/CC1200_HAT-fw

    Quick details behind the design:

    • 420-450 MHz range
    • approx. 20mW power output
    • frequency mod/demod1 only, excellent M17 capabilities
    • can be flashed over SWD, RPI’s UART, or USB-C2
    • half-duplex
    CC1200 Raspberry Pi Zero shield.

    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.

    It is all, of course, open-source. The GitHub repository with the SX1255 shield is here:
    https://github.com/M17-Project/SX1255_HAT-hw

    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.

    1. On-Off Keying (OOK, also known as CW) is also possible. ↩︎
    2. Flashing over USB remains untested. ↩︎
  • Quick ADF7021 and CC1200 comparison

    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.

    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.

    It’s immediately obvious that the CC1200 gives much better ACPR. Last, but not least, let’s have a look at harmonics and other distortion.

    With the measurement’s settings used, the CC1200’s harmonic content couldn’t even be detected.

  • M17 packet mode reception with a RPi Zero CC1200 hotspot shield

    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.

    Let’s move on to the receiver part. RPi-interface (and therefore CARI with its commands) was used to control the CC1200 shield over UART (/tty/AMA0) – the reception frequency and baseband’s sample rate were set. To pass the baseband stream further, I used picocom:

    picocom /dev/ttyAMA0 -b 460800 > /tmp/fifo1

    Use of this named pipe was required to move further with the GNU Radio flowgraph including a symbol synchronizer. Its output was set to another named pipe: /tmp/fifo2. The flowgraph expects a baseband stream coming from the RF chip at 24 kHz sample rate. Each sample received over UART is a signed 8-bit value, so conversion to floats was necessary. One tricky part was to set the scale coefficient just right, so the 4FSK-RRC symbol set of \(\{-3, -1, +1, +3\}\) had correct amplitudes. Plotting a histogram using a short filtered baseband data dump helped a lot. As an extra, the flowgraph removes the DC component of the signal by subtracting a moving average calculated over the last 100ms. The CC1200 offers an internal AFC that can be enabled, but I was too lazy to mingle with the rpi-interface code to enable it.

    After generating the python code for the flowgraph, one line of it required a quick edit to be executable by Raspberry Pi’s GNU Radio 3.8:

    gr.top_block.init(self, "Headless M17 symbol synchronizer", catch_exceptions=True)

    The catch_exceptions=True part had to be removed. From there, it was easy-peasy. To test the whole setup, I used m17-packet-decode from the M17_Implementations tool set.

    The decode was flawless. Time to move on to something more meaningful: transferring packets to a reflector. This is the point where I used marvellous Go code from Jim N1ADJ.

    All my text messages reached the reflector and were successfully passed to connected clients.

    Many thanks to both Jim N1ADJ and Tom N7TAE for helping me out with the Internet side of the M17 protocol. You guys are awesome.

  • M17 Rust library is now available

    Great news from Tom, VK7XT:

    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.

    Keep up the good work, Tom!

  • Is M17 any better than DMR?

    One of the first M17 transmissions using a modified Nokia 3310/3330. Not too complicated using libm17. There’s a wiki article on how to generate M17 baseband with the library.

    The transmission was received with an RTL-SDRv3 on 433.475MHz – IARU R1 designated M17 calling frequency! 🙂

  • M17 support in a Nokia 3310?

    Sure, why not? Just replace the mainboard with the one Woj SP5WWP designed, flash it with the sample firmware, et voilà.

    SA868 “open edition” 1W UHF module by NiceRF is used. The module runs OpenRTX open-source firmware.

    Please note that the project is very early in its development and the functionality offered is very limited. Nothing beyond text entry has been tested, but transmitting M17 should be straightforward to implement.

  • SR5MS repeater down

    Due to technical problems with the feed line and, hopefully temporary, lack of funding, we were forced to disable SR5MS M17 repeater site in Nowy Dwór Mazowiecki, Poland. This was the first repeater to support M17 mode and for a long time remained a true proving ground for the Protocol.

    The SR5MS repeater requires an upgrade from a legacy configuration based on a Motorola MTR2000 to a modern, RRU-based setup.

    We will keep you informed about the status of this repeater.

  • m17project.org updates

    We are still working on our new website – currently moving content from the old homepage. Some articles are outdated and will be removed, other need updates. Thank you for your patience. Stay tuned!