Configuration and running
Notice for GNU radio 3.8 users
Due to an issue present in GNU radio 3.8, it is necessary to perform a workaround step to re-enable digital modes. You need to run the volk_profile
command, and after it completes, inspect the file ~/.volk/volk_config
in the /home directory. Locate the line starting with volk_8u_x4_conv_k7_r2_8u
and ensure it ends with spiral spiral
: volk_8u_x4_conv_k7_r2_8u spiral spiral
. If it does not not, change it so it looks like this. After performing this step, digital modes should work again.
MMDVM and SVXlink operation modes
Please see the following README files in the docs directory for instructions:
- It is recommended to start the application using the command line when running the first few times and look for any error messages output to the console. Some of them can be ignored safely, others are critical. Logging to console is by default enabled.
- It is not recommended to run qradiolink as root
- When first run, go to the Setup tab first and configure the device options, then click Save before starting TX or RX. Without the correct device arguments or the correct antenna selected, the application can crash when enabling RX or TX. This is not something that the application can control and keep functioning properly.
- LimeSDR-mini and LimeNET-Micro devices require a device string like soapy=0,driver=lime. If you are using more than one device, use the SoapySDRUtil --find command and add the serial number of the device to the device arguments string, like soapy=0,serial=583A29CED231, driver=lime. You can use Auto for the antenna string for both Lime devices and the RF path will be automatically selected
- ADALM-Pluto requires a device argument like soapy=0,driver=plutosdr
- GNU radio main DSP blocks are highly optimized (including on embedded ARM platforms) by using the VOLK library. To minimize the CPU resources consumed by QRadioLink it is recommended to run the volk_profile utility after GNU radio has been installed. This command only needs to be run when GNU radio or libvolk are upgraded.
- High sample rates, high FPS rates and high FFT sizes all affect the CPU performance adversely. On embedded platforms with low resources, you can disable the spectrum display completely using the FFT checkbox. The FPS value also sets the rate at which the S-meter and constellation display are updated, so reduce it to minimum usable values. If the controls menu is not visible, the S-meter display will not consume CPU resources. Similar for the Constellation display.
- Pulseaudio can be configured for low latency audio by changing settings in /etc/pulse. If you experience interruptions or audio glitches with Pulseaudio, you can try the following workaround: add tsched=0 to this line in /etc/pulse/default.pa and restart Pulseaudio
load-module module-udev-detect tsched=0
Alsa may require you to place an .asoundrc file in the home directory with contents similar to this:
- New: You may now transmit at all supported sample rates, not just 1 Msps. This feature is still undergoing testing. Transmitting at higher sample rates will use more CPU cycles and be less efficient.
- Filter widths for reception and transmission of the analog modes (FM, SSB, AM) are configurable. To increase or decrease them, drag the margins of the filter box on the spectrum display. For SSB upper sideband, only the upper filter limit can be configured. For SSB lower sideband, only the lower filter limit is configurable.
- You can change the FFT reference display level by hovering with the mouse on the left sidebar where the dB numbers are displayed and dragging this bar up and down. You can also zoom on this axis by hovering with the mouse and using the scroll whell. The levels will be saved in the settings and will remain the same at the next restart. You can also drag the frequency bar below the FFT display to the left and right, and you can zoom in and out with the mouse wheel on both of the number bars. Right clicking the frequency bar resets the frequency zoom to the normal default value.
- The FFT history setting allows the display of the two previous FFT bins in addition to the current one, which may be useful for the display of short bursts transmissions.
- VOIP uses umurmur as a server. A version known to work with qradiolink is mirrored at qradiolink.
You can use QRadioLink as a pure VOIP client without using the radio by selecting Use PTT for VOIP. For radio over IP operation, you need to toggle Forward radio to send the digital or analog radio voice to the VOIP server and viceversa. Any voice packets coming from the server will be transmitted directly after transcoding in this case. Full duplex audio from more than one VOIP client at the same time can now be transmitted. The Mumble application is now also compatible with QRadioLink. It is recommended to enable Push To Talk in Mumble and maximize the network robustness and latency settings. Text messages from Mumble are displayed inside the application, but no action is taken for channel-wide messages. Text messages can also be sent to the current Mumble channel. If remote control is enabled, private Mumble text messages will control the radio.
The Mumble VOIP connection uses the Opus codec at a higher bitrate, so ensure the server can handle bitrates up to 50 kbit/s per client. The VOIP bitrate can be configured in the Setup page. On Android phones, the Plumble application can be used as a client, however you may experience interruptions of audio due to a lack of jitter buffer control and network latency.
- The VOIP username will be your callsign as set in the General Settings page
- Remote control via Mumble private text messages requires enabling remote control in settings, and using the Mumble client (either desktop or Android) to send text messages to the QRadioLink username. Text messages sent to the channel will be ignored by the application. Authentication of user who is sending the commands is not yet implemented.
- To display the application in fullscreen mode, use the system shortcut for fullscreen (F11 and Ctrl+Shift+F in KDE, Ctrl+F11 in Gnome)
- - Running headless (no graphical user interface) for usage on embedded platforms like the Raspberry Pi or similar boards requires starting QRadioLink from the command line with the --headless option; example:
$ qradiolink --headless >> $HOME/.config/qradiolink/qradiolink.log 2>&1
When running in headless mode, console log will be disabled by default with the above command. Init scripts for SysV / Systemd will be provided at some point to be able to run QRadioLink as a system service. When running headless from CLI, the network command server is started by default listening on the port configured in the settings file (or 4939 if not configured). Headless and remote operation will usually require you to enable VOIP forwarding either in the configuration file or via a command, unless you want to use audio from the machine where QRadioLink is running. CPU consumption can reach 50% at 800 MHz CPU clock for a headless QRadioLink instance connected to the VOIP network and operating as a duplex repeater (depending on mode used)
- The configuration file is located in $HOME/.config/qradiolink/qradiolink.cfg
- The memory channels storage file is located in $HOME/.config/qradiolink/qradiolink_mem.cfg
- Log messages are stored in $HOME/.config/qradiolink/qradiolink.log (this location will likely change in the future)
- After adding a memory channel, you can edit its values by double clicking on a table cell. This may cause the radio to switch to that channel. The settings are not updated instantly, so if you make a change, after you press Enter, switch to another channel and back to get the updates. A button allows you to save channels before the window is closed. Saving sorted channels is not possible yet. Otherwise, the channels, like the settings, will be stored on exit (if no application crash meanwhile).
- Before any upgrade, please make a backup of the $HOME/.config/qradiolink/ directory in case something goes wrong, to avoid losing settings and channels.
- Digital gain can be safely ignored on most devices. It was added as a workaround for the PlutoSDR and is no longer required. Leave it at 5 (mid-scale) unless you know better.
- In full duplex operation you need to have sufficient isolation between the TX antenna port and the RX antenna port to avoid overloading your input or destroying the LNA stage.
- In half duplex mode the receiver is muted during transmit and the RX gain is minimized. Do not rely on this feature if using a power amplifier, please use a RF switch (antenna switch) with enough isolation, or introduce attenuators in the relay sequence to avoid destroying the receiver LNA.
- The transmitter of the device is active at all times if enabled, even when no samples are being output. Although there is no signal being generated, local oscillator leakage may be present and show up on the spectrum display. This is not a problem usually, unless if you keep a power amplifier connected and enabled at all times. You can use the USB relays to disable it in this case when not transmitting.
- FreeDV modes and PSK modes are very sensitive to amplifier non-linearity. You should not try to use them within a non-linear envelope to avoid signal distortion, splatter or unwanted spectrum components. Digital gain for these modes has been set in such a way to avoid non-linear zone for most devices output stages. If this is not satisfactory, you can use the digital gain setting to increase the digital gain.
- Receive and transmit gains currently operate as described in the gr-osmosdr manual. At lowest settings, the programmable gain attenuator will be set, following with any IF stages if present and finally any LNA stages if present. This behaviour is desirable since there is no point setting the LNA to a higher value than the PGA if the signal power is already above the P1dB point of the LNA stage. Controls for adjusting individual gain stages can also be found on the controls menu. The name of the gain stage will appear as a tooltip.
Transmit shift can be positive or negative. After changing the value, you need to press Enter to put it into effect. Setting the TX shift is not possible while transmitting a signal. Although the shift is stored as Hertz and you can edit this value in the config, the UI will only allow a value in kHz to be entered (e.g. -7600 kHz standard EU UHF repeater shift).
- USB relays using FTDI (FT232) chipsets are used to control RF switches, power amplifiers and filter boards. To determine if your USB relay board is supported, look for a similar line in the output of lsusb:
Bus 002 Device 003: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC
Do note that the identifier digits are the most important: 0403:6001. At the moment, such USB relays can be sourced on Amazon and Ebay and can be identified by the light silver-blue colour of the board.
- QRadioLink can control a maximum of 8 relays, however only 2 are used at the moment. This is work in progress. Other types of relays may be supported in the future.
The order in which relays are activated and deactivated during a transmission cycle is as follows: activation starting with relay 1 to relay 8, deactivation in reverse order (relay 8 to relay 1). A Python script ( ext/ftdi.py ) is included to help you determine the order of relays on the board.
- The LimeRFE frontend device is supported in simplex and full duplex mode. Control of the LimeRFE is only via the USB connection. The default device is /dev/ttyUSB0, however you can change this device in the Setup -> General Settings page in case your device is asigned a different tty when plugging it in. Automatic tuning based on SDR frequency is available, however only amateur bands in IARU region 1 are currently supported. Be careful not to enable duplex mode in QRadioLink if port labeled TX is not terminated on a 50 Ohm load or connected to an antenna. For simplex operation use only the ports labeled "Tx/Rx" and "70 MHz". Do not exceed a transmit gain setting of 80 for the 2300 - 2450 MHz band to avoid amplifier damage. For SDR frequencies outside of IARU region 1 amateur radio bands, the WIDEBAND_1000 and WIDEBAND_4000 RF paths are used for both transmit and receive.
- Video will be displayed in the upper right corner. Currently the system default camera is used for capturing the images.
- New: starting with version 0.8.5-rc4, the video transmission also has sound, using the Opus audio codec.
- IP over radio operation mode requires net administration priviledges to be granted to the application. See the instructions in the docs/ directory. An error message will be output at startup if these priviledges are not present. You can safely ignore this message if you don't need to use the IP modem facility.
- VOX mode requires careful setup of system microphone gain to avoid getting stuck on transmit. The VOX activation level can be configured in the Setup page.
- Repeater mode requires the radio to operate in Duplex mode. Prior to enabling repeater mode, make sure to configure the TX shift (positive or negative). Mixed mode repeat is possible, so you can operate the receiver on a different mode to the transmitter (FM to Codec2/Opus/FreeDV or viceversa). If radio forwarding is enabled, audio from the repeater will be broadcast to the VOIP network as well (useful for remote repeater linking via TCP/IP). The repeater can now handle mixing of audio incoming from the VOIP network and coming from the radio receiver so it is possible for two or more users on different connected repeaters to speak simultaneously (full duplex repeater).
- When operating a repeater linked to the VOIP network, you may experience small delays of voice due to transcoding operations, especially for mixed mode repeaters.
- Setting application internal microphone gain above the middle of the scale might cause clipping and distortion of audio, as the system volume also affects what goes to the radio.
- The VOIP volume slider controls the volume of the audio sent to the Mumble server.
- It is now possible to mute self or deafen self from the UI without disconnecting from the VOIP server.
- Audio recordings are saved in the directory specified in the settings. Audio is recorded in FLAC (free lossless audio compression) format, with audio data only being written to file when there is something being played back on the audio interface. That means that recording while there is silence will not generate file data. The file name corresponds to the time when the recording was started.
- The S-meter calibration feature is not complete yet, however you can enter in the Setup tab the level (integer value expressed in dBm) of a known signal (e.g. sent by a generator) to correct the reading. Do NOT apply signals with levels above -30 to 0 dBm to the receiver input as this might damage your receiver, depending on hardware. Please note that the RSSI and S-meter values displayed are relative to the current operating mode filter bandwidth, so the FM reading will be different to a SSB reading! Calibration tables support for different bands may be provided in the future.
- The network remote control feature (for headless mode) is work in progress. The network server will listen on the localhost IPv4 network interface and the default control port is 4939. There is no provision for authentication of the user, so use SSH to log in to the remote system and use telnet from there to localhost port 4939. To use the network remote control feature, you can simply use the telnet program or you can create simple Python or shell scripts to automate the commands. The help command will list all the available commands as well as parameters:
$ telnet localhost 4939
Connected to localhost.
Escape character is '^]'.
Welcome! Available commands are:
rxstatus (0 parameters): Status of receiver (started or not)
txstatus (0 parameters): Status of transmitter (started or not)
txactive (0 parameters): See if the radio is on the air
rxmode (0 parameters): Get RX operating mode
txmode (0 parameters): Get TX operating mode
rxctcss (0 parameters): Get RX CTCSS
txctcss (0 parameters): Get TX CTCSS
rxvolume (0 parameters): Get RX volume value
txvolume (0 parameters): Get TX volume value
squelch (0 parameters): Get squelch value
rxgain (0 parameters): Get RX gain value
txgain (0 parameters): Get TX gain value
rssi (0 parameters): Get current RSSI value
voipstatus (0 parameters): Get VOIP status
forwardingstatus (0 parameters): Get radio forwarding status
voxstatus (0 parameters): Get VOX status
repeaterstatus (0 parameters): Get repeater status
duplexstatus (0 parameters): Get duplex status
setrx (1 parameters): Start/stop receiver, 1 enabled, 0 disabled
settx (1 parameters): Start/stop transmitter, 1 enabled, 0 disabled
setrxmode (1 parameters): Set RX mode (integer number, 0-16)
settxmode (1 parameters): Set TX mode (integer number, 0-16)
setrxctcss (1 parameters): Set RX CTCSS (floating point number, 0.0 to 200.0)
settxctcss (1 parameters): Set TX CTCSS (floating point number, 0.0 to 200.0)
setsquelch (1 parameters): Set squelch (integer number, -150 to 10)
setrxvolume (1 parameters): Set RX volume (integer number, 0 to 100)
settxvolume (1 parameters): Set TX volume (integer number, 0 to 100)
setrxgain (1 parameters): Set RX gain (integer number, 0 to 99)
settxgain (1 parameters): Set TX gain (integer number, 0 to 99)
tunerx (1 parameters): Tune RX frequency, integer value in Hertz
tunetx (1 parameters): Tune TX frequency, integer value in Hertz
setoffset (1 parameters): Set demodulator offset, integer value in Hertz
setshift (1 parameters): Set TX shift, integer value in Hertz
setduplex (1 parameters): Set duplex mode, 1 enabled, 0 disabled
setforwarding (1 parameters): Set radio forwarding mode, 1 enabled, 0 disabled
setrepeater (1 parameters): Set repeater mode, 1 enabled, 0 disabled
setvox (1 parameters): Set vox mode, 1 enabled, 0 disabled
setpttvoip (1 parameters): Use PTT for VOIP, 1 enabled, 0 disabled
setcompressor (1 parameters): Enable audio compressor, 1 enabled, 0 disabled
setrelays (1 parameters): Enable relay control, 1 enabled, 0 disabled
setrssicalibration (1 parameters): Set RSSI calibration, integer value in dBm
setrxsamprate (1 parameters): Set RX sample rate, integer value in Msps
autosquelch (0 parameters): Set autosquelch
setfilterwidth (1 parameters): Set filter width (analog only), integer value in Hz
ptt_on (0 parameters): Transmit
ptt_off (0 parameters): Stop transmitting
connectserver (2 parameters): Connect to Mumble server, string value hostname, integer value port
disconnectserver (0 parameters): Disconnect from Mumble server
changechannel (1 parameters): Change channel to channel number (integer value)
mumblemsg (1 parameters): Send Mumble message, string value text
mutemumble (1 parameters): Mute Mumble connection, 1 enabled, 0 disabled
start_trx (0 parameters): Convenience function, requires everything to be preconfigured
stop_trx (0 parameters): Convenience function, requires everything to be preconfigured
RX status is inactive.
qradiolink> setrx 1
Turning on receiver
RX status is active.
Connection closed by foreign host.
Please report any issues you have encountered using the bug tracker
The project has an email list at https://groups.io/g/qradiolink
which can be used to discuss operation, features and other topics related to software defined radio and amateur radio in an open source software context.
Is the packet radio system within QRadioLink compatible with other existing amateur packet radio modes and / or FM radios?
No, the packet radio modem is not compatible with FM radios and 1200 / 9600 baud amateur radio packet.
The receiver needs to be able to demodulate in a bandwidth of at least 1 MHz to receive this radio packet mode.
Furthermore, the Internet packet modes in QRadioLink do not even use the same data link layer. Instead of AX.25 frames, QRadioLink sends Ethernet frames over the air.
This means that you do not need AX.25 Linux kernel support to create an IP link with QRadioLink. Also, both the 4FSK and DQPSK packet radio modes require a full duplex transceiver, or at least two devices (a semi-duplex transceiver and an RTL-SDR receiver for example).
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 am running QRadioLink on a very limited CPU power platform, what can I do?
The FFT and waterfall widgets are not active if you disable the FFT checkbox. No FFT is performed on the data by GNU radio and
no UI painting is happening. When you switch FFT on, that code becomes active and the application
takes a performance hit which is proportional to the sample rate, FFT size and the FPS. Reduce them to the minimum for lowest CPU demand. You should run volk_profile before running the application for optimization.
I have issues forwarding the VoIP digital audio to the radio and viceversa
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.
Can QRadioLink be used headless (with no graphical user interface on the Raspberry Pi?
Yes, starting with version 0.8.2, QRadioLink can be used as a terminal application (possibly daemonized) without X11 or any screens.
Remote operation in this case is possible either via commands sent through Mumble as private messages, or via the embedded telnet server, for which you will need
a telnet client or similar application to connect with. No authentication or security features are implemented at the moment, so you should not expose the configured
remote port to the Internet and instead use SSH to connect to the system and telnet from there. If you are not using local audio, you will need to also enable VOIP forwarding.
Is there a Windows version?
No. QRadioLink only works on Linux systems at the moment. However, it is not impossible to port to the Windows operating system if someone is interested to do the work, with only a few parts that are very Linux specific (including some calls into Linux kernel API). However, Windows users should keep in mind that QRadioLink is a very simple educational tool for hobbyist and learning users and cannot achieve or even wants to achieve what professional SDR applications can perform on Windows. To avoid disappointment, I am recommending some professional products with first grade suppport for the Windows OS: FlexRadio SmartSDR and SDRConsole.