DAB, Digital Audio Broadcasting is gaining popularity. While in e.g, Norway the traditional FM broadcasting is already replaced by DAB, in other countries FM will be phased out and replaced by DAB or DAB+ in the next decade.
DAB+, now commonly in use, uses the same transmission technique as DAB. The difference is in the packaging. Some DAB transmissions contain data packed as DAB as well as data packed as DAB+.
In most countries the old TV Band III (176 .. 230mHz) is used for terrestrial DAB transmissions. Such a DAB transmission requires a bandwidth of 1.5 mHz, so one "old" TV channel in that band may contain up to 4 DAB channels.
Since the contents is digital, a DAB (DAB+) program can contain basically anything that can be expressed in a row of bits. So, next to audio - after all we are talking about radio - text, pictures and basically any other form of data can be and are transmitted.
While the transmitted signals are - obviously - analog, the output of the required "hardware" (i.e. a DABstick,an SDRplay or an AIRspy) is digital, a stream of samples. From a software point of view, a DAB (DAB+) transmission can be viewed as a sequence of DAB frames, each containing 199608 samples (taken at a sampling speed on 2048000 samples per second).
Such a DAB frame is logically built up from a number of data blocks. Frames themselves are separated by a period where the transmitter (almost) silences. In Mode I, pretty common around here, a frame is logically divided into a null period of app 2600 samples, followed by 76 data blocks, each consisting of app 2500 samples. Since the sample rate is 2048000, and a full frame takes 199608 samples, just over 10 frames per second are transmitted.
The first data block is used for synchronization, blocks 2, 3 and 4 (the so-called FIC, Fast Information Channel blocks) contain descriptive data, used to describe the structure of the data in the remaining Main Service Channel (MSC) blocks.
The software decoding DAB (DAB+) has to accomplish three things:
building and maintaining a "table of contents" with a description of what the different programs in the ensemble are, and where they are to be found in the MSC blocks;
extracting the program data from the MSC blocks and converting the bitstream to audio, text and other forms of presentation as dictated by the "table of contents".
For more information on DAB, refer to e.g. https://www.worlddab.org
In 2012/2013 I started to develop DAB software, with a cheap RT2832 based DABstick as input device. The DABstick was used to shift the frequency band around the selected frequency to an intermediate frequency (IF), zero in our case, and to sample the inputstream, passing on the samples to the USB output port. As it turned out, the osmocom group (www.osmocom.org) provided an excellent library to control this kind of device.
The computer software then reads the samples, identifies the DAB frames, and interprets the data. Based on the data in the FIC blocks the software presents a list of programs the user could select from, and - once a program was selected - converted the incoming bits (after some more transformations) into audio.
In a later stage support for the SDRplay and the AIRspy devices was added: by using a simple iterface between the device (handler) and the rest of the software it is pretty easy to add another device (feel free to try).
After acquiring a Raspberry PI 2 it turned out that some modifications were needed, running the software as it was caused some of the cores of the ARM cpu to overload. Partitioning the work and spreading it over some well-chosen threads turned out to be the solution here.
Since I am using the Raspberry completely headless, control is remote and a feature (configuration parameter) was added to tell the software to send the audio output (the PCM samples) over an IP port.
Next, based on user requests two different versions of the software were made, one allowing the construction of a command-line only version, the other one to create ETI intermediate files.
While the software was written in C++, just out of curiosity, a version with Ada as implementation language was made.
The Qt-DAB version is a program using Qt for a user interface and some other Qt classes internally. The program supports - next to input of 8 bit raw (iq) files and 16 bit "wav" files - the SDRplay device (both the RSP I and RSP 2), the Airspy, and the RT2832 based DABsticks (and the Windows version supports "Extio" plugins).
The Windows version of the Qt-DAB program (together with some other programs) is available as a zipped folder here . (Note that often a more recent Windows version can be downloaded from the github site mentioned above).
The Qt-DAB software can be compiled on/for a Raspberry PI 2 (or 3).
Depending on the configuration, the GUI contains several widgets.
A widget for the control interface, containing buttons and selectors for selecting a device, a channel, a DAB mode, an audio output device, a program in the received ensemble and dump facilities for the raw input and the sound output.
A widget showing characteristics of the incoming data (optional).
The spectrum of the signal being received. The picture shows that for the selected mode, the spectrum contains a massive block of data with a width of 1.5 mHz.
A constellation diagram. During decoding the signal is mapped onto values in an (x,y) plane. The x and y coordinates of the value are used to identify the bits. The quality of the signal can be deduced from the density of the clouds of dots in the 4 quadrants. Poor quality signals show large clouds, good quality signals merely show a dense cloud, almost reduced to a dot.
The number depicted below the constellation diagram is a measure of the quality of the signal, it indicates the standard deviation in the cloud of dots. The better the quality of the signal, the smaller the number.
A widget with technical data from the selected program. In the Linux version the widget also shows the CPU load. It shows that on my laptop this load is somewhere between 20 and 30 percent, while on the Raspberry PI 2 the load is app 65 to 70 percent.The indicators at the bottom of this widget show
the quality of the FIC decoding (FIC, as said, being the first few data blocks in a DAB frame, containing descriptive information on the data);
the success rate in identifying DAB+ frames. Note that a DAB+ frame is formed from data from 5 consecutive DAB frames.
the percentage of error free audio segments for the selected program;
In case we have a plain DAB transmission, only two indicators are shown, one for the FIC and one for the decoding of the audio.
A widget for the device control. Depending on the device, the widget contains a slider for setting the gain, a spinbox for setting a correction on the oscillator of the device, and a tick box for setting the autogain.
New features are
a button to save information on the current ensemble into a file;
an option to restart the software with the service selected in the previous incarnation of the program.
The most recent sources can be found on
Next to the sources that site contains a so-called "appImage" for use on an x64 based Linux system. The appImage contains all libraries for running the QT-DAB application. Simply download the appImage and run it (the appImage requests a validation to allow setting the udev file to allow the use of the attached usb devices).
The appImage is always based on the most recent sources and contains driver software for both the DABsticks and the Airspy. When the SDRplay driver is installed on the target, the Qt-DAB software can use that device as well.
To create some flexibility it was decided to create a "DAB-library", a library containing all of the functionality required for DAB handling with a simple API. A command line handler then can use this library, as can whatever other command handler.
To show the versatility of this approach, command line handlers - interfacing to the DAB library - were created. Two more or less regular command line handler in C++ as well as one written in Python, and a (limited) GUI-based version using Qt are all part of that pieve of software. The DAB library itself does not depend on Qt.
Obviously, in a command line version, all parameters are set and fixed when calling the program. Device support is built-in in the command line version, the other settings are through a command line parameter. An example of a command line is
./linux/dab-cmdline -M 1 -B "BAND III" -C 12C -P "Radio 4" -G 80 -A default
The full set of sources, both for the library, the C++ bindings, the "simple" GUI example and the python binding are to be found
ETI, Ensemble Transport Interface, is an intermediate format for handling DAB. It is defined in ETSI: EN 300 799. The ETI representation of a DAB transmission is significantly smaller than a dump of the input. The output of the eti-cmdline tool can be stored in a file, or passed on to an interpreting program.
The current eti-cmdline version only supports Mode 1, and since the device support is part of the build configuration, the main command line parameters are just the Band the Channel, and the file to which the output is to be written.
The full set of sources of the eti-cmdline program, accompanied by sources for an "ETI-backend" (using a Qt based interface) are to be found
A - slightly limited - version of the DAB software encoded in the Ada programming language. The limitations are twofold, as with the command-line version the choice of the device is a build-time parameter and there is only audio support with limited PAD handling.
Just to renew my knowledge of the Ada language I wrote this program. The program has a small GUI, created using GtkAda. Ada is a language for critical - mostly embedded - systems, and requires in coding more discipline than C or C++.
Since the program interfaces to a radio device for its input and a sound device for its audio output, and since the basic support for input and output is in C, the program shows bindings to C functions, callbacks from C libraries, application of generics, excercising OO techniques in Ada etc.
The implementation uses Gnat for compiling, and the GtkAda library is required.
An informal description of the processing of DAB, as implemented in this Ada version is given here. This (draft) report describes in some detail - including a number of code fragments - how the Ada version of the DAB software is built up. The description presumes some basic knowledge on Ada and on the structure of DAB.
The "architecture" of the implementation slightly differs from that of the Qt-DAB program, Ada has a far more advanced tasking model and the implementation itself is simpler due to the choice for device selection in build-time. Nevertheless, large parts of the implementations resemble each other, and the Ada version works fine.
The sources of the Ada implementation can be found at
https://github.com/JvanKatwijk/ada-dabFor compilation, one needs the GtkAda-3 toolkit to be installed.
Development of SDR-J programs started with an attempt to get some sound out of a PC, using an Elektor SDR card as (Elektor May 2007) radio device, it evolved into the current set of programs. are still being maintained.
The pictures show (from left to right) screenshots of
The current precompiled (Windows) version is compiled against
recent libraries for the devices (2.09 for the SDRplay, 1.08 for the AIRspy).
The software will probably
not work with versions of the SDRplay library before 2.05.
Furthermore, the common programs are equipped with tooltips, where the function of a button, slider or other widget can be viewed by moving the cursor over the widget.
For Windows, there is a single zipped folder containing
the executables and relevant dll's for all programs.
Download the Windows version of the DAB, WFM, Spectrumview
and SW software in a zipped folder here .
Note that, while a number of dll's is in the zipped files, the "basic ones" are supposed to be available elsewhere on your system. Note further that the libraries for the SDRplay - if you wish to use that - should be downloaded from the producer of the device.
The (Wideband)FM software contains a simple FM receiver, configured to be used in conjunction with a specified device, one of DABstick, SDRplay or AIRspy (depending on the configuration). The software runs under Windows (precompiled versions for all three mentioned devices as well as for Extio-XXX.dll's). Under Linux (both PC and Raspberry PI 2) it can be configured for any of these devices.
The program(s) support decoding FM transmissions in mono and stereo and support RDS decoding (obviously, the frequencies to be received depend on the radio device connected).
A recent feature is that the FM software supports a program list, a list of known programs with their frequencies, which can be set and altered. Such a program list may contain selected program names with their associated frequency and is maintained between program invocations. Selecting a station from the list will set the program to the frequency for that station.
Operation of the WFM receiver software is straightforward.
When the program is started, it will be idle until the button "START" is touched.
The button labelled "default" on the top row is the selector for the audio device. The selection depends on the soundcard on the system. The button labelled "fm4decoder" allows selection of an FM demodulator, 5 different approaches to FM demodulation are implemented, the "type" of the decoder show on the field to the right of the selector (the one shown is apparently the pll based one).
The button labelled "rds on" is the selector for the rds "on" or "off" the coloured field indicates the successful decoding of the rds signal, "green" indicates that the software thinks to be able to decode the signal, "red" that is doesn't.
Further selectors are the "squelch" and the selectors f-, etc. With the latter one may step through the frequencies (steps are 100 kHz) either manual (the buttons f- and f+), or automatic, the buttons fc+ and fc1.
Finally, with the button "FS", one may save the current frequency setting and bind a name to it.
The more general sdr-j-fm software is also still available. As can be seen from the picture the GUI contains more elements, it shows e.g the spectrum of the incoming signal as well as the spectrum of the decoded signal.
This version supports - under Linux - the sw-elad-s1, to be used with a downconverter. Note that the program is - especially when running Windows - quite resource hungry.
While the Windows executable is in the windows distribution, the sources can be downloaded from
For experimental purposes a simple command line based version of the FM software was created. The software sends it output to stdout, rather than to a soundcard. it can be used to see what is happening on the P2000 band on 169650.
sdrplay_radio -f 169650000 [-p3] |multimon-ng -a FLEX -t raw /dev/stdin
Of course one can use the program to listen to FM transmissions as well.
sdrplay-radio -f 94700000 -g 30 -M fm-stereo -D -Z |aplay -r 22050 -f S16_LE -t raw -c 2
Since the osmocom site has an excellent version of rtl_fm, the version here can only be configured for the SDRplay or the AIRspy.
The sources for the xxx-radio are to be found
The SW software aims to be the SDR equivalent of a classical SW radio. It originated as a small package for shortwave listening with the Elektor SDR card from 2007 and it evolved into the current program. The program supports a number of input devices and nearly a dozen decoders. I use it to listen to amateur bands, to psk, rtty and usb and lsb transmissions and - occasionally - to listen to RRI, sometimes to radio Nigeria and - depending on the conditions - to the DRM transmission of Bangalore. i.e. the few remaining DRM transmissions.
The SDRplay and DABstick are directly spported devices, both in the Linux
and the Windows version. The SDRplay supports frequency selection from app 10 kHz and up
and is used to listen to short wave. For DABsticks, there are libraries
with which a decent reception from 12mHz up is possible.
Under Linux, there is also direct support for the Elad-s1 (I don't own one, but a friend does). Furthermore, under Linux support for the Elektor card and the pmSDR can be compiled in (both devices need a cardreader for data input), or just a cardreader without device can be used.
Finally, there is support for receiving the raw antenna data using the WiFi, a simple server is part of the software, supporting the SDRplay, and sending the (decimated) data to an IP port. The receiver site is equipped with a small client program as one of the "device-handlers".
In the precompiled Windows version, direct support for the Elektor card and for the pmSDR disappeared since using the ExtIO-XXX dll for these devices is an excellent alternative. Handling of devices for which a Winrad compatible dll exist is now extended with support for fast devices, i.e. devices such as DABsticks and SDRplay that deliver their data through the usb. I tested it with the ExtIO-XXX dll's for the SDRplay and DABsticks.
Since the decoders in the software are all "small-band" (for CW and PSK I normally set the width of the decoder screen to 6kHz, and select the preconfigured USB bandwidth of 2.5 kHz, while for DRM a bandwidth of 12kHz is really needed), the sample rate of the data from the fast devices such as the SDRplay, is reduced to 96000 or 48000 (it can be set to different values in the configuration file though, but 96000 samples/second leads to a spectrum-width of 96000 Hz which functions well on a common laptop screen).
My personal use is listening to SW using the aforementioned simple "server", running on the Raspberry PI 2 in the neighbourhood of a loop antenna with a simple amplifier on the attick, that provides the (decimated) sample-stream from the SDRplay to the home WiFi, allowing me to listen to shortwave radio from within the "lazy chair". The sources for the software, implementing a simple server for the SDRplay are part of the SW sources. The sources for the client are also part of the software tree.
The screen depicted in first picture shows this "normal" way of working. The window of the SW program in the middle, with at the right the widget for the selected device, which is "remote SDRplay" and the widget of the SDRplay server - which runs through an SSH connection on my Raspberry.
The various pieces of software for interfacing to a device as well as the various decoder are implemented as plugins. Adding or deleting a device or a decoder is simple, just add the plugin code to the appropriate directory, and does not require recompilation of the main program.
On start up, the main program will look into an ".ini" file for the path-names that specify where to find these plugins. If no ".ini" file exists as yet, defaults "input-plugins" and "decoder-plugins" are chosen. To set up the paths for the decoder plugins and the input plugins in an ".ini" file, a small configuration utility ("configure") is included. The second picture above shows the widget for this configurator. It merely asks for the paths names and creates (or updates) an ".ini" file in the home directory of the user.A variety of decoders is implemented
On the 7 and 14 mHz band there are plenty of CW and psk calls. The 3855 Khz frequency is often used by me to receive weatherfaxes. There are not a lot of DRM transmissions, here, we normally receive the Radio Rumenia International, the DRM program of the Indian radio and radio Nigeria.
For use under Windows, a pre-compiled version of the sw-receiver software is here available in the same zipped folder as for the other programs. That folder contains plugins for input and decoders in subdirectories input-plugins resp. decoder-plugins and it contains many of the required DLL's. Using the SDRplay as input device does require installing the software from the producer of the device.
For use under Linux, one might want to download the sources from "https://github.com/JvanKatwijk/sdr-j-sw". The source tree contains subdirectories for the configurator, for the sw software proper and for the "server". The tree for the SW software itself contains subdirectories for the plugins, implementing the decoders and plugins implementing the support for input devices.
For compiling the main program one needs - obviously - the C++ compiler, the Qt libraries and development files and the QWT library and development files. Furthermore, the fftw3 library, the portaudio library, the libsndfile and libsamplerate libraries are also required.
For compiling the plugins (to be found in the subdirectory "plugins/input" and "plugins/decoders") one might need more libraries, depending on the plugin. E.g. for the rtlsdr as device one needs the rtlsdr library and libusb. Have a look at the configuration file. In the subdirectories for the input and for the decoder there is a small script to generate the plugins
Note that for the drm decoder plugin, one needs an adapted version of the "faad" library, a version compiled for DRM. The internet is full of examples on how to do that (./configure --with-DRM). Note further that, depending on the selected estimator, one might need additionally the "armadillo" library is needed (for some complex matrix operations), the default setting is such that armadillo is not needed.
The Windows version of the plugin for DRM has the correct library compiled in.
The spectrumviewer software is a simple program, it just shows the spectrum, up to a selected bandwidth, determined by the selected samplerate. The spectrumviewer software can be configured with the DABstick, the SDRplay, the AIRspy, the sw-elad-s1 and a soundcard.
Operation of the spectrumviewer software is straightforward.
The selector, marked "airspy" on the picture is used to select a device.
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).
The selector "viewmode" makes selection between spectrum or waterfall mode possible, touching the button "freeze" will - as the name suggests freeze - the spectrum shown.
The "set scan" selector starts (or stops) scanning though the frequencies The 4 selectors to the right of the "set scan" button determine the frequency range, the stepsize and the rate at which the frequency change will occur.
The precompiled Windows executable is to be found in the zipped folder
together with the DAB and WFM software. The configuration of the pre-compiled
version contains, next to
the DABstick, the AIRspy, the SDRPlay and the soundcard, a handler for devices supported by an Extio-XXX dll.
The sources, for compilation under Linux, are in
Since the interest is more in programming than in writing manuals (that no one ever reads), the manuals are not up-to-date. There is a manual for the dab receiver, for the wfm software, and one for the sw-receiver (note that the latter manual still refers to the previous version where the control box for the selected device is on the GUI and where there is no mention of the DRM decoder). However, in the version distributed now, the GUI's are extended with tooltips, telling the function of the various elements of the GUI.
An informal description of the synchronization in the DRM decode is given in this description the document continues to be a draft, but contains quite some information on issues with decoding the DRM signal.
A description - also informal - of the processing of DAB, as implemented in the Ada version is given here. This (draft) report describes in some detail - including a number of code fragments - how the Ada version of the DAB software is built up. The description presumes some basic knowledge on Ada and on the structure of DAB.
As an exercise in programming, basically to renew my knowledge of the
language after a period of 20 years, a - slightly limited -
version of the DAB-rpi program was rewritten in Ada.
For implementing the - simplified - GUI the Ada binding to gtk, gtkAda, is used.
The resulting program runs pretty well on my laptop and it was a nice and interesting exercise to create it.
I did not manage (yet) to compile the Ada sources on the Raspberry PI 2 and did not attempt to generate a Windows executable.
The current version has support for the input device "compiled in", i.e. the device is determined by the configuration settings (see the file "main.adb" for instructions how to select a configuration for one of the other supported devices). The Mode and Band can be selected though in the command line (defaults are Mode 1 and Band III).
The audio output is sent to a "default" device, no selection for other output devices is possible (yet). Contrary to the very first version, the current version heavily depends on the use of generics.
The sources were compiled using the gnat compiler and gtkAda3. The Ada sources bind to C libraries for fftw, libsndfile, libfaad, portaudio and - obviously - to the libraries for the device.
The sources are available at "https://github.com/JvanKatwijk/ada-dab".
To make life easy, a compressed 8G image of a Debian Jessie distro
for the Raspberry PI 2 with both the DAB-rpi and WFM-rpi software installed
(sources, required libraries and executables) is available on request.
Apart from the additions needed to compile and run the DAB-rpi and WFM programs, the distribution is clean.
Note, however, that this image will only run on an Raspberry PI 2, not on an Raspberry PI 3. Note further that different distributions for the Raspberry PI 2 sometimes support pretty old compilers. The g++ compiler in the Jessie distribution is a 4.XXX, while the g++ compiler on Fedora, my development system, is 6.4. This has impact on the efficiency of the compiled programs.
All software is being developed as a hobby project, and
available under a GPL.
It is - obviously - nice if this software is useful, but as the license states:
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.
I am grateful to SDRplay ltd for providing me the possibility to use
the SDRplay and to
Benjamin Vernoux for providing me the possibility to use the AIRSPY, both wonderful devices.
Suggestions and contributions (material and immaterial) are welcome.
Pijnacker, August 2017
Jan van Katwijk
Lazy Chair Computing