SDR++ Version 1.0.0 Released
SDR++ is an open source, cross platform, C++ based GUI general receiver program for various SDRs including the RTL-SDR. Since it's alpha release in mid 2020, it has undergone huge amount of development, and is quickly becoming the main program of choice for many users due to it's efficiency, cross platform and multi-SDR hardware support and increasing feature set. And with an easy GUI very similar to that of SDR#, it's easy for most users to learn.
Recently version 1.0.0 of the SDR++ software has recently been released. This is the first non-beta stable version, so represents a major milestone in development. Over on Reddit programmer u/xX_WhatsTheGeek_Xx summarizes the latest developments.
After over a year of work, I'm proud to released version 1.0.0 of SDR++!
For those who don't know, SDR++ is a crossplatform (Windows, Linux, MacOS, BSD) and open-source (https://github.com/AlexandreRouma/SDRPlusPlus/releases) general purpose receiver software meant to be simple and easy to use. It has advances features like multi-vfo and uses a fully custom DSP making it very efficient.
Here are the following additions compared to the last version:
- Support for the SpyServer protocol
- Support for all SDRplay devices
- Support for all BladeRF devices
- Support for all LimeSDR devices
- Optional IQ correction
- Optional Decimation
- Broadcast FM Stereo
- Frequency manager to create lists of frequency and optionally display them directly on the FFT/Waterfall
- Network sink to stream the audio output via TCP or UDP
- Options to set the FFT framerate, FFT size and FFT window.
- Theming with Dark and Light themes supplied by default
- RigCTL server module to control SDR++ from, for example, gpredict.
- A bunch of keyboard shortcuts (see wiki on the github page)
- SNR meter
- More info when hovering a VFO
- Colored VFOs to easily identify which is which at a glance
- Meteor M2 demodulator compatible with LRPTOfflineDecoder and Satdump
- Ability to resize VFOs by directly dragging the sides on the FFT and waterfall
- Module manager to easily add or remove any module on the fly without having to restart or edit the config manually
- File dialogs to select directories in the recorder or files in the file source (instead of having to type in the path)
- Ability to disable modules that support it (Radio and Meteor M2 demodulator) with one click (to save CPU power or just if they're not needed)
- Lots of performance improvements
- Ludicrous amounts of bugfix :)
I'd like to thank the many contributors, patrons and companies (SDRplay, Airspy, Nuand, LimeMicro) who helped make this project possible!
If you have any issue with the software, please open a github issue or contact me directly on the SDR++ discord (see readme on github)
I hope this software comes in useful to at least some of you ;)
We also wanted to highlight the fact that SDR++ runs smoothly with about 50% CPU usage on a Raspberry Pi 4 with an RTL-SDR.
Also according to @cemaxecuter who created DragonOS, if rtaudio is installed on Linux , then an easy to use virtual audio sink becomes usable from SDR++, allowing audio to be easily passed to other programs such as WSJT-X just like on Windows.
A ready to use zip file for Windows is available on the GitHub Releases page, as well as amd64 .deb and .pkg install files for Ubuntu, Debian and MacOS systems. For other systems the compilation instructions are available on the readme or Git main page.
I got it (v1.1.0) working on my Galaxy A50 right away. Great to have this for my broadcast stations. Can’t get the Frequency Selector and SNR Meter to show on the top bar.
well, this sounds like a good software package. However, like many other SDR packages, I won’t know if it works until I install it. Many other packages I have tried on OS X Catalina often don’t work with VoiceOver. Since I am totally blind and still want to listen to radio/ SWL/VHF/UHF/SHF/low microwave and have access to trunking, I need either accessibility built in or a plugin. recent developments at SDR# have an experimental accessibility plugin that seems to work on windows, but I prefer to use my Mac and haven’t found anything yet that supports accessibility. so, after I post this, I will install the software package for OS X and “see” what comes up. I will file further comment if it does work. I have two RTL/SDR units (one with a sub 25mhz add-on) and an Airspy discovery and an R2 with the “Spyverter” option.
I hope this works, because my old win7 laptop is getting rather long in the tooth and I would rather run my OS X box.
If you could add RDS support for FM this software would be great.
I like the program, it’s running smooth.The only thing i miss when i’m listening to fm radio stations is stereo.
Hi and thanks for a nice program. I have encountered a problem on Ubuntu, please read on:
I have 2 SDR receivers, a HachRF one and a simple DVB-TV (Bases on RTL).
In Windows 11, both receivers are working fine, but on Ubuntu 20.04LTS (fresh installed) the HackRF one does not work.
It terminates with the message (seen in terminal when starting sdrpp from there):
28553 segmentation fault (core dumped) sdrpp
I have also Gqrx installed and it works fine with HackRF one.
Best regards, Brian
Have problems on Windows systems while starting the SDR++ on some machines. A short splash screen and nothing.It looks like the software is missing something, libraries maybe, which is not installed on some PC’s.
On other PC’s I use it regularly without any problem.
Just extract in any directory and start, is not working on all Windows systems. What could be the missing dependencies?
I hope freqency manager to support UNICODE.
I am using Your APP to satellite monitoring I am having some problems with decoding signals.
The problem is that the bandwith is too narrow for USB modulation, the old sdr# versions had 16kHz, the newer ones don’t have any limitations in FM and SSB. I would like to ask is it possible to increase this width for FM and SSB in SDR ++?
The new SDR++ v1.0.3 runs great on Kubuntu 21.04 GNU/Linux. My move to Linux is now fully complete. I am not using Windows at all anymore.
I did have to do a few minor things after installing SDR++ to get it going:
1) Open Kate text editor.
2) Copy/Paste the following 3 blacklist lines below into it:
3) Click SAVE AS, browse to the /etc/modprobe.d folder, and save the file as no-rtl.conf within that folder.
4) Uninstall soapy in Terminal with sudo apt remove soapy* as SDR++ keep stalling on it when opening.
5) Reboot computer.
A Frequency Manager scanner is in the works 🙂
Installed from the .deb files, then tried building from source. Still had one annoying problem.
I’m running POP! OS on a system76 laptop. Based on Ubuntu 20.04.
The program runs and talks to my Airspy HF+ Discovery just fine. However, only in about 1 out of 7 tries, the audio is fine. The rest of the time it stutters and fills the terminal with ‘audio write error: buffer underrun’.
Also, It lists 15 versions of my audio device, but reports the device is in use. I have to select ‘default’ at the bottom of the list to get audio.
Even when the audio is clean, if I change the frequency by more than a few KHz, it will start stuttering and giving the buffer underrun errors again.
I had audio stuttering problems with Lubuntu 20.04LTS and applied the solution mentioned under this discussion in GitHub:
“Linux Mint Audio Fix when self building #112”
Konradrundfunk’s solution fixed my problem.
I enjoy your YouTube videos.
Regards, Ian, Dorset, UK.
Hi Ian, yep, I found the solution too. Thanks for watching! I’ll be doing a vid on this software when I get back from my little break.
Please add an Omni Rig plugin. That would make this gold.
is this only windows 64 bits compitable?
Just came from the Github page and by the look of it there’s no Mac version that I can see. Just the word TODO (to do?) listed under Mac. Pity…
If you go to the releases link click on the Assets. There is a .pkg for MacOS.
No. Linux – including Raspberry Pi OS, see below – and Mac OS, too.
Sorry, wrong place. Should be a reply to swl’s question.
Go to Discussion #39 “Debian 10.7 (buster 2020-12-05) works, but hit a few issues along the way #39”
in the SDRPlusPlus Github by Alexandre.
I got a replay from him today.
May be it helps because I saw exactly that error message you get.
I just want to say that, you have got me back into radio as a kid in the 80’s i was into CB and in the 90’s i was into scanners, then the internet was born and the scanner was put to bed, 40 years on i have started with the SDR and got a Hackrf
Cant wait to see an HACS integration for Home Assistent for this. Hope this wont take ages.
limesdr mini crashes when turned on, does not work. windows 10
..still waiting for detailed installation instruction under Raspberry Pi. I found them really confused 😓.
I have to agree. The existing Debian Buster release is only for AMD64 chips. I have a RPi 3B+ which is ARM32 chip. So, I guess you could try to build everything from the src files but that could take a lot more linux knowledge than I have anymore (stopped coding many years ago).
If someone could do a step by step for Buster on RPi 3B+ and earlier, it would be a real help for many of us.
As a user of the BladeRF 2.0 – amongst others SDR’s – I am pleased to see a new interface that supports the device out of the box.
I Installed it and it ran without a hitch and within a few minutes I was using the Blade in all it’s glory.
On first inpressions this appears to be an excellent piece of software both in terms of performance and a clear representation of visual information.
What a fascinating tier of Radio SDR has turned out to be, with all this fantastic hardware and now software.
Congratulations to all involved on this project, we in the community live for this type of acheivement.
If you need to run SDR# on MacOS, before downloading .pkg file from github, you need to install following packages: glfw, volk, portaudio (I used Homebrew). Under BigSur it works perfectly 🙂
Where does the .pkg file install the app? I am unable to find it.
Did Lusa really mean “SDR#” .pkg files for MacOS? Or it should read “SDr++”? The latter’s binaries from the “nigthly builds” section on Github can indeed be installed on x86 Macs. While M1-2 machines still need building from source after dependencies are installed, f.i. with Homebrew.
In core/src/core.cpp at line 276, change to
const char* glsl_version = “#version 300 es”;
Thanks a lot , Tim. SDR++ works now on my Raspberry 4.
Here is a short summary of what I did to get SDR++ running on a raspi: I took a fresh Raspberry Pi OS (to avoid the hash collision problem, see Alexandre’s readme, https://github.com/AlexandreRouma/SDRPlusPlus). First, I added cmake via apt install and then downloaded the programm code from the github mentioned. Then I did the changes Tim suggested and installed all the programs/drivers according to the first (!) line “sudo apt install libfftw3-dev …” under “Installing”, “Linux” and “Debian based ..”. Do not try to install the deb package (see second line) as it won’t work with a raspberry. From here on I followed Alexandre’s guide under “Building on Linux” , “Building” in the readme. cmake complained about two missing programs – librtlsdr-dev and libairspy-dev – which have to be installed manually via apt install before making the software. That’s it. I did just a short test with my AirspyHF+ discovery. Everything seems to work.
I could compile SDR++ on my Raspberry 4. Just had to add two dependencies. I can’t run the program, however. The error message is “Glfw Error 65543: GLX: Failed to create context: GLXBadFBConfig”. What did you do to get it working?
Program crashes when I start it.
Trying to figure out where to find help. When starting the program it crashes and the event log says it is a problem with ucrtbase.dll
Tried to find a solution, a brother of mine has no issues but his ucrtbase version has a newer time/date but same version (and don’t know how to replace the dll)
I’ve had sdrpp working on Windows 10 for several months. Yesterday I tried running it and it shut down immediately after starting. The error log showed a problem with the ucrtbase.dll. I tried removing and reinstalling sdrpp, reinstalled all of the Windows Visual C++ vcredist run-times (sometimes related to ucrtbase.dll), and even recompiled and reinstalled RtAudio. Nothing worked. I noticed when I deleted the rtaudio.dll file from the sdrpp folder, the program would function correctly, albeit without an audio sink.
I eventually checked the Windows Sound Control, and changed the default device for Windows audio playback. After doing that, sdrpp would work fine with audio sink selectable. It appears there was some conflict occurring between the sdrpp audio sink and the Windows default playback device that resulted in the ucrtbase error. If you have any virtual audio cable programs installed, try changing the default Windows playback device to see if it rectifies your problem.
At first I was sceptical, if it was worth all of this effort, just to produce a much less featured version of SDR#.
However on loading it up, I quickly changed my opinion.
What a joy, a nice clean simple interface, like SDR# used to be, before all the bells and whistles were added.
The application opens almost immediately, and when you just want a quick simple SDR receiver that works, everything there where you need it.
What’s even better is that it’s cross platform, so can run on Linux boxes too.
Well done, but please don’t ever be tempted let it turn into over-featured bloatware.