QRadioLink is a Linux SDR transceiver application using VOIP built on top of GNU radio, made for hobbyists, tinkerers and radio enthusiasts, which allows experimenting with software defined radio hardware using different digital and analog modes and a friendly user interface.
Its primary purpose is educational, but it can also be customized for low power data communications on various frequency bands. Can also be used as an amateur radio SDR transceiver for teaching students about radio communications.
Possible applications:
Note: QRadioLink currently uses only the default Gnuradio blocks, but that could change in the future.
Why does QRadioLink use a fixed sample rate?
QRadioLink is meant to be a simple two way SDR communication tool for experimenting. The current operating modes are all narrow band
(they fit within 1 MHz) so a fixed sample rate that is compatible with listed devices and gives the best performance
was chosen. In the future, if wide band communication modes are implemented, a choice to pick between various sample
rates may be added. If you are looking for a more featureful dedicated receiver and spectrum analyser,
take a look at Gqrx.
I can see a signal at the extreme right of the spectrum display, but when I try to tune to it, it seems to
disappear
In order to be able to use the default GNU radio Qt widgets,a design choice was made to shift the signal of choice to
the center of the FFT/waterfall, but this has the side effect of also shifting a signal which would normally appear
at the extreme left to the right side. The solution is not very elegant and with some effort this could be fixed. The user
interface from Gqrx is better suited if you need to visually inspect a wide radio spectrum.
Why does the user interface appear different from the screenshots on my computer?
The screenshots are taken under KDE, a native Qt desktop environment. With GTK based desktops, the Qt theme can
behave differently. I have not mastered yet these subtle differences. Your help is welcome.
I am trying to use the official Mumble server package, but it does not seem to work with QRadioLink
The best response I can come up with is that the official Mumble protocol reference possibly ommits some steps required
to connect to the latest version of the official server. My Mumble client is written according to this document, but
it uses the umurmur server package for this reason. Your help in resolving this issue is also welcome.
Why is there no Android APK for QRadioLink?
Because QRadioLink is not a native Android application and needs a GNU/Linux Android container and userspace. For this reason
the user interface is rather clunky for a mobile device and needs a rewrite. You can expect that to happen once KDE Plasma
mobile becomes stable. While the application is not native, the performance is similar to a native application, but
there is some overhead from the visualisation layers, especially if you use a VNC display instead of an X server.
For most modes, expect at least 50% CPU usage on 3-4 cores running at 1.2 GHz.
I see a performance drop when switching to the spectrum display tab
The FFT and waterfall widgets are not active when you don't have the tab open. No FFT is performed on the data by GNU radio and
no UI painting is happening. When you switch to the spectrum display tab, that code becomes active and the application
takes a small performance hit. You can try to run volk_profile before running the application and see
whether it helps, but it's not required.
I have issues forwarding the VoIP digital audio to the radio and viceversa
There are two specific scenarios: if the SDR is connected to a Mumble server and more than one VoIP client speaks
at the same time, the code will not handle that correctly and you may hear garbled audio over radio. This will be fixed in a future release.
If your SDR receives an FM or other analog signal there is no transcoding involved and the voice packets encoded with Opus are sent
directly to connected clients. If your SDR receives a digital voice signal like Codec2, the audio is transcoded first
before being sent to the VoIP network. Audio artefacts and delays may be present in this case.
I want to configure a radio base station / repeater with VoIP linking, but I can only choose analog or digital, but not both
at the same time
This part of the software is not ready yet and it would be useless to include it in public releases.
Indeed, the main goal is for a base station to be able to serve both analog and digital channels at the same time, provide a broadcast
channel with VoIP room and client information and the ability of the remote radio to choose which VoIP room is
linked to a specific physical channel. Unfortunately that is no small amount of work, and while VoIP channel list broadcast is
partly implemented, the rest of the code is not. In any case, a SDR base station servicing up to 6 physical channels
either digital or analog will require more CPU power than a simple QRadioLink client, so expect a Raspberry Pi to be a stretch
for this purpose.
Can QRadioLink be used headless on the Raspberry Pi?
It's not possible yet, but it's on the TODO list, especially for the repeater and base station modes.
Can I encrypt / obfuscate the radio signal to avoid eavesdropping?
QRadioLink does not encrypt the radio signal, because it's mostly aimed at hobbyist users and amateur radio where encryption of radio signals
is generally prohibited. If you need to securely transfer sensitive data over the radio, you should probably use something else.
However, audio transiting the VoIP network is encrypted using TLS.
You should take care that uMurmur SSL certificates are properly generated and stored if you need to transit an insecure network.
QRadioLink