Qt-DAB-3.X is the most recent version of the Qt-DAB 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 PC, RPI 2 and RPI 3, and has a number of features not often seen.
The program supports decoding of DAB and DAB+ audio services as well as data services. For audio services, it handles simultaneous processing of a main audiochannel and its (data) subchannels (if any).
For data services:
a packet service with TPEG or ip data - when selected - can be made available to other programs using the IP protocol, if configured the data is sent to an IP port.
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, pictures will be made visible and directories with data that are transmitted are stored.
Based a.o. on user requests, some buttons and selectors were added: a presetselector, a next channel and 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.
A recent addition is the possibility to write AAC frames from a DAB+ audio service into a file. The output - a sequence of AAC frames - then can be processed by external programs, such as VLC.
A second addition is the implementation of a preset facility. This facility allows maintaining a list of "favorites", any service encountered can be registered in the preset list, just touching a name 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 service with that name. Preset services are made visible in a combobox, just below the list of services.
Note that a preset value is built up as a tuple channel:servicename. It sometimes happens that the name of a service shows up in more than one ensemble (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.
(Note that - similar to what I see on my car radio - a list is maintained of all services ever encountered. The list can be made visible by touching the xx button. Elements in this list can be selected by a mouse click).
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 the current CPU load on the machine, and - if detected - an estimate of the Transmitter Identification Information.
The technical data widget now only shows data related to the selected service. Also, 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.X program still supports other modes as well as decoding 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 in the selected band and will show an overview of the ensembles and services found.
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 xx button on the bottom row shows (or hides) the list of all services ever encountered. Touching an element in this list will select the service.
The other 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.
Until recently, the scan function of the Qt-DAB program just scanned until a channel was encountered that contained DAB data. Based on user requests, the function was changed and now provides an overview of all ensembles and services found in the selected band.
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.
Currently, both QIRX and Qt-DAB provide a reader, able to handle xml files and the various device handlers all are equipped with a "dump" button to generate such a file, directly from the selected device.
Qt-DAB-3.X supports a variety of devices. Next to xml files as described above and 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.X 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 controllers 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:
the various RSP's from SDRPlay using a 2.13 library. As known (at least by those using the SDRplay), new SDRplay devices need the 3.06 library
Qt-DAB further supports
Adding support for 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 device API, describing which functions need to be implemented. The description is in a text file in 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.
For Debian/Ubuntu systems, a script is available with which the executable can be generated. For the RPI, the Debian script is such that on running it all required libraries will be loaded, the most recent Qt-DAB sources will be loaded and an executable will be generated (Note however, that one may want to adapt the configuration in the qt-dab.pro file.)
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. 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, and a specialists version for handling eti data streams.
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. The contens of this skipfile can be modified dynamically. In this mode, one selects a skipfile on program start up.
The output of the scanner - a text file, readable by a spreadsheet program such as OpenCalc - contains detailed information on the ensembles encountered.
In "continuous" mode, actually 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.
If the mode controlled is selected, the scanner will run a number of times, 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 the same devices as supported by Qt-DAB, i.e. the SDRPlay (using the 2.13 or the 3.06 library), the AIRspy, and the DABsticks. The Linux version can be configured to support the LimeSDR and the Hackrf (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 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 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 Band III, the shortwave has its 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 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 DRM30.
In Europe, one can receive a few DRM30 - i.e. shortwave - transmissions. Rumenia is still one of the few European countries transmitting 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.
The digital content of such a transmission contains different elements, part of the digital content is used as a kind of directory, describing the services carried. The services themselves are either audio or data and up to 4 services can be carrier in a single transmission.
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.
While the basis sample frequency for DAB is 2048000, for most modes in DRM30 it is restructed to 12 Khz. In DRM30 there are 4 modes and a number of options for the spectrum to be occupied, the mode and spectrum can 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. 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.
n 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 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 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.
In some countries DRM+ is chosen to be the medium for digital radio. While DRM30 is meant to be operated in the shortwave 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 Mode and Spectrum are fixed, a DRM+ decoder has an simpler job in finding synchronization than the DRM30 decoders.
Although in the part of the world where I live there are no DRM+ transmissions (and probably never will) I am developing a DRM+ decoder. Decoding DRM30 and DRM+ is interesting from a technical point of view, and it provides ample opportunities to play around with a variety of algorithms.
Since the few DRM+ transmissions that I know of are in the FM band, the drmPlus, the DRM+ decoder, 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 with that input, 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 carrier 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, the software is under development. However, 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 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.
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:
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.
Most of the SDR-J software uses existing dynamic libraries (linux) and dll's (windows), 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 warrantees, 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 all this SDR-J software is a hobby, a "spare time", project (being retired makes that there is 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 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, Februari 2020
Jan van Katwijk
Lazy Chair Computing