QRadioLinkRemotely monitoring and accessing the amateur repeater network with the LimeNET Micro SDR and GNU Radio
By Adrian, Sun 30 August 2020, in category Amateur radio
By Adrian, Sun 30 August 2020, in category Amateur radio
In the past 10 months, I've been working on the VOIP capability of QRadioLink, with a few goals in mind. The first one was to obtain a stable test platform for a field configurable multi-mode SDR repeater that can be interconnected to a wider voice network using the Internet (or HamNet). The second one was to have a stand-alone remotely accessible and remotely configurable SDR transceiver that can be controlled with my mobile phone.
While the first application is still in our evaluation phase, the past year brought a number of improvements that made achieving the remote station goal possible.
Two years ago I was kindly sent one of the new LimeSDR-mini transceivers to test on and write some code. The board was at that stage still in development, so my version was not very stable yet, with the support libraries still in the testing phase. However, the potential of the LimeSDR as a fully open design with the backing of a large community was obvious. This year, I decided to check out the new LimeNET-Micro fully integrated SDR platform which re-uses a lot of the components from the LimeSDR-mini project, but adds new ones, becoming a self-contained SDR-computing platform with the addition of a Raspberry-Pi compute module 3 and connectivity options like USB ports, Ethernet and HDMI. And it's not just that. The clock precision of the LimeNET-Micro is much improved compared to the LimeSDR-mini, and it offers an easy option to add a GPS antenna for the included GPSDO.
Obviously, the presence of an integrated Raspberry Pi module gives me the possibility to implement my fully standalone remote transceiver with a network connection port (either Ethernet or Wifi). Since QRadioLink uses GNU Radio, a full Linux environment with quite a lot of RAM and CPU speed is needed, something which the Raspberry Pi CM3 can provide. Because the LimeNET-Micro will not be connected to a screen, I would run the application without the graphical user interface as a system process, which should shave off quite a few CPU cycles. The rest of the hardware setup should be familiar to people who read the FT8 with the PlutoSDR article or watched the SDRA talk. A relay board controlled via USB, the RF switch, some band filters and an RF power amplifier capable of delivering 5-25 Watts in FM mode.
Since I did not set up multiple RF paths, I would be operating on only one band, the 430 MHz amateur band. Obviously, the upcoming LimeRFE hardware would eliminate some of the complexity involved with band filters / amplifiers and RF paths requiring multiple RF switches, allowing one to roam on all bands remotely at will.
The operational setup for the remote controlled SDR transceiver was straight forward. I chose an Ethernet connection from the LimeNET-Micro to my router and a vertical antenna with 2 dB gain. The amateur radio repeters which I planned to monitor and access this way are all FM and are located some 30 km away from my location, on top of a mountain. An output power of 1 Watt would be sufficient to access them.
The voice over IP server is a very small free software program called umurmur which can run even on a router. However, for simplicity reasons I decided to run the VOIP server (or reflector as it is sometimes called by amateur radio operators) on the LimeNET-Micro as well, since it takes very little memory and CPU to run it when only a few users (less than 10) are logged in at the same time. The VOIP protocol is called Mumble, after the original application which is very well known by gamers because of the voice quality and low latency. I've been using this application for the last 15 years to communicate over the Internet, so implementing the protocol in QRadioLink was easy. This protocol supports not only voice, but also text messages, which I used to conveniently provide a control interface to the SDR.
The reason why Mumble's audio quality is so good is because it uses the Opus codec. Unless you are working in this field, I doubt you have heard of this voice codec developed by the Xiph foundation, but you are most certainly using it every day without knowing it with various internet applications. This codec supports bitrates from 5 kbit/s to more than 100 kbit/s, so you can even stream music at high quality with it, although in real-life applications it's used for voice communications.
The VOIP connection from QRadioLink is done using the settings file and the telnet interface, without using the GUI, but in any case this is how the parameters would look in the GUI if it were used
The first test was to check that I can receive the repeaters while connecting from my laptop using the standard Mumble desktop application.
Obviously we need to select the proper server channel to be in, otherwise we wouldn't hear a thing
This worked fine, and I also invited a few friends to log in and listen to the FM repeater audio, to confirm the perceived quality. The VOIP bitrate towards the server is configurable in QRadioLink with several settings available to be chosen depending how much Internet bandwidth we can use. Obviously, the more clients connected to the server, the more bandwidth needed for all simultaneous streams. Experimentally, I determined that 24 kbit/s is enough to have good quality, even in the presence of FM demodulation noise.
Next, I wanted to be able to use the transceiver while mobile, and this is possible with the Plumble Android application, which is an open source implementation of Mumble for Android. It has all the useful features needed, including the ability to transmit voice by pressing a PTT button on the screen or a physical button. It also works well with Bluetooth headsets, which comes handy when mobile with the car.
Plumble user interface
Configuring the GNU Radio flowgraph parameters, the LimeNET-Micro hardware frequency and RF gains and other internal settings of QRadioLink was done using text messages sent to the QRadioLink Mumble client (as YO8RZZ-ntAV in the image above). This user processes commands received via private text messages to configure almost everything that is configurable via the graphical user interface. Of course, typing commands on the mobile phone is maybe a bit arcane and cumbersome, but the most important thing is that it's very simple. The user will even give you a list of commands and possible parameters if you type help or ?.
Controlling the LimeNET-Micro remotely using Plumble from the mobile phone
Something to note is that the way Mumble operates is by having several configurable logical server channels or "rooms" which can have as many users as you want (or can support on the Internet pipe) connected simultaneously and listening or speaking. Mumble is full duplex, so more than one user can speak at the same time on a channel without issues. The problem was that the QRadioLink audio layer couldn't handle this properly, so when more than one user spoke and the audio was transmitted by the LimeNET over FM, it came out horribly garbled. This lead to some work on the internal audio mixer to be able to allow multiple users to be heard at the same time over radio, which also comes in handy when we want to have a VOIP network connected repeater in full duplex mode.
Since we are using a star topology, now we can connect more than one radio to the same server room and be able to support IP-only clients as well that would also be heard over the radio. But this is out of scope here, since I wanted a remote controlled SDR transceiver only at this stage.
QRadioLink runs (or is a wrapper of) GNU Radio flowgraphs to be able to transmit and receive FM (and other modes, like SSB or FreeDV). While GNU Radio is very flexible and powerful and you can do almost anything radio-wise that you can think of, it also has a few issues: a very large number of dependencies, some of which are not packaged properly by some Linux distributions, and quite complex to install from source with everything required to set up QRadioLink. For this reason, I gave up on using anything other than Debian 10 at the moment. This is what ran on the Raspberry Pi module as well.
Some technical information about the whole audio stream flow from and towards the radio. To receive the FM tranmissions, a GNU Radio flowgraph does the demodulation and filtering of the signal. Two bandwidths are available for FM mode, for the two channelization standards of 12.5 kHz and 6.25 kHz. Squelch level can be adjusted at any time, and CTCSS tones are transmitted for some of the repeaters which require it. The CTCSS tone squelch on the receiver side has a couple of issues though, it is not always very reliable with some delay in opening present, so I generally used only transmit CTCSS. The FM signal comes out of GNU radio as 32 bit floating point values which are coverted to 16 bit integer audio samples (PCM), at a sample rate of 8000 samples per second. Using a higher sample rate is not really necessary for voice communications. Tnen, the samples are accumulated into a 120 millisecond audio frame which is passed to the Opus encoder whose bitrate is fixed to the value set in the config (Opus also supports variable bit rate). Experimentally I found out that larger audio frame sizes around 120 ms work better when there is a lot of network latency (like LTE connections sometimes have). The Opus packets are then encapsulated into the Mumble network protocol and sent to the VOIP server to be distributed to clients.
The transmit flow is similar. Opus packets encapsulated in the Mumble protocol are sent by the clients to the server and received by QRadioLink which decodes the Opus packets to PCM audio samples. The other clients (whether desktop or mobile) can use variable bitrate, but the Opus library will handle the decoding automatically regardless of the actual bitrate of the input. PCM samples are then passed on to GNU radio which handles FM modulation and CTCSS tones. If two clients speak simultaneously in the server channel, audio packets cannot be just sent sequentially to the FM modulator, since that would cause unintelligible audio. The audio mixer in QRadioLink will mix the two or more audio streams into one, reducing the audio volume to each stream in the process, to avoid clipping and distortion due to over-modulation.
Over the course of several months I tested both monitoring and remotely accessing amateur repeaters via my mobile phone. Since I'm mostly using LTE and rarely Wifi, there is some significant delay here due to my voice being carried over two radio connections (LTE -- Internet towards SDR and from SDR to repeater via FM radio). Sometimes this delay was further increased by introducing a third radio connection, from my Bluetooth headset to my mobile phone. I managed to measure these delays, and got 750 milliseconds in the best case and more than 1.2 seconds in the worst case from phone PTT press to signal reaching another FM radio listening on the repeater. Also something to add is that GNU Radio buffers add some not quite insignificant delay, but it's manageable if no instant break-in is required.
Of course during these months I found a lot of bugs in the software, and with the help of great people like Catalin YO7GQZ, Petru YO3HPC, Cristi YO3GWM and Bogdan YO3IXW I managed to get something working to my satisfaction. I am in debt to them for their patience while I was doing tests on the air, and for their radio controls which helped me tune the GNU Radio code and eliminate some bugs. Some things don't work yet like I want them, like selecting memory channels remotely, but I could work around them by giving commands to set the frequency and repeater offset instead. Most importantly, I now have a remote transceiver that I can use, tune and configure from my mobile phone, and this is the first step towards fully field-programmable amateur repeaters.
As an amusing side comment, one of our repeaters is connected to a nation-wide FM repeater network with more than 100 nodes which all transmit the same audio. I used this remote setup to access it lots of times, and the full path that the audio signal takes involves no less than 5 radio connections all on different radio network types sometimes: the audio is transferred from my headset to the phone via Bluetooth, then it uses the LTE (4G) radio network to reach Internet and the LimeNET-Micro at my home, from there the signal takes an FM path on 430 MHz to the repeater, from the repeater it hits Internet again via a WiFi connection and finally reaches somebody's portable Rolink node via LTE again. If you think about it, there's not only a lot of latency here but a lot of transcoding from one voice codec to another, and it still works well, with latencies from 1 to 1.5 seconds round-trip, all a testament of the resilience of modern radio network protocols.
The conclusions, if I'm allowed to draw any after more than half a year spent using this remote system, are: