Need some help with Airspy + OpenwebRX (DD5JFK fork) #openwebrx


Hi All, 

I try to get my Airspy R2 to work with the openwebRX fork from Jakob but without any luck. Can you guys help me out what I possibly do wrong?

I download en use the complete installation on SD card and it works fine on my PI3B. I can start openwebrx on my laptop but (of course) with some errors in the log (SDR device failed / websocket stopped). I edited the configuration file to copy/paste the code from: .

What confused me is that the lines were already in the config file together with the code for other devices. So I expect to see a setting where I can select the type of SDR but can't find it. I guess there is some kind of auto-select device mechanism? I understand that it works different from the original openwebrx and now uses connectors. Anyway, if I let the config file as it is it won't work.  So I tried to replace the sdrs code with only the one for the Airspy but if I do that the whole config file is broken and the server won't start at all and gives an error. 

For what its worth, to know for sure that the image/connections/sdr were OK, I also installed the original openwebrx and adjusted the suggested lines
This works flawlessly but it's not what I want :-)

What am I doing wrong guys?


Jakob DD5JFK Ketterl

Hello :)

The lines that are already present in the config are basically an example, but they also have the nice side-effect that the device types listed there will work right out of the box when you start the receiver for the first time. There is no auto-detection in place (yet), but the software will detect most errors when the devices first start up, and remove them (temporarily; after a restart, everything is back to square one).

I did not include all possible variations in the initial configuration, because then of course the file would be huge. The R2, unfortunately, is not part of the initial configuration, that's why there's a configuration "snippet" on the Wiki. From your description, it sounds as if you added the snippet to your config, but it is actually meant to replace the complete "sdrs={ ... }" section of the configuration (that's 125 lines in total), and not as an addition.

I also just noticed that the sample on the Wiki took a wrong turn somewhere, since it had profiles for shortwave bands with the SpyVerter disabled. I have split the sample in two now, one for use on VHF/UHF, and one for use on shortwave with the SpyVerter.

If you still can't get it to work, feel free to attach your configuration and errors or post them to me directly, I'll have a look :)


Jakob DD5JFK


Hi Jakob, 

Let me first thank you for all of your work 'adopting' this great piece of software and make it smarter and better every time.  

As a Linux noob it took me quite some (long) evenings to figure it all out. I now can say that I find my way around and understand the basics. Last night I was finally able to get my R2 to work with your version. The key for me was the installation of your latest image (I use the .zip). In the config file you wrote some more information about how to connect the Airspy (soapySDR + connector). I also noticed the little glitch in the config file were it was referring to "Type=airspy_connector'" . When I changed it to "airspy" it worked just fine! ( I saw that you changed the wiki yesterday :-)) Even it took me awhile to find it out, it was fun to get this working and I hope it will help other Airspy users in the near future who read this :-)

Now you are here :-) let me ask your some other questions:

  • Do I understand it correctly that you can only change the frequency (by clicking on it) if it's within the scope of the predefined band? If so, this is for a reason I presume? Maybe a technical limitation or by design? (because more people can use it at the same time). I guess the only solution for now is to make much more predefined band plans (2500000 sample rate) so I can listen to my most used frequencies (mainly UHF and VHF)

  • I think it REALLY neat that it's possible to decode DMR (etc). Despite that, it is not working flawlessly. If I listen to a (very) nearby DMR repeater the decoded sound is quite distorted and missing pieces of the conversation (CPU 49%). As I understand,  it's not possible to tweak any digital settings right? The only thing I could try was adjusting the bandwidth, but this wasn't making any difference. If you want to listen to it for yourself or I can help let me know! 

  • It would be nice to see some (DMR) network information and/or identification files/errors etc. I know this from the DMRPLUS plugin within SDR# and it's quite helpful to know if, for example, your reception is good enough. Still, it's just helpful and no life-changer. 



Jakob DD5JFK Ketterl

Hi Rene,

sorry for the late reply, work has been keeping me very busy this week, and also sorry for the outdated information in the wiki. The "connector" suffix was only a temporary thing to help the transition, and I didn't remember that there was still occurences on the wiki, I hope I got them all fixed now. I'm happy you could make it work.

Now for your questions:

  • There's two basic ways of "switching frequency" that are pretty much present in most SDR software, it is less obvious in many, but it is very obvious in OpenWebRX, which is due to the fact that it's a multi-user system. You can tune and listen to any frequency in the current band, which will not affect any other users, or you can switch the tuned frequency of the SDR (which is most commonly referred to as the "center frequency") which will affect all users that are currently using the affected SDR device. Both of these interactions are possible with OpenWebRX, but since switching the center frequency affects other users, it is not implemented in a simple drag&drop manner, but instead using the profiles and the profile switching dropdown. This has some positive side effects: The users are only able to select bands that have been set up by the operator, which prevents them from listening to stuff they're not legally allowed to listen to, and also prevents them from tuning into bands where the physical setup will not receive anything. It also allows the receiver operator to limit the device to a single profile, preventing users from switching and interfering with each other. The latter of course is a very limiting move, but since all users need to share the physical device there's no way to allow two bands at the same time. This limitation has also been in place in the original OpenWebRX and other websdrs.

  • DMR is using the AMBE voice codec, which takes a lot of CPU to decode. I have tried to split the decoding process into separate steps, so that they can make use of multicore architectures, where available. Unfortunately, as it turns out, the voice codec alone takes up pretty much a complete CPU core on a Raspberry Pi, which is probably why you are having problems with choppy audio. Decreasing the bandwidth is generally the correct move to take load off the CPU, but in this case there's unfortunately a limit to how much one CPU core can do, which is why that didn't help. There is some other recommendations though:
    • Use a Pi 3B+ or better. The Pi 3B+ was the first model that had enough power to decode continuous AMBE audio in realtime.
    • Keep the CPU temperature below 65C to avoid temperature throttling. (Check temperature with "vcgencmd measure_temp")
    • Make sure you are supplying enough power to the Pi. If the core voltage drops too low, the Raspberry will throttle to reduce power consumption. (You can use "vcgencmd get_throttled" to check that, please consult the official documentation here:
  • For the DMR information: I would need some more documentation on how to extract them from the actual signal. From what I know, there's no detecting the DMR network (e.g. Brandmeister / DMRplus / DMR-MARC) from the data that is sent over the air. The individually assigned user ids (that are used to determine the callsign and name) are kept in sync across the networks, whereas the talkgroups are somewhat different. Bit error rate is something I'd actually like to implement at some point, but at this point I'm not sure how it works. It is actually defined as the amount of errors over time, but in the case of this application, I can only account for the errors I can actually detect.

This turned out to be a rather lengthy reply. I hope I could answer some of your questions, I'll of course answer some more if not :)

73s and Happy Weekend
Jakob DD5JFK


Hi Jakob, 

Thanks again for answering my questions! I hope your/our information is not only useful for me but for other Openwebrx users as well. First a short reply to your answers without quoting are of your lines:

Frequency tuning --> . Because I setup Openwebrx just for private use (for now) it was kind of strange to me that I was limited to certain predefined bands. Especially because I was used to using #SHARP which gives you unlimited access. But now I know why it was build like that (multi-user) it's more clear to me. I now made for about 10 predefined bands were I can choose from. It still is quite limited but hey, it works! :-). I know, it's not the meaning and design of OpenwebRX but it would be neat if you can choose between a multi-user and private mode with unlimited access (+ login and password or something). 

DMR --> Interesting! For your information, I use a Raspberry 3B+ (with your build). When I'm listening to analog signals the CPU load is only +/- 45%. When I listen to the nearby DMR repeater it rises till max 55%. So it is handles it very well! I change the DMR quality parameter to 3 by the way ( CPU still is 55%). I've got the feeling that the sound quality is a bit better, but not sure. What does the setting do precisely?
As for the extra (status) information: Sometimes you see and hear a digital signal but it is not decoding (for some reason). It would be nice to see whats going on in that case (encrypted/other digital modes etc). A digital auto-select feature that detects which digital modes would be nice ;-). 

Some other thoughts while playing with OpenwebRX the last week:

  • I understand why the large red banner "under construction" is on the screen :-) Still, it would be nice if it can be optionally disabled. 
  • I found OpenwebRX in my search for an alternative to Spyserver. With Spyserver I can't control my SDR on my (android) phone and with openWebRX this is possible and thats great. Still, it is (understandably) quite limited because of the available space on the screen. For example, some buttons are not available (log/receiver/maps) because the receiver banner is in the way.  This is horizontal and this is vertical (which is much to small :-)) on a 5.7 inch screen.  I don't know if it automatically connects to a mobile version of the page or that this is Chrome who is resizing it. 
  • Curious why WFM isn't supported? Is this because of technical limitations?
I got SO many more ideas and questions :-) but let's stick to this. I don't want to flood you, especially because you are so busy. 




Jakob DD5JFK Ketterl

Hello Rene,

I'm happy to receive so much feedback :) As usual, there's more to it than the obvious, but I'm glad to share what's behind.

About the frequency tuning: I have been thinking about building a fully-tunable, "private" mode that would need to be enabled in the configuration. I do understand that many users put up a receiver just for their personal use (which is perfectly fine!) but in case of OpenWebRX, priority is multi-user operation. Of course that doesn't mean it's limited to that, at least not as long as there's no immediate conflict. I have also been thinking about allowing the fully-tuneable mode in "public" mode, but within limits set up by the operator (e.g. the 70cm band, which is 430 to 440 here, is too big to cover with an rtl-sdr. Right now, the only way to make that work is to split the band into segments of 2MHz. But in the end, it would be much nicer to be able to scroll the band, just like most people are used to now from their desktop SDR software).

DMR: I think you're referring to "digital_voice_unvoiced_quality" - basically... the AMBE voice codec differentiates between voiced noises (aeiou) and unvoiced noises (stf...) and synthesizes them differently. The parameter is basically influencing the latter, and should make them sound better, at least that's what I understand. Technically, it's just a parameter that is passed on the library, but I have found that it has a much bigger impact on the CPU usage than on the audio quality, hence the recommendation to keep it on 1 for Raspberry users (not sure if you saw that in the config). It also applies to the other digital voice modes, e.g. D-Star, YSF, NXDN.

The decoder currently is not picking up weak signals very well, which is one of the things that I'd like to improve. For the case of DMR, if the decoder has received a sync word on frequency, it will light up the little green indicator (next to Timeslot 1 / 2), which is the first step at decoding anything. From there on, the signal might be a lot of different stuff, out of which only the most interesting ones are displayed on the interface (There's "idle" frames, which don't contain any data, or data mode, which is not decoded at this point). As soon as some useful voice data is received, you should of course get information like the talkgroup id, and if your receiver you can connect to the internet, it will even look up the callsign and name from the database.

Things are a little bit different for YSF, but they should behave somewhat similar. For D-Star and NXDN, I don't have any inband data yet, since those modes still use the dsd decoder which only supplies audio data. I'll have to see what kind of data is available for those modes once I start implementing custom decoders for them.

I do intend to leave the "under construction" banner in place for all "development" builds, which is pretty much everything that has been available from me so far. I will remove it for all official (stable) releases. The current state is pretty much where I'd like to have it for the first release, I'm just ironing out some bugs at the moment, and setting up the build pipeline for releases, so stay tuned ;)

Mobile usage... is another big issue. It's on my list, but I haven't done much for it. I hope to address this at some point, but I'm not a big mobile user myself, so I'm not sure when I'll get around to it. I do try to build the frontend stuff in a modular manner when I'm wokring on it, so that should at least help. It's still a lot of untouched code, though.

Wideband FM isn't in the package since the audio sample rate that is sent to the client is too low (depending on the soundcard in use, it is selected somewhere between 8kHz and 12kHz). According to Nyquist, that would allow audio frequencies of up to 4kHz or 6hHz respectively, which isn't sufficient for enjoyable audio. I have been thinking about adding a high-quality (HD?) audio mode to get past that. I'd also like to offer DRM (not to be confused with DMR) in the future, which will probably also require better audio, so that's probably a good addition. It will require more network bandwidth, though, even though nowadays that's probably not the biggest problem any more.

BTW: I opened up a separate group here on for OpenWebRX a few days ago. I haven't done much promotion for it yet, but I guess that will be the future place to discuss all these questions. I'm more than happy to answer them, but I think we've left the airspy specific questions a while back ;) So feel free to join over on

73s and all the best
Jakob DD5JFK


Hi Jakob and all other OpenWebRX (wannabee) (airspy) users,

I think it's a great idea to open up a separate OpenWebRX group. We will not bother Airspy users in this group with non related stuff and it's possible to open up more than one topic so we not have to stuff all info in one topic like this one :-). I hope it will encourage other users as well to give feedback so it will help you develop. 

So, who will join us?----->>