Qt-DAB-3.0 is a further development of the Qt-DAB program, and a successor of the Qt-DAB-2.x program, a program to decode DAB and DAB+. The program, developed under Linux, runs under Linux, is cross-compiled for use under Windows (and was ported to IOS). It runs well on an RPI 2 and RPI 3, and has a number of features not often seen.
The program supports audio services in both DAB and DAB+, it also supports simultaneous processing of main and subchannels in a given service. Furtermore, decoded data from a packet service with TPEG or ip data - when selected - can be made available to other programs using the IP protocol (depends on the configuration). A packet service with EPG data or journaline data - when selected - will see its decoded output written to a file. MOT data is handled by the program itself and pictures will be shown.
The implementation of Qt-DAB-3.0 is - obviously - based on the implementation of previous versions. Many (technical) improvements were made since version 2 arrived and some functionality is added.
Next to - invisible - differences in some parts of the implementation, the visible difference with previous versions is in the GUI. Based on requests and user experience some buttons and selectors were added in the subsequent 2.x versions: a presetselector, a previous channel button and a button to start (or stop) writing aac frames to a file. That, as well as the addition of a next service and a previous service button asked for a minor redesign of the GUI.
One of the recent additions is the possibility to write AAC frames from a DAB+ audio service into a file. The output then can be processed by external programs, such as VLC.
A second addition is implementing support for presets. The preset facility allows maintaining a list of "favorites", just touching the preset in the preset list instructs the software to switch over to the channel to which the preset service belongs, and in that channel selecting the preset service. Preset services are made visible in a combobox, just below the list of services.
Note that the preset value consist of the combination channel:servicename. It sometimes happens that a service service shows up in different channels (here we have 5B:Radio West transmitting in mono and 8A:Radio West with the same program in stereo).
Presets are kept between program invocations in a file .qt-dab-presets.xml, a file in xml format, maintained in the user's home directory.
Adding a preset is by clicking with the right mouse button on the name of the currently selected service (note that clicking with the right mouse button on any of the other service names in the list will show some technical data on the service by that name).
Removing a service name from the presets is by touching with the curson the name of that service in the list of presets, and simultaneously pressing the shift and delete keys on the keyboard.
Since for some devices one needs to adjust some settings, on startup the widget with controls for the device is shown. However, the GUI contains a button to hide that widget, the program will keep track on the setting of this button, and store the setting in the ".ini" file for deciding whether to show the control widget or not at the next program invocation. If the widget is hidden, the text on the button is show.
Different from previous versions, the main widget now shows the frequency of the selected channel and (on Linux) the current CPU load on the machine, and - if detected - an estimate of the Transmitter Identification Information. Furthermore, the service label, is now shown in the technical data widget rather than as a separate entity.
Finally, while not supported anymore in the current DAB standard, the Qt-DAB-3.0 program still supports other modes as well as transmissions in the L-band. However, the GUI does not provide means to select mode or band, setting the software to another mode or to the L-band requires setting the correct values in the ".ini" file.
The buttons and selectors - not directly related to selecting a channel or selecting a service - are now grouped together.
From left to right, the top row of the button panel contains:
the Content button, when touched, will show a file selection menu with which a file can be selected to which an overview of the content of the current ensemble is written.
the Detail button that, when touched, shows (or hide) a widget with additional information on the selected service.
the reset button that, when touched, instructs the software to start with synchronizing again.
the scan button that will start (or stop) a scan over the channels until one is encountered with a DAB signal.
The buttons on the second row will show or hide the widgets for the Transmitter Identification Information data, for the correlation result in synchronizing, for the spectrum and the signal constellation, and for the control widget of the selected device.
The selectors on the third row are for selecting an audio channel (default set to "default") resp. the input device.
The buttons on the bottom row will start (or stop) writing the raw input samples, resp. the DAB+ AAC frames, and the audio output samples to a file. Touching them will first show a file selection menu. Touching them when writing is in progrss will stop the writing.
Qt-DAB-3.0 supports a variety of devices. Next to physical devices (listed below), it does support processing of "raw" ("iq") 8-bit input files as generated by some osmocom software, it does support processing of 16 bit ".sdr" files as generated by the Qt-DAB-3.0 program itself. Furthermore, it does support input from an rtl_tcp server (also 8-bit osmocom software).
In between program invocations, the software stores the name of the selected device and will (try to) open it on the next invocation of the program.
The control(s) for the various devices themselves will maintain the settings of the various controls between invocations, data is stored in the ".ini" file and read in on program start.
Devices that are currently supported are:
Adding a device is not very complex, these are just the devices I have access to. If you have an interest in adding support an a device, read the description of the interface, describing which functions need to be implemented, which is part of the sourcetree (or send me the device).
Qt-DAB - sources and executables - is to 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 and for Debian/Ubuntu systems, a script is available with which the executable can be generated.
The sources for Qt-DAB-3.0 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. Apart from these, there is a DAB version intimately coupled to the SDRplay RSP's (sdrplayDab), a "small" one, i.e. hardly any buttons (dabradio), one written in Ada (might be a little out of date now) and one written in Java.
Furthermore, there is a version - actually one of my favorites - implemented as a server and running (a.o) on an RPI 3, where an "app" on an Android tablet is the client (soon to be followed by a client on the PC). Communication between client and server is using bluetooth. The server can be installed as a service, starting up in the initalization sequence of the (Linux based) OS on the host. I often run the server on an RPI that is not connected to the home WiFi.
For all these programs a repository exists on Github 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).
In continuous mode a skipfile can be selected, that file tells which channels are not part of the scanning process and which are. Such a skipfile can be modified dynamically, on program start up one may select a file as skipfile.
The output of the scanner - a text file readable by a spreadsheet program such as OpenCalc - contains detailed information on the ensembles encountered..
If the mode "continuous" is selected, actally two output files are written. In the first one, each time an ensemble is detected, details of the services in that ensemble are written out (such as in the picture above). Next to that, a summary file is written, one with only a single line for each recognized ensemble is written.
The sources for the DAB scanner - with an installer for an executable on Windows - can be found in this repository
The DAB library is a library containing the full 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 happens to be the defaults), 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 values comprising the AAC frames from the selected DAB+ service to stdout.
New is example 9 that - as an experiment - modulates the audio output as an FM signal (with the dynamic label contents as rds data) and sends it to a small server running the HackRF .
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, feel free to adapt to your needs and improve.
Next to DAB, transmitted with a bandwidth of 1.5 MHz in the old TV III Band, the short wave has its own - small band - version of digital radio, DRM (Digital Radio Mondiale). Although most European transmissions in DRM stopped, DRM seems to gain some terrain outside Europe. In Europe - with its dense population - DAB seems seems to be the choice, in more rural areas in the world, e.g India and parts of Africa 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.
In Europe, one receives some DRM - i.e. shortwave - transmissions. Romenia still is one of the few European countries transmitting in DRM, other transmissions are from Kuwait, India and Nigeria.
DRM, Digital Radio Mondiale, is a standard for digital radio over short wave and operated in short wave broadcast bands. A DRM transmission is therefore limited in bandwidth: most transmissions are 10 KHz, however, transmissions with a width of 20 KHz and 5 Khz are also possible. While the basis sample frequency for DAB is 2048000, it is for DRM 12 Khz. Furthermore, in DRM there are 4 modes and a number of options for the spectrum to be occupied, the mode can be detected from the characteristics of the datastream. The detected mode determines a number of settings for the DRM frames. With such a bandwidth it is still possible to transmit up to 4 services (2 audio and 2 data).
Processing DRM is more complex that processing DAB, especially the synchronization, while for encoding the data encoding of up to QAM64 are used. More "technique" is needed to extract the bits from DRM than from DAB. In this report I discuss the approach taken in the sweadio-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 sources can be configured to support the pmSDR device, i.e. using the soundcard.
The implemented DRM 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 picture shows - next to the main widget with the spectra of the received band and the selected subband - a widget dedicated to the DRM decoder. That widget shows at the right hand side 4 colored blocks that take the value green if everything is OK, otherwise a red color will be shown. Here, all 4 blocks are green meaning that decoding - up until 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 (important) details on processing the input (the left column relates to the timing error of the incoming samples, the top elements in the other column indicate the measured frequency offset. The bottom number in the right column gives the instantaneous SNR).
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.
The SDR-J FM software supports - under Linux - next to the SDRPlay, the AIRspy, DABsticks, HACKrf and a soundcard, the sw-elad-s1, to be used with a downconverter. The (W)FM receiver software implements different types of FM decoders, and - as seen on the picture - rds.
The software works on a rate of 192000 samples/second, data from the input device is downconverted to this rate.
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 is connected.
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 the 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. The aforementioned windows-bin.zip contains an "rtlsdr.dll-fake" that can be used (after renaming of course) instead of the real "rtlsdr.dll" lib.
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 brief descriptions of the different example programs, an example of such a command line and build instructions.
There are some documents though, an informal description of the synchronization in the DRM 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 (one of the decoders for the sw-radio-8 program) for decoding the DRM signal.
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.
A manual, contained in the repository, gives - in about 20 examples - in quite some detail the mapping between Algol 60 constructs and the resulting plain C code. Actually, it works pretty well on my x64 based laptop and my RPI 2 and 3.
Most of the SDR-J software depends on existing dynamic libraries (linux) and dll's (windows), e.g. libraries for audio output, fft, handling "wav" files, reed-solomon correction, aac decoder, samplerate converter, all available under a GPL-V2 or V3. All rights are gratefully acknowledged, and the 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 warrantees, however.
If the software does not do
what you expect it to do, it might be the case that it is not the
software you are looking for.
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.
However, if the software seems useful and you have suggestions for improving and/or extending the software feel free to inform me, such suggestions are always welcome (although no garantees are given that they will be applied.)
The development of all this software is a hobby, a "spare time", project (being retired there is probably more spare time than for someone who is working), as with all hobby projects, support and (material) contributions are always 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, November 2019
Jan van Katwijk
Lazy Chair Computing