Using a SDR device as a digital voice hotspot with MMDVM supported modes like DMR

By Adrian, Sat 28 August 2021, in category Amateur radio

LimeSDR, PlutoSDR, amateur radio, DMR, System Fusion, D-Star, Digital voice

Using GNU Radio and a SDR device as a digital voice hotspot with MMDVM supported modes like DMR, D-Star, YSF

MMDVM is a popular software created by Jonathan Naylor G4KLX which powers the multitude of digital voice hotspots or digital voice repeaters so common today. Using it and some custom hardware you can access DMR, D-Star, YSF and other voice networks worldwide. There are two main software components involved: MMDVM, which runs on a microcontroller board and MMDVMHost which runs on a GNU/Linux host computer, usually something like a Raspberry Pi board and handles connectivity to the network and the main scheduling logic.

Some of us, including me, use a SDR device for most of their amateur radio activities, and want to adapt their SDR to a multitude of tasks, to avoid using multiple hardware device types for the same job. This is why I began to think some time ago if it would not be possible to adapt such an SDR as a digital voice hotspot (with DMR as a target mode, since I already have DMR radios). Luckily, I wasn't the only one targetting this functionality, and there was at least one port of MMDVM to GNU/Linux. This fork of MMDVM (MMDVM-SDR) by Peter Rakesh had already solved the issue of serial port communication with MMDVMHost by using a virtual serial port, enabling it to run on a regular Linux computer instead of a microcontroller and use different audio sample input/out rather then the microcontroller ADC/DAC. With these hard problems already solved, there remained the issue of transmitting the modulated samples through a SDR device.

Some technical details about the ETSI DMR standards and the MMDVM implementation of these standards will follow.
DMR is a radio standard which implements a double timeslot time division multiple access scheme (TDMA). This means that each base station (BS) can carry two radio conversations simultaneously in a single 12.5 kHz channnel, effectively offering double the capacity compared to a single FM 12.5 kHz repeater. More than that, the DMR protocol offers call routing between logical channels called talk groups, as well as direct calls between two DMR radios identified by a unique ID. Besides these advantages, the TDMA access scheme requires very strict timing for base station access, and the mobile station (MS) needs to be time synchronized to the BS and transmit within a specific window of time in order to be received in its own timeslot and avoid interfering with the other timeslot where a different radio transmission can occur independently.
One MMDVM DMR hotspot can operate either in simplex mode, where a single time slot is used for BS downlink and uplink, or in full duplex mode, where both time slots are used and can carry voice transmissions. To ensure the hard timing demands are met, MMDVM runs on a microcontroller and has direct access to the ADC and DAC of the microntroller.
If we run MMDVM on a Linux host instead of a microcontroller and we use a SDR devices as our radio hardware, we will face the following challenges:

GNU Radio implementation

MMDVM provides four level symbols to the ADC/DAC of the microcontroller at a rate of 24000 samples/second. These symbols are already filtered with a root-raised cosine filter and the only thing left to do is to frequency modulate (or demodulate for the receive case) these symbols to obtain a 4FSK DMR signal. GNU Radio can handle this frequency modulation and demodulation as well as any resampling needed, and gr-osmosdr can communicate with most SDR devices. The only thing left to do in MMDVM is to communicate with a GNU Radio process and set up a continuous flow of samples. There are several ways of achieving this: using UDP sinks and sources in GNU Radio and setting up an UDP socket handler in MMDVM, or even better, using ZeroMQ for communication. ZeroMQ is a fairly recent addition to GNU Radio and makes it very easy to communicate and set up a flow of samples between different programs, either on the same machine or even over an IP network.
I've chosen to use ZeroMQ in both MMDVM-SDR and in the QRadioLink flowgraph to set up this flow of samples between both programs. The ZeroMQ sinks and sources in GNU Radio use IPC (inter-process communication) as a delivery mechanism instead of TCP, to avoid tying up two TCP ports unnecessarily.
The GNU Radio flowgraphs are integrated in QRadioLink, which will serve just as a bridge and as an UI frontend to handle SDR tuning and setup of RX/TX offsets necessary for a full duplex hotspot. A full-duplex SDR device is necessary, however you can also use a simplex device like the HackRF for transmitting and a different device like the RTL-SDR for receiving.

Operation of a DMR duplex hotspot

The first thing to do is to compile MMDVMHost and setup the configuration for a duplex DMR hotspot. An important thing to note is that baseband audio symbols output by MMDVM need to be inverted for proper GNU Radio modulation and demodulation. This is an example of the Modem section of the MMDVMHost config file:

Port=/home/pi/mmdvm-sdr/build/ttyMMDVM0
TXInvert=1
RXInvert=1
PTTInvert=0
TXDelay=0
RXOffset=0
TXOffset=0
DMRDelay=0
RXLevel=100
TXLevel=100
RXDCOffset=0
TXDCOffset=0
RFLevel=100
RSSIMappingFile=RSSI.dat
UseCOSAsLockout=0
Trace=0
Debug=1

This path: /home/pi/mmdvm-sdr/build/ttyMMDVM0 will point to the location of the virtual serial port set up by MMDVM-SDR, which is usually in the same location where MMDVM-SDR is run from.

After compiling MMDVM-SDR, we will need to start this application first to have the virtual serial port ready, then start MMDVMHost as well. If the configuration is done correctly we should see a network connection towards the DMR master server and even some DMR voice frames logged in the console if some static slots are already set up. After they are started, QRadioLink RX and TX activation can also be done. If you activate SDR RX before starting MMDVM-SDR and MMDVMHost, you will probably see QRadioLink freeze for a while and then some console messages about sample overflow. This is not a fatal error however it means the sample buffers are filled and the flowgraphs are simply stopped leading to some overflows.
The deactivation order is also somewhat important. MMDVMHost needs to be stopped before MMDVM-SDR to avoid it hanging because the virtual serial port file descriptor being deleted as MMDVM-SDR shuts down.

Since the BS (our SDR hotspot) sets its own time reference, it can transmit both DMR timeslots just fine. However, the large delays in the sample processing chain mean that the SDR hotspot cannot receive both timeslots in the correct time window. So with a minor change to the MMDVM-SDR code, our duplex hotspot will transmit both timeslots on downlink, but use the DMR direct operation mode (DMO) for MS uplink. All transmissions from the DMR radio will be picked up on timeslot 2 regardless on which timeslot they originate from. This is a hard limitation, meaning you can't use both timeslots to select on which talkgroup you enter the DMR network.
Instead, you can set some static talkgroups on timeslot 1, and then transmit and dynamically activate some talkgroups on timeslot 2 which is received by the SDR hotspot.
While not actually compliant to DMR base station specifications, since you can't transmit to it on both timeslots, this enables two simultaneous transmissions on the BS downlink, while the user can use timeslot 2 on the uplink to access any talk groups which can be either static or dynamically activated.
In my case, I used both an ADALM-Pluto (PlutoSDR) and a LimeSDR-mini device to test this DMR hotspot mode. Since this works for DMR, I see not reason why it cannot also be used for D-Star and System Fusion, which are less complex than DMR since they don't use a TDMA access scheme.
Something which is also worthy of noting is that SDR devices can drift in frequency as they warm up, some of them less and some of them more. This means that you might have to adjust the transmit and receive frequency as the devices warm.
Also, the frame sync correlator implemented in MMDVM is quite sensitive to being off-frequency even as little as 200 Hz. If you notice your radio transmissions are not picked up by the SDR hotspot and logged by MMDVM-SDR, carefully adjust the receive frequency while transmitting and zoomed in on the FFT display until you are very close to the actual receive frequency as displayed by the green filter box in QRadioLink.
The QRadioLink functionality shown here can now be found in the next branch of the source repository, however since this is not released yet, you will have to build it from source until a new release is available. Alternatively, the MMDVM-SDR repository makes available some GNU Radio Companion flowgraphs to achieve the same purpose.

This article was made possible by Jonathan Naylor G4KLX (the author of MMDVM and MMDVMHost), Peter Rakesh (the author of the Linux port, MMDVM-SDR) and thanks also to Johan D. who encouraged me at SDRA 2021 to look into this matter.

PlutoSDR in operation as MMDVM DMR hotspot: