Digital Radio is now all around us. Our local TV provider recently stopped passing on analog stations over the cable. The medium wave band does not contain a single country wide transmitter anymore, and even the short waves are emptier than a decade ago.
FM is still in the air, however, there seem to be plans to stop that in around 2023, so all that remains is either internet or digital radio (of course Internet, WiFi etc is digital as well).
Digital Radio, the foreseen replacement, differs from the "old forms" in that the content of the signal is digital, a stream of bits, to be decoded and converted into audio, text or video. Of course, the "radio waves" themselves are analog as usual, it is the contents that is treated differently.
My second radio (the first one was a crystal receiver) had a real valve (a DL92) and was built around the famous AMROH 402 coil, and I enjoyed listening to the radio stations on the MW. Just a few meters of copperwire as antenna, headphones (2000 Ohm in those days), and a few batteries, were sufficient to bring the world in and - late at night, head under the blankets - listen to famous stations as Radio Luxemburg and Radio Veronica, instead of making homework. Nowadays, one needs both a "receiver" and software for anything more complex than FM (without rds).
The standard approach to play with what is called "software defined radio" is to have some hardware device receiving the signal from the antenna and converting it to a stream of bits, and a processing device for the decoding.
There is a myriad of devices, translating what comes in to samples, the cheapest being the "dabsticks", price around 10-20 Euro while the USRP B210 Board van Ettus research is with a price of 1210 dollar at the other side of the spectrum. In the range between, there are happily many others.
I am the happy owner of SDRplay, Hackrf, RT2832 based DABsticks and AIRspy devices, more than enough to keep me busy (well, and in case I still get bored I do have an old pmSDR device, a device where one still needs a soundcard to get the data "in").
The HACKrf starts at 1 Mhz, so that is also usable on shortwave, and as a special feature, it supports both reception and transmission on frequencies to 6 GHz. Other devices support frequencies between say 50 Mhz and 2000 Mhz, bands with interesting broadcasts and service transmissions.
A limitation on the AIRspy is that it only provides a limited number of sample rates (high though). For e.g. DAB decoding rate conversion is required.
DABsticks have the advantage that they are cheap and there is a tremendous amount of software for these devices. Depending on the model, the range is somewhere around 24 MHz to well over 1.5 GHz.
The SDRplay device has the advantage of supporting a frequency range starting at less than 100 kHz without having to perform tricks, the device supports the whole range from less than 100 KHz to 2 GHz. On medium and shortwave it is the device of choice.
One important difference between the devices is in the number of output bits, while DABsticks and HACKrf deliver I/Q samples of 8 bits, the SDRplay delivers 12 to 14 bits I/Q samples (depending on the chosen model).
Stability of the oscillator is obviously also pretty important, although the DAB program (and the DRM decoder) manage to deal with offsets to up to 25 to 35 Khz. The frequency error with the SDRplay, the AIRspy and the HACKrf is negligible, the cheap DAB sticks suffer from offsets to 20 a 30 Khz at 200 MHz and the offset varies with climate conditions.
There is an enormous amount of software already available for SDR applications, For me, it is just fun, however, to write and develop my own programs for this domain. One of the major gains in writing one's own software is (given that one has a sufficient amount of time since it requires lots of code) that it really deepens the understanding of elements in the domain and it definitely contributes to the further development of one's programming skills.
After retirement, I actually did have spare time to sit in my lazy chair with a laptop on my knees. Starting with an "Elektor" card (from the Elektor magazine) as "hardware" device, where the output went into the soundcard (at those days, laptops still had embedded soundcards with a "line-in"), it did not took too long before I could listen to AM stations.
After that, RTTY decoding seemed the ultimate goal. However, that turned out to be reasonably simple, so it was followed by a (q|b)psk decoder and a CW decoder. Then a whole series of other decoders, complete and partial, followed. Of course the "Elektor" card was a simple device, tuning above 20 Mhz was rather inaccurate, but at the time I really enjoyed it. Later versions of the software supported more devices and other decoders, including one for the digital radio of the shortwaves, DRM. The current version supports about 8 different decoders, under which a DRM decoder (and a cw decoder as shown on the picture) and can be used in connection with the SDRplay, the HACKrf device, DABsticks (for RT820 based sticks a library is part of the source tree with which one can tune as low as 13 MHz), and the good old pmSDR (with a soundcard). For details on the swreceiver, see "https://github.com/JvanKatwijk/swradio-8".
After the "Elektor" card, I acquired a pmSDR. The pmSDRdr was a very nice device, while the oscillator runs from 0 .. 55 MHz, using the third harmonic one gets a frequency range to over 150MHz. The device is "old-fashioned" in that the output is still analog and a soundcard is needed to do the ad conversion, but still very usable.
With the pmSDR, it was very tempting to investigate the FM broadcast band, and indeed, inspired by some pieces of example code, found on the almighty internet, an FM receiver could be realized. The design was made such that interfacing with other devices would not be too compilated: separation of the input device from the processing chain. Later on, other devices, SDRplay, AIRspy, DABsticks and HACKrf were added.
The current version has a wealth of buttons and sliders, one may choose from a collection of 5 different implementations of the FM decoder. Of course rds is implemented and one may scan over a user selected band. A simpler version exists as well, WFM-RPI. For further info see "https://github.com/JvanKatwijk/sdr-j-fm" and "https://github.com/JvanKatwijk/wfm-rpi".
Around the time I was working on a FM decoder, DABsticks were arriving. The DABsticks, with a frequency range of 24 MHz - 1700MHz, were cheap and available. The bandwidth, up to nearly 3Mhz, made it possible to look at a whole band on a single screen. For that purpose a spectrumviewer was developed, later on further developed into one as in the picture.
The program in its current setup shows two main windows and a small one. The main windows show the spectrum of the incoming data, as spectrum and as waterfall. Of course many details are invisible when looking at a 15 inch screen to a spectrum with a width of say 10 Mhz. Therefore a third, small window was added showing an enlarged small part of the while spectrum. For more info see "https://github.com/JvanKatwijk/sdr-j-spectrumviewer".
One of the challenges, after having played with FM, was to look into DAB decoding. DAB, Digital Audio Broadcasting, is slowly taking over Europe and some other continents. Some countries announced that DAB (or DAB+) will replace FM, so it seems that after the demise of the AM, the FM will eventually be phased out.
The coverage of DAB is pretty good, here, in the Netherlands, we receive with a single telescope antenna 3 to 4 ensembles, with around 45 services. While the content does not necessarily makes me happy, the techniques used are really interesting. After all, Digital Radio requires a fair amount of computing, so for a real programmer these is lots of work and a reasonable laptop is absolutely necessary.
I made a few different versions of a DAB decoder, to be used with SDRplay, AIRspy, DABSticks, HACKrf devices (and file input for testing purposes). The main version is Qt-DAB, it supports a range of devices and has a range of options and sliders. A variant is sdrplayDab, a version optimized for use with the SDRplay, which is shown in the picture. For more info, see "https://github.com/JvanKatwijk/qt-dab", "https://github.com/JvanKatwijk/sdrplayDab" or "https://github.com/JvanKatwijk/dabradio".
I myself am mostly using the dabserver, a variant running on an RPI3 as "service", controlled from my tablet, using a bluetooth connection.
The "server" version is an offspring from the project dab-cmdline (see "https://github.com/JvanKatwijk/dab-cmdline"). In this dab-cmdline project, the functionality for DAB decoding is implemented in the form of a library, and a number of example programs is given, each leading to a cmd-line driven version of the DAB decoder.
In this dab-server (see "https://github.com/JvanKatwijk/dab-server") the server program is running as a Linux service on an RPI2/3 (one with bluetooth support). The server is configured as a "service", i.e. on system startup, the program will start. A client, a remote control is written in Java, for use on either a 10 inch or 5 inch Android tablet. This client contains buttons to select a service, to have the server execute a new scan over all channels and to control the sound level. (GUI design is not my favorite hobby, and it is obvious that it does need some additional attention.)
One of the nice features (at least that is what I think) is that the server does not need a WiFi connection and runs unattended, i.e. it continues to do whatever it did after stopping the controlling client program. After (re)starting the controlling client program and connecting with the server, the server will send some information so that the client can show the actual program information on its screen, and another service can be selected, if so desired.
While my development platform is Linux, it is clear that for programs to be useful, they are preferably available for Windows as well. Happily, the Linux platform I am on, fully supports the mingw32 cross compiler environment, so it was/is relatively easy to cross compile all software and make it available under Windows.
For all this software, sources are available from github in the various github projects.
the qt-dab respository contains in its releases section a zipped windows folder (windows-bin.zip) with quite a few Windows executables (together with libraries that are required).
Furthermore, for the programs mentioned above, a Windows installer is available in the releases section of the project. Such an installer will install the executable and the required dll's. The installer will install the dll's for the SDRplay as well, of course, if not installed already.
To overcome the problem of differences in different Linux distributions for PC's, for some of the programs, AppImages are made. An AppImage is a file containing the executable and most of the required dynamic link libraries (see "https://github.com/AppImage" for details). The basic idea is that such a file is downloaded, the exec bit is set and the program can run.
The RPI (2 and up) are popular devices, and since "Stretch" is a real and full Linux distro, it is straightforward to build an executable for the above mentioned programs on such a device. From time to time I create an AppImage for Qt-DAB for Stretch on the RPI2/3.
A description of the full set of programs is quite lengthy and the programs are quite different, that is why one just might select a description. For each of the programs it holds that there are sources available for use under Linux, and for many of them precompiled executables are available for use under Windows.
DAB is being pushed as the replacement of FM broadcast, it operates in most countries in the "old" TV Band III (somewhere between 170 and 230 Mhz). In my local environment I receive - with an indoor telescope antenna - 4 ensembles with over 40 services (most of them for me not worth listening though). From a technical point of view, DAB, being digital radio, is quite interesting and I made different versions of a DAB decoding program, three with, others without a GUI. In this section the programs with GUI are described.
The picture on the left, dabradio is the simple version, just start the program, select a service and listen. The one on the middle, Qt-DAB, is the most extended one, and the picture shows that the HACKrf device is used as input device. The one on the right, sdrplayDab, is similar to Qt-DAB, but for use solely with SDRplay devices.
The first two programs support - if so configured - the SDRplay, the AIRspy and rtlsdr based DABsticks as input device. As the picture shows, the Qt-DAB program can be configured to accept input from an HACKRF device and furthermore, it is standard configured for input from a file, both a "raw" file (".iq" or ".raw", 8 bit I/Q samples) as produced by e.g. osmocom tools or an "sdr" file (a ".wav" file) generated by the Qt-DAB program.
The sdrplayDab program also takes ".sdr" files as input, however, due to a different architecture of the front end, only those generated by the sdrplayDab program itself.
For Qt-DAB and dabradio so-called AppImages are available as well. For such an AppImage to run, one should have the library for the device of choice installed (most modern distros do have the rtlsdr library in the repositories, the driver for the SDRplay devices can be downloaded from SDRplay.com), the AppImage itself contains all further dependencies. Running is then simply setting the exec bit on the AppImage and executing the file.
For Windows, a "zip-file" (windows-bin.zip) is available, a folder compressed in "zip" format, with the executables of these (and other) programs and the required DLL's.
This windows-bin.zip file and an AppImage for Qt-DAB are available in the releases section of the Qt-DAB repository.
An Appimage for dabradio is available in the repository (releases) section of the dabradio repository. The Windows executable of dabradio is in the aforementioned zipped folder.
The Windows version provides additional support for selected devices with an Extio plugin dll, tested with plugins for the SDRPlay and rtlsdr based DABsticks.
The main differences between the various versions is the amount of buttons and selectors. By dabradio there are only a few, Qt-DAB has an abundant amount with which selections can be made and aspects of the signal can be made visible. Things like TII recognition are implemented in Qt-DAB (and sdrplayDab), but missing is dabradio. The same for showing a spectrum.
Just as a programming exercise - and to (re-)gain some experience with the languages - the core of the C++ implementation was recoded in both Ada and Java. Both implementations are functioning and provide more or less the same functionality as dabradio. Both programs make use of a number of "native" (i.e. "C") libraries. gnat, the compiler used for the Ada version, is part of the gcc ecosystem, making it relatively easy to bind to C libraries, in Java it is more complex - and it is far less portable - to handle "native" libraries.
While both programs are functioning, making them was merely an exercise and the programs are not actively maintained. Feel free to adapt, modify and extend. A reasonably extended implementation description of ada-dab is contained in the repository.
In order to create a command line version for DAB processing, a library was created with entries to the functionality to process DAB and DAB+. The sources can be compiled into a shareable library, or they can be included in an application. The sources for the library, as well as the sources for a number of example programs are to be found in the github repository here.
Examples of the use of this library, some (sources for) example programs are provided for in subdirectories (each directory contains a CMakeLists.txt file that can be used to create an executable).
Example 1 implements a simple command line version, using a precompiled library. In the configuration phase one has to select the device to be used;
Example 2 implements a simple command line version, using the sources of the library. In the configuration phase one has to select the device to be used;
Example 3 is based on example 2, it differs from example 2 in that the PCM output is now being sent to stdout rather than using portaudio to control a soundcard;
Example 4 is based on example 2, it differs from example 2 in that the raw MP2 or aac data (depending on the service selected) is being sent to stdout rather than to an MP2 resp. AAC decoder;
Example 5 implements the functionality of example 2, with as addition the possibility of selecting the "next" service in the channel;
Example 6 implements a version with an internet interface. Commands to select a channel, set the gain of the device (on a scale from 1 .. 100) and select a service can be given through an IP port, some data (i.e. the names of the services in an ensemble) are passed back. The code for the example contains a "mini" client implemented using Qt.
Example 7 implements a version similar to example 3, the difference being that rather than selecting an input channel, the input is assumed to arrive through stdin.
Example 10 is special in that it was not developed by me and aims at obtaining some technical information from the receiving channel.
The Python example implements a simple command line version using Python 3, is however obsolete A Python API layer is created implementing a library with a Python binding to DAB handling functionality. This Python API together with the library sources are made into a separately compiled library and references from with the Python program.
The dab-scanner example implements a simple scanner over the selected band (default Band III). It collects the data of the ensembles and the services and prints that out, if selected to a file, otherwise to stderr. The resulting file can be viewed in e.g. LibreOffice Calc.
A typical command line for e.g. the Example 2 program, configured to run with an SDRplay device is
./linux/dab-sdrplay-2 -M 1 -B "BAND III" -C 12C -P "Radio 4" -G 40 -A default
In this example Mode 1 is selected explicitly, which happens to be the default one. VHF Band III is selected, which also happens to be the default one, channel 12 C is selected, and in that channel the program "Radio 4". The Gain for the input device is set to 40 (on a scale from 1 .. 100), and as output device "default" is chosen (which, almost obviously, happens to be the default one).
The example programs - although all functioning quite well - are merely meant to show the usage of the library (or its sources) and are hopefully a source of inspiration, rather than complete implementations. Use your own imagination to adapt and extend.
The way I am working makes it quite inconvenient to run the DAB software for listening to e.g. music, on the same laptop where I am programming and doing other things. For e.g. testing I often switch to another OS (even Windows sometimes), which means that the DAB decoder stops. The same applies when running the DAB software on an RPI, since my RPI's are headless, they are controlled through a WiFi connection, which - obviously - disconnects when switching the OS.
Therefore the idea was born to run the DAB program as an autonomous service on the RPI, i.e. without having to be connected always. Since all laptops and tablets (phones) do have bluetooth, and the RPI does as well, it seems logical to investigate the possibility of using a bluetooth connection to control a server, running on an RPI.
The bluez library helps, and the sources in the dab-cmdline project were a good base to create a stand-alone server in just a few days.
Communication protocol between server and (potential) client should be easy. Assuming the server "runs", it can get one of a few commands, i.e. to scan the band for stations, to select a service, to regulate the gain setting for the radio device and to regulate the sound level. Since, however, the server may run on an RPI without even WiFi connected, there should be a command to stop the whole system as well, after all in general it is not recommended to switch off the power with a running system.
As a programming exercise a simple client was written, in Java, for use on an android tablet. In the current form, two versions exist, one for 10 inch tablets (I use one), and one for 5 inch tablets (only tested with an emulator). It goes without saying that the GUI of the client needs further development, "we are working on it".
Both versions of the client (better: remote control) share the same layout.
A button start to setup the connection, after touching, the client will search for bluetooth devices in the environment;
A button reset to command the server to scan or rescan the band and build up a list of services;
A button quit to stop the local client. The server will just continue;
Two sliders, one to regulate the loudness setting of the output, the other one - depending on the radio device attached to the RPI - for regulating the gainsetting;
For e.g. the SDRplay a spinbox for setting the lnastate;
Once connected, a list of services detected by the server will show. Touching a service name will instruct the server to tune to the right channel and to sekect the service;
A large grey box, when touched it will instruct the server to close down the RPI orderly.
The swradio-8 program is used to "listen" to frequencies on the "shortwave" bands, it takes the SDRplay (all models) as input device and it implements half a dozen decoders. While there are no decoders specific to signals in the higher bands the covered frequency range is only determined by the device and with the SDRplay allows access to frequencies up to 2 GHz.
The software is a (partial) rewrite and simplification of the sdr-j-sw software, the latter, still available on github, supports more decoders and input devices than this one, but is more complex to build and to use.
The swradio-8 assumes that the interesting signals are small-band. The inputrate of the SDRplay is set to just over 2M, and decimated (and filtered) to a rate of 96000. A reasonable amount of filtering is done using an fft implementation of a FIR filter. The software will then select a band with a width of 12K, based on the user's frequency selection, and filter it out and decimate the samplerate to 12K. The user then can select a subband (usb, lsb, AM, wide) to be send to the selected decoder, the decoder will - if required - do further filtering. The function of the main program is limited: it collects data, filters, decimates, if required applies AGC, and then passes the result on to the selected decoder, if any.
Looking at the internet, there is a tremendous amount of interesting modes for shortwave and amateur transmissions. We restrict ourselves to those modes that we actully could receive:
The bandwidth for the decoder can be set to AM (9 kHz), wide, for DRM (12 kHz), USB (2.5 kHz) or LSB (2.5 kHz). Using the right mouse button on any of the two "scopes", the view is switched between "spectrum view" and "waterfall view".
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, the coastguard sends regularly messages in Amtor format on 518 Khz.
DRM transmissions are rather scarce unfortunately, the transmissions of Kuwait and Nigeria are well received here. DRM, mode B, is a very interesting technique, however, in Europe it is almost dead. In other parts of the world, e.g. India, is is quite poplar though.
For short wave reception I use an "in house" loop antenna with a simple amplifier, a balanced one, (see e.g. "http://www.pa1m.nl/pa1m/simple-active-receive-loop/"), which performs reasonable well with a loop of 4 times 1.5 meters.
To aid in finetuning for psk decoding and cw decoding, the control widget for those decoders show as waterfall a very small band around the received frequency. Correction of the frequency is possible by clicking the mouse on this "waterfall" widget. It turns out that tuning to an accuracy of one or two Hz, as required for decoding e.g. qpsk, is easily possible.
A program list is maintained between program invocations, selecting a program on the list is just by clicking the mouse on the selected program. The GUI contains a button with which a frequency can be saved and stored in the list. The main GUI contains a button for storing the currently selected frequency in this program list.
For use under Linux, one might want to download an AppImage from the releases section in this repository from github. The AppImage is "ready to run" (after downloading and setting the exec bit of course), one only needs to have installed the support library for the SDRplay (the library can be downloaded from SDRplay.com).
The README in the repository is quite extended.
The implementation of the DRM decoder depends on the use of a special version of the faad library, since faad 2.8 this specialized version is standard available.
For windows an installer is available in the releases section of the github repository.
The WFM-RPI software is the implementation of a simple (W)FM decoder, compiled for use with radio devices as SDRplay, AIRspy and/or DABsticks (depending on the configuration). The software runs under Windows (precompiled version configured for all three devices mentioned) and under Linux. The sources are to be found on the github repository.
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 program list, a list of known programs with their frequencies, is maintained between invocations.
Tooltips tell the function of the various buttons and sliders.
The more general sdr-j-fm software contains more elements, the GUI shows the spectrum of the incoming signal as well as the spectrum of the decoded signal.
This version supports - under Linux - next to the SDRPlay, the AIRspy, DABsticks, HACKrf and a soundcard, the sw-elad-s1, to be used with a downconverter. Note that the program is - especially when running Windows - quite resource hungry.
The sources can be downloaded from github . In the releases section of that repository one will find a Windows installer.
For experimental purposes a simple command line based version of the FM software was created. The software sends it output to stdout or to a selected file, rather than to a soundcard. It can be used e.g. to listen to mono or stereo transmissions, or to see what is happening on the P2000 band on 169650 kHz. It is modelled after the - excellent - fm software in the osmocon site for DABsticks.
sdrplay_radio -f 169650000 [-p3] |multimon-ng -a FLEX -t raw /dev/stdin
To listen to an FM transmission (the only classical station in the Netherlands on FM)
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 at the github repository . An executable can be configured with either an AIRspy or an SDRplay device as "radio" device.
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.
Yhe 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.
The popular dump1090 software (Copyrights Salvatore Sanfilipo) to keep track on planes is tightly integrated with software for rtlsdr devices and lacks support for the SDRplay and the HACKRF devices. So, some reconstruction was done to create a separation between "device" and "algorithm", and at the same time a kind of GUI was added.
The current version is 0.8: while it is definitely running, it is still an experimental version and does not have all of its final functionality. In the aforementioned windows-bin.zip zipped folder, a windows version is included.
Unfortunately, it seems that the free access to the maps API is restricted and - since end of june 2018 - one needs to register and - in some cases - one seems to have to pay for the usage of the API.
The sources, for compilation under Linux, are in their own repository . In the configuration file, qt-1090.pro, one can select or deselect the devices supported. The program, when started, will sequence through a (short) list to open one of the configured devices.
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).
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, rtl_433 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.
Modern radio devices deliver a wideband signal (e.g. the SDRplay up to 10 Mhz, the hackrf to up to 20Mhz). While it is nice to be able to show the spectrum of e.g. half the FM broadcast band in a single view, for decoding a dignal a smaller band is usually needed. As an example, the band width for decoding a psk31 mode signal or a cw signal is less than 100 Hz. The sw software takes as input from the SDRplay a signal with a width of just over 2 MHz (the smallest possible), and (filters and) decimates that to 96 Khz. Then, depending on the user selected frequency, a subband of 12 Khz is selected (and filtered out) and made available for decoding at a rate of 12 Khz. The user may select a subband of 12, 9, 2.5 Khz (upper or lower sideband) to be handled by the decoder. The latter will further filter the signal as required.
All these filterings are done by Finite Impulse Response filters, some with a pretty high degree to obtain steep flanks (a degree of 255 is no exception, although then implemented using a FFT). FIR is chosen over IIR since FIR does not destroy the phase of the signal.
The pictures all show a filter with a degree 64 and a width of 0.33 (in the range 0 .. 100, i.e. for a signal with a sampling rate of 96000, this would mean 0.33 * 96000 / 2, i.e. 16Khz). So the pictures show a low pass filter with a 3DB point at 16 Khz. The pictures differ in the windowing applied.
The sources of the program can be found in the github repository .
Since my interest is primarily in programming, I'm less 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 and an example of such a command line.
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.
A description - also informal - of processing of DAB and DAB+, as implemented in the Ada version of the software, is given here. This (also eternal draft) report describes in quite 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 and DAB+. It is slightly outdated, some algorithms in the regular DAB implementations are replaced by more efficient ones.
For those interested in really old stuff that has nothing to do with Software Defined radio, but 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. 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.
This software depends on existing dynamic libraries (linux) and dll's (windows), e.g. libraries for audio output, fft, handling "wav" files, all available under a GPL-V2 or V3. So the software is itself also made available under a GPL-V2 licence.
It is - obviously - nice if (some of) this software is useful, feel free
to use it and enjoy. There are no warrantees, however,
and if the software does not do
what you expect it to do, I suggest you read the documentation first before
complaining to me.
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.
Suggestions for improving and/or extending the software 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, 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 and Great Scott Gadgets for making an HACKRF device available to me.
Pijnacker, February 2019
Jan van Katwijk
Lazy Chair Computing