DAB, Digital Audio Broadcasting, is considered to be the future of radio in Europe, Australia and some other parts in the world. DAB, of better, DAB+, is transmitted in the old VHF Band III, and a single transmission takes a bandwidth of 1.5 MHz. A DAB transmission usually contains a number of services, packed in an ensemble.
While transmissions are analog by nature, the content of a DAB transmission is digital. For a decoder like Qt-DAB the world starts with samples, digital samples arriving with a rate of 2048000 I/Q samples per second. The conversion from the analog signal received by the antenna, somewhere around 220 MHz and a stream of samples with an IF of 0, is far beyond the scope of Qt-DAB and similar programs. For this conversion, Qt-DAB (and other decoders) depends on an SDR converter, such as the SDRplay device, an Adalm Pluto or an RT2832 based dabstick. While there are enormous differences between different devices, they all have in common that they do what is needed: with an antenna receiving signals and converting them to a stream of IQ samples.
Since the DAB data is digital, basically anything that can be represented digitally can be made part of the transmission. Next to audio (after all it is radio), slides can be - and are frequently - transmitted, of course text messages are part of the transmission, traffic information and file transfer are possible, and one of the options is to redirect the contents of a service to an IP address.
Non-audio data can be made part of an audio service (the so-called PAD services), or it can be made into a data service, the latter usually send as a stream of packets.
DAB started in the end of the previous century with MP2 based frames to carry the audio content, later on DAB+ was introduced with AAC as (main) encoding for the audio. AAC has a number of advantages over MP2 with repect to quality and density of the encoding, it has as disadvantage that it complicates the decoding process and its incompatibility: DAB+ data cannot be decoded with a first generation DAB receiver.
While the underlying technology for DAB and DAB+ is the same, the audio encoding of DAB+ is incompatible with the audio encoding for DAB. Modern implementations of DAB radio's (and DAB decoders like Qt-DAB, dabMini and QiRX) can handle both DAB and DAB+.
Different from e.g. AM and FM, and a big advantage of digital transmissions, is that more transmitters can transmit the DAB signal on the same frequency, in the same neighbourhood, a so-called Single Frequency Network (SFN). The transmitted digital signal is such that when a receiver receives signals from more than one transmission, it is able to "focus" on one of the signals and extract the data transmitted by that transmitter. So, rather than one large, heavy transmitter somewhere central to cover a large region or even a country, a whole range of small, lightweight transmitters can work on the same frequency to cover a large area. Sitting in my lazy chair, I receive DAB signals - using a simple whip -from 3 (sometimes 4) transmitters, all within a range of 10 to 15 km, most of them transmitting the same signal.
It is interesting to see what the effect of receiving multiple transmissions on the same frequency is though. The digital DAB signal is transmitted in "DAB frames" of 196608 * 1 / 2048000 seconds (since sampling is with 2048000 I/Q samples per second, a DAB frame takes 196608 samples). In such a "DAB frame", the first part, around 2600 samples, taking slightly more than one millisecond, is transmitted with an amplitude that is (almost) zero. The first data block following this NULL period, also with a suration of slightly more than 1 millisecond contains predefined data.
The "gap" and the predefined block of data make it easy to synchronize the receiver with the incoming datastream, and to determine the correction to be applied on the frequency (if any). Part of the synchronization is done by correlation. The correlation, as shown in the pictures above, shows the difference between handling the signal from a single receiver or the signal from multiple receivers. In the right picture one sees at least 3 peaks, meaning that from (at least) three transmitters data is received. From the correlation picture it can be deduced that the signal being handled, the one with the peak on sample 504, the second largets peak is around sample 465, since the samplerate is known, we can deduce that the difference in arrival time of these transmissions is around 20 micro seconds.
The accompanying spectra show that while the amplitudes of the transmitted signal are (more or less) constant (not taking into account the starting "gap"), the amplitudes shown in the spectrum when receiving more than one transmitter are essentially a mess. The way decoding works makes that even when the spectrum is as messy as shown, bits can be extracted with an accuracy, sufficient to have them translated to audio and data.
What is further interesting is that small clock errors in sampling do not invalidate the input. The spectrum scope as displayed with Qt-DAB shows - as one of the indicators - the offset of the number of samples, measured over 10 frames, i.e. 10 * 196608 minus the actual number of samples found. For simple SDR hardware - e.g. the RTLSDR based dabsticks - the offset per DAB frame can be well over 20 samples. Obviously, more expensive devices have more accurate clocks, e.g. for the SDRplay the offset is (almost) zero. The picture above shows the result of (a recording of) an RTLSDR stick, with 204 missing samples per 10 DAB frames (the number on the bottom line of the picture).
The (obvious) reason that even the offset as seen with RTLSDR sticks does not prohibit the software to do a good job in decoding is that the DAB data is encoded in the frequency domain, rather than directly from the samples (in the time domain). Since the contribution of an individual sample in the time domain contributes only a little to the data in the frequency domain, an offset of a few samples in data blocks of 2048 samples does not disturb the spectrum derived from the datablocks in a way that decoding is impossible. A few simple tests with Qt-DAB show that if the synchronization is off for even more than 100 samples, decoding is still possible.
DAB technology is also interesting from a software point of view. After all, all processing of the samples is done in software, and with 2048000 complex samples per second, with about 100 FFT transforms per second, with lots of viterbi decoding and Reed-Solomon error repair, and with a variety of different SDR devices to support, developing software provides lots of challenges.
Qt-DAB and its family are the result, they provide DAB (DAB+) decoding for a whole range of devices, and the architecture is such that additions and changes are made easily.
Currently Qt-DAB (and most of my other software) supports the devices as shown in the picture below. Top right a LimeSDR in a yellow enclosure, clockwise, the Adalm Pluto, two RSP devices (RSP II and Ia), the tiny RT2832 based "DAB" stick, the HackRF and the small (slightly older) AIRSPY.
Of course, Qt-DAB supports file input as well, both ".iq" (.raw) 8 bit files as generated by osmocom software, 16 bits ".sdr" file as generated by Qt-DAB and xml files are supported. (Qt-DAB further supports in input through an IP port, and, in a limited way support using Soapy and - for Windows - Extio interfaces.)
Qt-DAB is built from the perspective that the user is in full control: not only are there buttons on the GUI to show different displays, to scan, to select a device etc etc, the ".ini" file, i.e. the file where configuration data is stored, contains lots of settings for the user.
Lots of selections are possible, and to ease life, lots of selections are maintained between program invocations. As an example, the device, the channel and the program that were active when shutting down the program are stored and used as start up parameters. Presets are maintained between program invocations,
One of the recent additions is that the gain setting per channel is kept. Comes in handy when using the preset selection: when selecting a service in a different channel than the current one, the correct settings for the new channel are set automatically.
Another recent addition is color setting. I hestitated a long time before adding colors, after all, different people have different ideas about favorite colors. However, in the end colors were added to the buttons and the displays, in such a way that color setting and modification can be done from within the GUI, just by clicking with the right mouse button.
For those who want an idea on what can be received, the GUI contains a scan function that will scan the selected band (usually Band III, but user defined bands are also possible), and show (and save) data of all ensembles and services detected.
Of course, from time to time we do not need all the whistles and bells that Qt-DAB provides, we just want a list of services and the ability to select one. That is why dabMini was developed.
Already years ago, variants of Qt-DAB were developed with small, limited GUI's, dabradio and qml-dab being examples. However, while the software of Qt-DAB was (is) continuously improved, there was hardly any maintenance for the other software, and the organization in different repositories did not help either.
dabMini therefore is built on the same set of sources as Qt-DAB and is part of the same source tree as Qt-DAB. Any change in the non_GUI elements of the software of Qt-DAB therefore automatically applies to dabMini.
dabMini just provides a minimal GUI, device selection is automatic, next to service selection there are easy ways to iterate over the channels and the services. Of course dabMini supports presets, and a recent addition was a mute button, to stop any audio from eaching the soundcard for a given amount of time.
A third family member of the Qt-DAB family is dab-2. dab-2 is for me a vehicle to experiment. While most of its implementation is shared with the Qt-DAB program, there are some fundamental differences between Qt-DAB and dab-2. dab-2 is also part of the Qt-DAB sourcetree, dab-2 shares its GUI with that of Qt-DAB, the widgets for the devices differ though.
It took a while, but I found time to write a pretty complete user's guide. That guide not only contains a detailed description of the widgets in the GUI, it contains a description of the possible (few) command line parameters and a detailed description of the - possible user's - settings in the ".ini" file. It further contains a detailed description of how to configure and create an executable, how to add a device and - last but not least - a description of the mini version of Qt-DAB, i.e. dabMini and how to build an executable for it.
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.
Obviously there exist an almost infinite amount of other devices, the way Qt-DAB is built makes it pretty easy to add support for an other device. A well-defined interface exists that any device handler should implement, the user's guide contains a section describing in detail what functions must be implemented and what files need to be adapted and how to modify the configuration parameters. Anyone is invited to add another device to the list of supported devices.
While Qt-DAB (still) provides the opportunity to dump the incoming data in a PCM formatted file (2 channels, 16 bit integer, 2048000 rate), and - obviously - is able to process that data as well as 8 bit "raw" files, an addition is made to support "xml files"
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 in Qt-DAB 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.
While Qt-DAB now offers the opportunity to scan the band and save a description of the ensembles and services found in a file, 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 and the Adalm Pluto. 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.
One of the example programs is a command line version of a DAB scanner, it will scan the band and save the results of the scan in a (specified) file.
Example program 2 supports the same set of devices as Qt-DAB. Other example programs (after all, they are just examples) most of the basic ones, like the SDRplay and the RTLSDR sticks.
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 Adalm Pluto, 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 Adakm Pluto, 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 (as well as a script to build an executable).
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 and outdated - 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 is a user's guide and 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, etc etc, 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 fit your purposes,
it might just not be the software you are looking for,
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 available, to Great Scott Gadgets for making an HACKRF device available, to Robin Getz (Analog Devices) for making an Adalm Pluto device available and to Jan Willem Michels for making an LimeSDR device available.
Pijnacker, September 2020
Jan van Katwijk
Lazy Chair Computing