Modalità di lettura

Re: [new] Improved OpenWebRX Packages Available

OpenWebRX+ 1.2.121, available from the repository, adds multitude of fixes and improvements to the signal processing, as well as better filtering of PskReporter spots. See below for all changes.

- Now validating PskReporter spots.
- More Yaesu/Kenwood APRS IDs [Geoffrey Phillips].
- [NR] Added Hamming window to the input.
- [NR] Added 50% output buffer overlap.
- [NR] Fixed sound pop when NR is engaged.
- [NR] Fixed noise floor tracking.
- [NR] Fixed NR threshold to use proper dB.
- [AGC] Added initial peak computation.
- [AGC] Fixed complex magnitude clamping.
- [AGC] Fixed setHangTime() argument type.
- [CW] Fixed noise floor tracking.
- [CW] Fixed CW codes table.
- [CW] Fixed WPM computation.
- [FAX] Fixed phase tracking.
- [FAX] Fixed zero magnitude handling.
- [FAX] Fixed color computation.
- [SSTV] Fixed buffer deletion.
- [SSTV] Fixed YUV to RGB conversion.
- [SSTV] Fixed intra-scanline sync.
- [SSTV] Fixed PD scanline sequence.
- [DSC] Fixed coordinate parsing.
- [DSC] Fixed frequency parsing.
- [DSC] Fixed phone number parsing.
 
PS: Short cheat sheet for people who just cannot get things to work:

1) If it does not work for you, reload OpenWebRX page while holding the SHIFT key.
2) If it does not work for you, check "Settings | Feature report" page to see what you are missing.
3) If it does not work for you, wait for a day or two, maybe it starts working or you figure it out.
4) If it does not work for you, create a separate forum thread and explain your problem there. Attach the logs, obtained with "sudo journalctl -u openwebrx". Do not paste the entire log into the message, attach it as a file instead.

  •  

Port forwarding for rasberi pi

Hi everyone,

I’m trying to set up OpenWebRX on a Raspberry Pi 5.

It works well on my LAN, but I’m trying to make it work over WAN. I’ve set up a permanent IP address using DuckDNS, but now I need to forward the port. I tried using the Port forward utilitis software, but I don’t know which TCP and UDP ports to enter to connect to the Raspberry Pi. I don’t know which port it is broadcasting on, and I don’t know if having a permanent IP address is actually useful for this or not.

Thanks!

  •  

Re: Feature request: RF bandwidth setting per SDR profile

On Tue, Aug 11, 2026 at 08:48 AM, Marat Fayzullin wrote:
So far, you have not yet disclosed what device driver you select in OpenWebRX in order to use your device. This is somewhat important if you expect somebody else to make the change for you, right?
sorry for not providing enough information 

I'm using the  PlutoSDR driver in OpenWebRX.

The PlutoSky is connected via Ethernet or USB , and the relevant Soapy device arguments are essentially:

driver=plutosdr,uri=ip:192.168.20.70

So OpenWebRX starts the soapy_connector, which then uses the SoapyPlutoSDR driver.

My suggestion was to make setBandwidth() follow the selected sample rate in this path, because the Pluto otherwise seems to keep/use a much larger RF bandwidth than necessary.

######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################
----------------------------------------------------
-- Device identification
----------------------------------------------------
  driver=PlutoSDR
  hardware=ADALM-PLUTO
  ad9361-phy,model=ad9361
  ad9361-phy,xo_correction=40000567
  backend_version=0.26 (git tag: v0.26)
  fw_version=tezuka-v0.3.16
  hw_model=PlutoSky Rev.2 (Z7020-AD9361)
  hw_model_variant=1

  •  

Re: Feature request: RF bandwidth setting per SDR profile

Thanks. I understand that the actual RF bandwidth is a driver setting.

However, I think exposing it as an optional setting in an OpenWebRX SDR profile would still be useful. OpenWebRX already changes parameters such as sample rate when switching profiles, and could simply call the driver's setBandwidth() as part of the profile setup.

Automatically coupling RF bandwidth to sample rate inside the driver would be one possible solution, but it would be less flexible, since RF bandwidth does not necessarily have to equal the sample rate.

  •  

Feature request: RF bandwidth setting per SDR profile

Hello,

is this the right place to post feature requests?

I have a new PlutoSky R2 (AD9361) and noticed that when switching between OpenWebRX profiles with different sample rates, the AD9361 rf_bandwidth setting does not change.

It would be useful to have an RF bandwidth setting per profile, similar to the sample rate setting.

For example:

  • 1 MS/s profile → 1 MHz RF bandwidth
  • 4 MS/s profile → 4 MHz RF bandwidth
  • 10 MS/s profile → 10 MHz RF bandwidth

Currently, if rf_bandwidth is set to 1 MHz and I switch to a 4 MS/s profile, it remains at 1 MHz, so the analog RX bandwidth is much narrower than the sampled spectrum.

Ideally, the profile could contain a configurable rf_bandwidth value which is passed to SoapySDR using setBandwidth().

For example, on the AD9361 the current RX RF bandwidth can be read with:

 
iio_attr -u ip:192.168.20.70 -i -c ad9361-phy voltage0 rf_bandwidth
 

and it can be changed independently of the sample rate, for example:

 
iio_attr -u ip:192.168.20.70 -i -c ad9361-phy voltage0 rf_bandwidth 4000000
 

This would set the RF bandwidth to 4 MHz, which would be useful for an OpenWebRX profile using a 4 MS/s sample rate.

The AD9361 in my PlutoSky R2 supports RX RF bandwidth values up to 56 MHz.

Thanks!



  •  

Re: [new] Improved OpenWebRX Packages Available

The new OpenWebRX+ 1.2.120, available from the repository, adds bubble display of bookmarks, as they get selected, as well as improvements to APRS reporting. See below for all changes.
 
- Added bookmark info bubbles when clicked.
- Fixed reporting third party APRS packets.
- Disabled reporting non-reportable APRS packets.
- Fixed typo in APRS "adressee" name.
- Stripped whitespace from APRS addressee.
 
Bookmark-Bubbles.png
 
PS: Short cheat sheet for people who just cannot get things to work:

1) If it does not work for you, reload OpenWebRX page while holding the SHIFT key.
2) If it does not work for you, check "Settings | Feature report" page to see what you are missing.
3) If it does not work for you, wait for a day or two, maybe it starts working or you figure it out.
4) If it does not work for you, create a separate forum thread and explain your problem there. Attach the logs, obtained with "sudo journalctl -u openwebrx". Do not paste the entire log into the message, attach it as a file instead.

  •  

Re: Background decoding - interesting problem

Background decoding, when enabled, will automatically decode anything that is available, that means: anything that is registered in the bandplan, is enabled, and is available on a currently running profile.
 
I suppose your device is decoding on profiles that are being used by clients, or you have the "keep device running at all time" option checked, in which case it will just continue decoding on the last profile used on the device. The schedule is a feature that will take control of the device if no clients are using the device any more, it just gives you more control over what the device should do while idle.
 
PSKreporter on the other hand has its own configuration, where it can be en- or disabled separately.
  •  

Background decoding - interesting problem

Hello. I have a very interesting issue regarding background decoding. After selecting the "Enable background decoding services" option, the server immediately begins decoding WSPR (which is the only mode I have selected) and sending spots to PSKReporter simultaneously on the 40m and 20m bands. What makes this particularly interesting is that my SDR profiles do not have the "Run background services on this device" option enabled, nor do I have a "Scheduler" configured. Decoding starts immediately upon checking the "Enable background..." option. I cannot understand why it specifically targets the 20m and 40m bands, or why it begins decoding and spotting straight away. I have three devices plugged to RPi4: one RTL and two Sdrplay's. The RTL profile covers only VHF/UHF; the first Sdrplay (RSP1) has profiles: 160m, 80/60m, 40m, 30m, ..., 6m; and the second Sdrplay (RSPa1) has profiles for 20m, 15m, and 10m. It is worth noting that the first profile on the RSP1 is 160m, while the first profile on the RSPa1 is 20m. The server is not open in a web browser. Thanks for any opinions and help to understand this ironically issue.
 
73
Arek
  •  

Re: DX PATROL MK4.

Thanks for the reply. I had an issue with the PPM setting that needed adjustment. I also need to find a solution for the high gain. I added a blacklist entry that frees up the receiver, decoupling it from the DVB-T receiver.
  •  

Re: DX PATROL MK4.

Geia sou Giorgo,

It looks like you need to blacklist some modules.

First create the following file (copy past from sudo all the way to last EOF)

sudo tee /etc/modprobe.d/exclusions-rtl2832.conf <<EOF
# Blacklist host from loading modules for RTL-SDRs to ensure they
# are left available for the Docker guest.

blacklist dvb_core
blacklist dvb_usb_rtl2832u
blacklist dvb_usb_rtl28xxu
blacklist dvb_usb_v2
blacklist r820t
blacklist rtl2830
blacklist rtl2832
blacklist rtl2832_sdr
blacklist rtl2838

install dvb_core /bin/false
install dvb_usb_rtl2832u /bin/false
install dvb_usb_rtl28xxu /bin/false
install dvb_usb_v2 /bin/false
install r820t /bin/false
install rtl2830 /bin/false
install rtl2832 /bin/false
install rtl2832_sdr /bin/false
install rtl2838 /bin/false
EOF

Then do also the following

sudo modprobe -r dvb_core
sudo modprobe -r dvb_usb_rtl2832u
sudo modprobe -r dvb_usb_rtl28xxu
sudo modprobe -r dvb_usb_v2
sudo modprobe -r r820t
sudo modprobe -r rtl2830
sudo modprobe -r rtl2832
sudo modprobe -r rtl2832_sdr
sudo modprobe -r rtl2838

then..
sudo depmod -a

After that I would reboot the raspi and hopefully all will be ok.

-Yiannis
  •  

Re: DX PATROL MK4.

Do you mean OpenWebRX+ 1.2.117 SD Card Image for 64bit Raspberry Pi ?
 
RasPi 3 probably doesn't have enough processing power, and although it has 64-bit ARM core with a 32-bit GPU, the usual RasPi OS is only 32-bit.
 
I'd suggest minimum RasPi 4 (or even better a 5) hardware, to be able to take full advantage of OWR+.
 
 
On Tue, Aug 4, 2026 at 05:26 AM, GEORGE-SV1GGY wrote:
  •  

DX PATROL MK4.

Good evening to the group. I have an RPi 3B and installed OpenWebRx from the official site (dated 11/10/2023), and it works very well. However, when I installed OpenWebRx version 1.2.117 from LZ2SSL, I get no VHF/UHF/HF reception at all. In the first instance, the system recognizes the SDR as an RTL-SDR, whereas in the second, it recognizes it as a DVB TV receiver. Does anyone have any idea what I should do? The waterfall display is blue, but there is no signal reception. All settings seem to work, yet there is no reception. Thanks in advance.
  •  

Re: FreeDV Decoder not working on OpenWebRx+ 1.2.117

I am running openwebrx+ on my Debian box (AMD64) and I was able to compile the software into a .deb file, then install the deb.  I'm not related to the project at all, but I'll try to help if I can.  
 
At https://github.com/peterbmarks/radae_decoder  I followed the instructions under "Install dependencies (Debian/Ubuntu)".  I then followed the "quick build" under  "Debian Package for webrx_rade_decode" .
 
A .deb file was built, then I used dpkg to install it.
 
It installed a file /usr/bin/webrx_rade_decode
 
I restarted openwebrx+ and boom!  there were new modes listed as "RADEU" and "RADEL".  I tried using it a bit on what I thought were FreeDV signals and it did not seem to be working.  No sound.  But maybe the signal was too weak or somthing because as I was scanning the bands last night, I ran across the Tuesday night FreeDV net and it worked flawlessly.
 
I don't know what platform you're trying to run openwebrx+ on, but it looks like the RADE decoder page has good instructions for MAC also.  If on a Raspberry PI, then I'm guessing the Debian instructions MAY work on there.  I don't know.  I hope this is of some help.
 
  •  
❌