Qt-DAB-3.4.1 is the most recent version of the Qt-DAB program. Qt-DAB-3.4.1, developed under Linux, runs under Linux, (on PC and RPI) is cross-compiled for use under Windows (and was ported to IOS).
The Qt-DAB program has an extensive GUI with a variety of widgets and a pretty large number of controls, as can be seen on the picture. The idea is that the user is in control and can select (virtually) anything.
Next to Qt-DAB I used dabradio a lot, especially when I just wanted to listen to a service, and did not need all the controls provided by Qt-DAB. However, not all updates and corrections made to the Qt-DAB sources were also made to the dabradio sources (well there were many), and maintaining consistency between different sourcetrees remained difficult. Therefore I implemented, using the Qt-DAB sources, a new version with a minimal GUI, dabMini. This dabMini version has its own directory within the Qt-DAB sourcetree with in it the dabMini specific sources.
As can be seen, dabMini has a minimal GUI, just channel and service selection, with a selector for the presets, a selector for the audio channel, and a few support buttons for easy scanning through channels and services.
The GUI for dabMini does not show a device selector, the program will - when started - look for one of the configured devices being connected.
A third implemention using the Qt-DAB sources, also residing in the sourcetree of Qt-DAB, is dab-2. This is an experimental version, in that it uses a completely different implementation for DAB frame detection. That program also shares over 90 percent of the sources with Qt-DAB, it shares the GUI with Qt-DAB - apart from the widgets for the device control -, and it can be found in the subdirectory dab-2.
Devices that are currently supported in all three version of the dab decoder are:
the various RSP's from SDRPlay using a 2.13 library,
RT2832 based (so-called) DABsticks,
HACKrf device (currently only Linux),
limeSDR device (currently only Linux),
The Qt-DAB programs and the dab-2 program support further:
devices supported by Soapy, experimental, tested with SDRplay device,
through an IP port, using a client to an rtl_tcp server,
devices using the Extio interface in Windows (tested with the SDRplay and DABsticks, but not in the standard configuration).
Furthermore, the programs support reading files, 8 bit "iq" files, as generated by osmocom software, 16 bit ".sdr" files as generated by Qt-DAB and xml files.
Adding support for a device to Qt-DAB is not very complex, a well-defined interface exists. The user's guide contains a section describing in detail what functions must be implemented and what files need to be adapted.
It took a while, but I found time to write a pretty complete user's guide. That guide contains not only a detailed description of the widgets in the GUI, it contains a description of the possible (few) command line parameters and a description of the settings in the ".ini" file. It further contains a description of how configure and create an executable, how to add a device and a description of the mini version of Qt-DAB, i.e. dabMini.
Note that while there is no separate description for dab-2 - after all dab-2 might change daily - most of the settings for Qt-DAB also apply to dab-2.
A useful addition to the functionality of Qt-DAB and the other 2 dab decoders, was the addition of presets.
Presets make it easy to assemble a list with a few preferred services, regardless the channel on which they are transmitted. An entity of the preset list - encoded as channel:service - can be selected, just by clicking with the left mouse button on it.
Presets are saved between program invocations, documentation tells how to add and - also important - to remove elements from the list.
Especially when experimenting, there might be a need to replay transmissions, or to replay recording of the output of transmissions.
Qt-DAB and dab-2 provide a number of possibilities:
Each device handler has a dump button, controlling the dump of raw input of the device into an xml file.
The input data as being processed can be saved into a file in PCM format. The samples are translated into 16 bit integers, the samplerate is 2048000, two channels. Files get an extension of ".sdr" (this is the old format, might disappear at some point). In the dab-2 program the button is visible on the GUI, touching it will be without any effect though.
The AAC output for DAB+ services can be saved into a file. Such a file can be processed by e.g. VLC (note that the AAC format has used in DAB+ has frames of 960 elements rather than 1024).
The audio output can be saved into a file in PCM format with a samplerate of 48000, sample format is 16 bit integer, two channels.
The scan function of the Qt-DAB program scans all channels in the selected band, and shows the ensembles and services found. A scan gives in a few minutes a good overview of what can be received in the current band (usually Band III).
A recent addition is that at the end of a scan, the question is asked whether or not to save the result of the scan into an ASCII encoded file. The file is formatted such that it can made visible by e.g. LibreOfficeCalc.
To promote interoperability between QIRX and Qt-DAB (and possibly others), Clemens Schmidt (the author of QIRX) and I defined and implemented the xml file format.
An xml formatted file contains - next to the raw data - a precise description of that data. That way, raw data from a variety of devices can be used as input to the afore mentioned programs. The advantage is clear, the data recorded is the data as picked up by an input device, unaltered.
The description - written in XML, and contained in the first segment of the file - contains (a.o) the name of the device used and the number of bits per sample. A detailed description of the format can be found here
Currently, both QIRX and Qt-DAB provide a reader, able to handle xml files, furthermore, the various device handlers are equipped with a dump button to generate such a file.
Qt-DAB - the sourcetree and executables - is to be found in this repository on github.
For Linux (on an x64 PC) a precompiled version of Qt-DAB is available as an appImage. For Windows there are installers for all three members in the sourcetree, Qt-DAB, dabMini and sdrplayDab (see the releases page in that repository).
However for the RPI's or other targets, one has to start with the sources, install some libraries and build an executable.
The user's guide contains extensive instructions to create and executable, both for Qt-DAB and its little sister dabMini.
The sources for Qt-DAB-3.X are also used as basis for a number of derived programs, two of which will be briefly discussed here: a DABscanner and a DAB library a.k.a dab-cmdline.
For these (and a number of other) programs a repository exists on Github, most of them with an extensive README, containing a description and details for constructing an executable.
The DAB scanner is a program to continuously monitor (selected) channels in a given band and report on the received ensemble (if any). The program is developed for DX purposes, it is an ideal tool to monitor a band for a longer period.
The scanner can operate in two modes, continuous mode and controlled mode.
In continuous mode the duration of the scan is not specified, scanning continues until explicitly stopped. To allow focusing on selected channels, a skipfile can be selected, in which the channels that are to be part of the scan are marked as such. The contents of such a skipfile can be modified dynamically.
In this continuous mode, one selects a skipfile on program start up, if none exists, one will be created.
The output of the scanner is a text file, readable by a spreadsheet program such as LibreOfficeCalc.
Each time an ensemble is detected, details of the services in that ensemble are written out (such as in the picture above). Obviously, running the scanner for a couple of hours will generate a lot of output, therefore a second file, a summary file is generated as well. The summary file contains just a single line for each recognized ensemble.
If the mode controlled is selected, the scanner will run a specified number of times, the number determined by the value chosen for the spinbox, and generates a text file with a description of the ensembles and services encountered.
At the end, the scanner will show an overview of the result of the last scan over the band (similar to the scan output of the Qt-DAB program).
The DAB scanner supports most of the devices that are supported by Qt-DAB, i.e. the SDRPlay (using the 2.13 or the 3.06 library), the AIRspy, DABsticks. The Linux version can be configured to support the LimeSDR, the Hackrf and the ip client as well (since I do not have working dll's for these devices I do not offer support for the Windows version).
The sources for the DAB scanner - with an appImage for use under Linux x64, and an installer for an executable on Windows - can be found in this repository
The DAB library, a.k.a. dab-cmdline, is a library providing the functionality to decode a DAB data stream. It is used to create (a.o) command line programs to listen to a single service in a given band, without any form of GUI.
The repository contains a number of example programs, using the DAB library, either as a binary library or connecting directly to its sources.
Invocation of such an example programs, with some parameters specified, is something like
dab-sdrplay-2 -M 1 -B "BAND III" -C 12C -P "Radio 4" -G 80 -A default
In this example, the program was created with the SDRplay as device, it selects Mode 1 and "BAND III" (which both happen to be the default), Channel "12C" is selected, with a program "Radio 4", the gain is set to 80 and the output is just "default".
The example programs differ in details, example 2 (see the command line above) sends the audio output to the (local) soundcard, example 3 sends the audio samples to stdout, example 4 sends the AAC frames from the selected DAB+ service to stdout.
The sources and example programs for the dab-cmdline library can be found in this repository
The repository for dab-cmdline contains an extensive README that describes all (about 10) example programs and discusses the API of the library. Note however, that the example programs are meant to be examples, examples 2, 3 and 4 can be configured with the devices also used for Qt-DAB and dabMini, the remaining examples are highly experimental. In general: feel free to adapt to your needs.
As well known, DAB is transmitted in the old TV Band III. The bandwidth used is 1.5 MHz, (4 DAB channels take the width of one TV channel). Less known is that the short and medium waves have their own - small band - version of digital radio, Digital Radio Mondiale (DRM for short).
In Europe - with its dense population - DAB (DAB+) seems to be the choice, in more rural areas in the world, e.g India and parts of Africa DRM transmissions on short wave seem to be the medium.
DRM+, i.e. a version of DRM aiming at replacing FM stations, is currently in a rather experimental stage. It seems that in Russia some DRM+ transmissions are going on. To distinguish, the medium/shortwave version is called DRM30s, while the FM band version is called DRM+.
In Europe, one can receive a few DRM30 - i.e. shortwave - transmissions. Rumenia has still international programs transmitted in DRM, other transmissions that I receive are from Kuwait, India and Nigeria.
DRM, Digital Radio Mondiale, is a standard for digital radio and operated in medium and shortwave broadcast bands. As said, for medium and short wave there is DRM30, for VHF there is DRM+.
DRM30 and DRM+ (and DAB as well) are transmitted in Ofdm, the spectrum of which is easy to recognize: no signal peak as in Am or FM, just a block with (more or less) a constant amplitude over the whole frequency range of the signal. Using Ofdm blocks of data are transmitted that - using FFT techniques - can be mapped upon blocks of bits. Using some error correction techniques, errors - resulting from channel characteristics - can be corrected. This way, DRM can transmit up to 4 services in a single transmission.
While the basis sample frequency for DAB is 2048000, for most modes in DRM30 it is restricted to 12 Khz. A DRM30 transmission is limited in bandwidth: most transmissions are 10 KHz, however, transmissions with a width of 20 KHz and 5 Khz are also possible.
In DRM30 there are 4 modes and a number of options for the spectrum to be occupied, the mode and spectrum are to be detected from the characteristics of the datastream.
Processing DRM30 is far more complex than processing DAB (and therefore technically more interesting), especially the synchronization requires some effort.
For encoding the data QAM4, QAM16 and QAM64 encodings are used. Far more "technique" is needed to extract the bits from DRM than from DAB.
In this report I discuss the approach taken to synchronization in the DRM30 decoder of the swradio-8 and its predecessor. (Since I do not have to publish, it is an (eternal) preliminary version, and in details different from the current implementation, the algorithms are still the same though.)
The swradio-8 program is designed to "listen" to frequencies on the "shortwave" bands. It takes its input from a hardware SDR device and contains a dozen decoders to "listen" to some common modes.
The sw-radio-8 supports the SDRplay RSP devices: they have a frequency range starting at app 100KHz. Furthermore the Hackrf (since it supports frequencies starting at 1 Mhz) and RT820 based RT2832 compatible DABsticks are supported. For the latter there is a library supporting frequencies as low as 14 Mhz (the way the signal is dealt with requires a valid I/Q signal) and the DRM transmissions from Kuwait are around 15 MHz.
The software can also be configured to support the pmSDR device, i.e. using the soundcard, rather than the high-speed wide band SDR devices.
The implemented DRM30 decoder - limited to a bandwidth of 10 KHz - is able to detect the mode, and correct a limited frequency offset (i.e. up to a few hundred Hz). The picture shows the reception of the transmission from Nigeria, in the early evening in the 19 m broadcast band.
The DRM decoder widget shows at the right hand side 4 colored blocks that take the value green if everything is OK, otherwise red. Here, all 4 blocks are green meaning that decoding - up to and including audio decoding - is successfull.
The middle part of that widget shows at the top that there is only one service, that the transmission mode is Mode C, with spectrum 3 (i.e. just a 10 Khz spectrum with two sidebands), that the audio for the selected mode is AAC, and the name of the transmitting station is "Voice of Nigeria".
To the left there are 8 numbers giving some technical information on the received data.
Some other decoders in the swradio software are:
swradio-8 - sources and executables - can be be found in this repository on github. For Linux (on an x64 PC) a precompiled version is available (an appImage), for Windows an installer is available (see the releases page in that repository), however for the RPI's or other targets, one has to start with the sources. The README contains extensive instructions for generating an executable.
In some countries DRM+ is chosen to be the medium for digital radio. While DRM30 is developed for short and mediumwave bands, DRM+ is meant to be used in the VHF band. The bandwidth is 100 KHz, and the service data is encoded in either 4 QAM or 16 QAM.
Since the few DRM+ transmissions that I know of are in the FM band, the drmPlus, the DRM+ decoder that I developed, is also equipped with an FM decoder.
The picture shows the DRM+ part of the decoder. Since - as said before - there are no DRM+ transmissions in the neighbourhood, the development is being done using some files as input. The picture shows that for the given file, there are 4 services, and the green spots indicate that sychronization and decoding is all correct. The widget in the left corner shows the correction that is being carried out on the signal, the blue line indicates the correction to be applied on the phase, the red line the correction to be applied on the amplitude of the signal.
The second picture shows the FM part of the decoder. The SDRplay is used as input device (other devices are the RT2832 based "dab" sticks, the LimeSDR and the HackRF). It also shows the preset list, a list of station names and frequencies for fast selection.
As said, there are no DRM+ transmission here, there are hardly DRM30 transmissions here, developing software for these modes is mainly driven by an interest in the technology.
Sources are - as always - available, they can be found on this repository on github. Cooperation to further develop the software would be (very) welcome.
The SDR-J FM software supports - under Linux - next to the SDRPlay, the AIRspy, DABsticks, HACKrf, limeSDR and a soundcard, the sw-elad-s1 is supported when used with a downconverter. Under Windows the support is for the SDRplay, AIRSpy and DAB sticks.
The (W)FM receiver software implements different types of FM decoders, and - as seen on the picture - rds. It works on a rate of 192000 samples/second, data from the input device is downconverted to this rate if needed.
Operation is simple, the buttons and selectors on the main widget are equipped with tooltips. Furthermore, frequencies can be labelled with an appropriate name and stored in a preset list, for easy program selection.
The sources can be downloaded from github . In the releases section of that repository one will find a Windows installer.
The spectrumviewer program just shows the spectrum, up to the selected bandwidth determined by the selected samplerate. The spectrumviewer software can be configured with the SDRplay, the AIRspy, the HACKRF and DABsticks.
Operation of the spectrumviewer software is straightforward, tooltips tell the function of the various buttons and sliders.
The spectrumviewer will open a device that is configured and connected, in case of more devices are configures, it just opens the first one that it sees.
A frequency can be selected by entering the number in the keypad, terminating it with either MHz (for interpreting the number as the frequency in MHz) or kHz (for interpreting the number as the frequency in kHz). A scanning function is implemented with which it is possible to look at a wide range of frequencies.
The program shows both a spectrum and a waterfall, here over a range of frequencies in the FM broadcast band.
Since the input is usually wideband, up to 8 or 10 MHz, a decimator is part of the program, where the decimation rate can be selected. For e.g. an input signal with a width of 8 Mhz, decimation with a factor 100 gives a signal width of 80 Khz, making smaller band signals visible.
The set scan selector starts (or stops) scanning though the frequencies The 4 selectors to the left of the set scan button determine the frequency range, the stepsize and the rate at which the frequency change will occur.
The sources are to be found in this repository. The releases section of this repository contains an installer for the Windows version. This installer will install the executable and dependent dll's. It will also install the SDplay library interface, if not installed already.
Many interesting software packages for (sole) use with an RTLSDR compatible device exist and are available, dump1090 and acarsdec are typical examples. It would be interesting to have these programs and be able to use them with other devices, e.g. the SDRplay RSP. The acarsdec software was extended by me with an option to use the SDRplay, and a derived version of dump1090 was written with a small GUI and support for the SDRplay (the above mentioned qt-1090 program).
There are, however, other programs as well, e.g. rtl_433, aiswatcher etc. that are interesting and, somehow, tightly bound to the use of an rtlsdr compatible stick. I realized that it would be easier to write an rtlsdr emulator using the SDRPlay device than rewriting all software that I encountered and works only (primarily) with a DABstick. That lead to the development of the rtlsdr emulator for the SDRplay. Implemented as a plugin replacement for the rtlsdr library, either for Linux (librtlsdr.so) or windows ([lib]rtlsdr.dll).
For Windows, the version is extended and a small dialogbox is shown (shown at the top of the picture). The dialog box allows to set both the lna state and the if gain reduction. The emulator was tested with e.g. SDR#.
Note that - while it is working in a number of cases - it is far from perfect.
The sources of the library can be found in the github repository . Operation of the emulator is simple, it is just a replacement of "librtlsdr.so" under Linux or (lib)rtlsdr.dll under windows (it is assumed that you have the SDRplay lib installed).
In my environment the emulator works fine with both dump1090 (although qt-1090 has a better performance), acarsdec, and others, and on my development laptop the "standard" librtlsdr.so is replaced by the emulating one.
Since my interest is primarily in developing programs, I'm less (better word: not) interested in writing manuals (that no one ever reads anyway), so manuals are pretty much absent. The programs that are equipped with a GUI have tooltips, telling the function of the GUI elements. For the others, read the README and the CMakeLists.txt and/or the xxx.pro file. The repository for dab-cmdline contains a fairly extensive README with descriptions of the different example programs, an example of such a command line and build instructions.
There are some documents though:
a user's guide for Qt-DAB software (both Qt-DAB-3.4 and dabMini) is given here. The guide contains a description of the GUI elements, configuration options, how to generate an executable, how to add support for a device, and a description of dabMini.
an informal description of the synchronization in the DRM30 decoder is given in this description. The document will be a draft forever, but it contains quite some practical information on issues encountered in writing the software (the decoder for the sw-radio-8 program) for decoding the DRM30 signal.
For those interested to get an idea of how DAB decoding is implemented, a description of a - slightly limited - implementation of the DAB decoder in the programming language Ada is given.
For those interested in really old stuff that has nothing to do with Software Defined Radio, but happens to be for me one of the funniest projects, this repository contains (sources for) an algol 60 to C translator, with a number of example programs. The program was written in plain C around 2002, also as a hobby project at that time. Recently an addition was made: selecting a "-F" as one of the command line parameters causes the compiler to accept French keywords, rather than the default British/US style keywords. This manual describes - in about 20 examples - in quite some detail the mappings of Algol 60 constructs in the resulting plain C code. Actually, the compiler works pretty well on my x64 based laptop and my RPI 2 and 3.
In most of the SDR-J software existing dynamic libraries (Linux) and dll's (windows) are used, e.g. libraries for audio output, fft, handling "wav" files, reed-solomon correction, decoding AAC and xHE-AAC, converting samplerates, all available under a GPL-V2 or V3. All rights are gratefully acknowledged, and the SDR-J software is itself also made available under a GPL-V2 licence.
It is - obviously - nice if (some of) this software is useful, there are no guarantees, however. If the software does not do what you expect it to do, it might just be the case that it is not the software you are looking for. If, however, the software seems useful and you have suggestions for improving and/or extending it, feel free to inform me, suggestions are always welcome (although no garantees are given that they will be applied.)
Above all, read the license, that states (a.o):
SDR-J is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
The development of this - and other - SDR-J software is a hobby, a "spare time", project (being retired makes that there is some spare time). As with all hobby projects, support (such as suggestions for improvements, and additions, suggestions for modifications etc) and contributions (such as code improvements or extensions, providing me with a yet unsupported device, etc) are welcome.
I am grateful to SDRplay ltd for providing me the possibility to use different versions of the SDRplay RSP devices, all wonderful devices. Furthermore, thanks to Benjamin Vernoux for making an AIRSPY device, Great Scott Gadgets for making an HACKRF device and Jan Willem Michels for making a LimeSDR device available.
Pijnacker, May 2020
Jan van Katwijk
Lazy Chair Computing