Important remark for all users only reading headlines:
(for whatever reason, other readers please skip)If you intend to use the ADS-B decoder to show airplanes on the map, you MUST select a sampling rate of 2000000 in the Settings of that receiver, otherwise the ADS-B will not work! The ADS-B will currently NOT work with the Airspy R2.
Introduction
Each of the QIRX receivers ("Frontends") processes data arriving on the TCP/IP network. If you want to understand and
use the various Setup scenarios of QIRX
you need at least a very basic knowledge how TCP/IP works. . In the following I assume you understand the term "TCP/IP socket", "Dotted IP Address" and "Port Number". This is
the whole vocabulary you need to know. As TCP/IP is at the heart of the Internet, understanding these terms will help you also
in a better understanding of the Internet.
Remark: Working with TCP/IP does NOT mean that you need to connect to other computers. Each computer has its "built-in" TCP/IP network called the "localhost". QIRX is perfectly able to work with the localhost only, although a "real" network is advantageous in many cases.
Remark: Working with TCP/IP does NOT mean that you need to connect to other computers. Each computer has its "built-in" TCP/IP network called the "localhost". QIRX is perfectly able to work with the localhost only, although a "real" network is advantageous in many cases.
Drivers, or I/Q Data Servers
Receiver hardware like rtl-sdr dongles are usually connected to a USB port of the computer. Therefore QIRX uses a "driver program" for each
hardware it supports, to convert the I/Q data arriving at the USB port into the TCP/IP format and send it to QIRX.
All driver programs with their additionally needed DLLs are provided by the installer.
This looks at first glance like a complication, but at second glance opens a flexibility not possible with USB connections.
QIRX supports the following hardware, with the corresponding driver software:
This looks at first glance like a complication, but at second glance opens a flexibility not possible with USB connections.
QIRX supports the following hardware, with the corresponding driver software:
- rtl-sdr Dongles: Driven by rtl_tcp.exe. There are rtl-sdr dongles with different tuners, like the R820T, the E4000 or the FC0012 and more. All of them are driven by rtl_tcp.exe. A prerequisite is that the so-called Zadig driver has been installed, which is not distributed and installed by QIRX, but can be found on many places in the web.
- sdrplay Devices: Driven by RSP2_tcp.exe. T he supported hardware are RSP1A, RSP2, RSPduo (currently its single tuner mode only).
- Airspy Devices: Driven by airspy_tcp.exe. The supported hardware are Airspy Mini, Airspy R2. Please note that the Airspy R2 currently does not work with the ADS-B decoder.
Setup Dialog
The picture shows the QIRX Setup entries as pre-configured when first run. The dialog opens on clicking the gearwheel icon on the topmost bar.
The following describes the different fields of the Setup dialog.
Each row corresponds to the settings of the receiver with the number in the leftmost column.
Remark: The dialog can be opened only if all receivers are off. This might change in a future version.
The following describes the different fields of the Setup dialog.
Each row corresponds to the settings of the receiver with the number in the leftmost column.
Remark: The dialog can be opened only if all receivers are off. This might change in a future version.
- Column "Hardware": Selects the hardware to be used for the receiver. Possible entries are RTL-SDR, RSPx, Airspy.
-
Column "Activate": If checked, the receiver is visible and runnable. If unchecked, it is invisible and cannot be used.
This is useful e.g. for users not interested in multi-Rx operation. For instance, with the DAB demodulator the software behaves like Version 2.
For this entry to become effective, QIRX must be restarted. -
Column "Sampling Rate": Important for the demodulator to be used. Possible entries are:
-
2000000: Necessary for ADS-B. Due to QIRX internal working it should not be used for one of the other demodulators.
ADS-B will not work with one of the other sampling rates. - 2048000: To be used for DAB, AM, WFM, NFM, SSB. Not for ADS-B.
- 3000000: Airspy only. It has been introduced to replay raw files recorded with other programs using the Airspy hardware with that sampling rate during the recording (e.g. qt-dab).
- 4096000: Possible together with a RSPx or the Airspy hardware. Cannot be used with RTL-SDR hardware.
- 8192000: Possible together with a RSPx hardware only.
-
2000000: Necessary for ADS-B. Due to QIRX internal working it should not be used for one of the other demodulators.
-
Column "Bit Width": Possible entries are 8 or 16 Bits. Only for the RSPx and the Airspy hardware.
Remark: The TCP/IP data rate doubles with 16 Bit compared to 8 Bit.
Remark: Although the Airspy and the RSPx hardware delivers 16 Bit data from the USB, the QIRX drivers (see above) are able to convert to 8 Bit, thus halving the TCP/IP bandwidth. -
Column "Autostart": If checked, the QIRX I/Q data server program is started automatically.
If unchecked, it is assumed to be already running with the correct parameters.
Please note: "Autostart" does NOT mean that the receiver is started automatically after having started QIRX. For live reception the blue triangle at the top of each receiver must always be clicked on. - Column "Autostop": If checked, the QIRX driver program is stopped automatically when the receiver is stopped. If unchecked, it continues to run and will accept new connections.
-
Column "IP Address": Pre-configured to the localhost (see picture above). Other local addresses can be used also. For remote scenarios, see below.
Remark: The IP Address must be entered as "dotted address". QIRX does not resolve host address names. This might change in a future version. - Column "Port": When using the same IP Address, different receivers MUST use different port numbers. When using RTL-SDR hardware, the port numbers MUST differ by at least two, because rtl_tcp.exe uses two sockets, one for the I/Q data, and another one for commands and responses.
-
Column "Device Index": Identifies the USB index. It must be up-counted when using more
than one hardware on a computer with the same QIRX driver, like the scenario described in the Install.
The main hardware affected are the RTL-SDR dongles, where sometimes even the use of a single dongle requires a Device Index of 1 instead of 0. This remains kind of a mystery.
With more than one RSPx devices, the count must start at 0 and be increased with other devices used on the same computer.
No tests were made with more than one Airspy regarding the Device Index.
Remark: In any case, using the same Device Index with the same QIRX driver for two different receivers (same computer) will NOT work. - Column "Remote Starter Port": Described in the following section.
Remote Scenarios
In a "Remote Scenario" the receiving hardware is connected to another computer than the one running QIRX. This might be
advantageous for a number or reasons. This remote computer does not run the QIRX software, but one or more instances of the QIRX drivers like rtl_tcp (see above).
Whereas QIRX is confined to run on a Windows machine, the drivers are not. Currently the rtl_tcp.exe program is available on
Linux, and the RSP2_tcp.exe is
also runnable on Linux, although no build exists yet (this will change in the near future).
As a result, people are running e.g. the rtl_tcp on Raspi embedded devices, perfectly suitable for the purpose.
Some examples where such a remote scenario might be useful:
As a result, people are running e.g. the rtl_tcp on Raspi embedded devices, perfectly suitable for the purpose.
Some examples where such a remote scenario might be useful:
- Short Antenna Cable: It is always advantageous to have the cabling from the antenna to the receiver as short as possible, despite the fact that the drivers all support a Bias-T supply to drive e.g. a mast amplifier. The cheap rtl-sdr dongles do not provide this facility though.
- Antenna Location: Using an antenna together with the receiver hardware near the SDR program like QIRX will in most cases be a compromise. Having the possibility to put an antenna on the roof pairs nicely with using a remote I/Q data driver.
- Noise Pollution: Today's working places with all of this home office stuff and large multiple computer screens have a notoriously bad reputation with respect to pollution of the environment with RF noise. Using an embedded device tailord for low noise generation will definitely gain you some decibels in sensitivity.
-
USB Problems: The rtl_tcp.exe driver has been shown to be sensitive to occasionally loosing samples on the way
from the hardware across the USB interface. The reason is unclear, as e.g. the RSPx drivers do not show this deficiency.
Tests with this driver running on a remote computer (Windows or Linux) drastically improve the situation. This is particularly important for coherent applications like DAB.
-
Rx 1: Driver for RTL-SDR runs on the localhost. Nothing special here.
-
Rx 2: Driver for RTL-SDR runs on a remote computer. Autostart is selected. Remote Starter Port is 12345 (see below).
-
Rx 3: Driver for RSPx runs on the same remote computer. Obviously intended for ADS-B, as the sampling rate is 2000000. Autostart is selected. Remote Starter Port is 12345 (see below).
- Both drivers - for Rx2 and Rx3 - are to be run on the same remote computer, as the same IP Address has been entered for both. As a result - even for two different drivers - two different port numbers are mandatory, due to the TCP/IP restriction that no two "Server Sockets" (as the QIRX drivers are using) on the same machine can be equal, meaning that with equal IP Addresses the port numbers must be different.
- The drivers for Rx1 and Rx2 are equal. They can nevertheless use the same port number and Device Index, because running on different machines.
- Both drivers on the remote machine have their "Autostart" checked, with the "Remote Starter Port" of 12345. What does this mean?
Starting Remote
"Autostart" means that QIRX should start the corresponding driver program automatically, also in a remote scenario. However, in Windows it is not possible
for a program to start another program on a remote machine in the network. It needs some remotely existing communication partner which can be informed
to start the requested program.
In QIRX, this partner program is called "StubForRemoteStart". It must be started once, and can be accessed at any time by QIRX (on another computer) and informed to start the requested driver. The communication between QIRX and the "Stub" takes place also via TCP/IP, same remote IP address, but of course another port number as mandated by TCP/IP, the "Remote Starter Port".
The picture visualizes the situation:
QIRX, when starting receivers from its own "local" site, starts the local I/Q data server ("driver") by just starting their exe with the parameters as entered in the Setup. In our example this is Rx1. On Rx2 and Rx3 however it connects to the "StubForRemoteStart" and sends it the complete pre-prepared strings to start the respective drivers.
After this step there is no difference any more to the local case. QIRX connects to the TCP/IP sockets remotely in exactly the same way as it does locally.
One detail remains though: The "StubForRemoteStart" must be started once, either manually or in some way automated e.g. during Startup of Windows. Of course its TCP/IP socket must know the port number where to listen. This can be set as a parameter on the command line. If omitted, 12345 is used.
In QIRX, this partner program is called "StubForRemoteStart". It must be started once, and can be accessed at any time by QIRX (on another computer) and informed to start the requested driver. The communication between QIRX and the "Stub" takes place also via TCP/IP, same remote IP address, but of course another port number as mandated by TCP/IP, the "Remote Starter Port".
The picture visualizes the situation:
QIRX, when starting receivers from its own "local" site, starts the local I/Q data server ("driver") by just starting their exe with the parameters as entered in the Setup. In our example this is Rx1. On Rx2 and Rx3 however it connects to the "StubForRemoteStart" and sends it the complete pre-prepared strings to start the respective drivers.
After this step there is no difference any more to the local case. QIRX connects to the TCP/IP sockets remotely in exactly the same way as it does locally.
One detail remains though: The "StubForRemoteStart" must be started once, either manually or in some way automated e.g. during Startup of Windows. Of course its TCP/IP socket must know the port number where to listen. This can be set as a parameter on the command line. If omitted, 12345 is used.
Starting Remote, Special Case
Sometimes people want to have more control over their I/Q data servers. They want to start the remote drivers manually. To achieve this, it is just
necessary to enter the value of zero into the "Remote Starter Port" field. In that case the complete remote starting process is bypassed, and of course care must be taken
to manually provide the remote QIRX drivers with the correct parameters. The setup looks like this:
And the picture visualizes this situation:
No "StubForRemoteStart" any more, on the remote site the start of the drivers has to be done manually. The same result can be achieved by un-checking the "Autostart" field, but in this case some - perhaps annoying - messages appear that everything has to be done manually. These are suppressed when entering a 0 in the "Remote Starter Port" field.
Credit: This feature has been suggested by rundfunkforum user zwhd.
And the picture visualizes this situation:
No "StubForRemoteStart" any more, on the remote site the start of the drivers has to be done manually. The same result can be achieved by un-checking the "Autostart" field, but in this case some - perhaps annoying - messages appear that everything has to be done manually. These are suppressed when entering a 0 in the "Remote Starter Port" field.
Credit: This feature has been suggested by rundfunkforum user zwhd.