RF notch filter is always on

Question

RF notch filter is always on

iwiq opened this issue 4 years ago · 28 comments

Is there a way to activate the RF notch filter via a device argument so that it always stays on when using RSP1A ?

Answer 1 · 2020-12-12T00:30:58.000Z

@iwiq - thanks for your feedback.

Looking at the source code of Settings.cpp, I see there is a SoapySDR argument called 'rfnotch_ctrl' (see here: https://github.com/SDRplay/SoapySDRPlay/blob/master/Settings.cpp#L1368), that should do exactly that for the RSP1A.

You should be able to see all the available arguments by running the command:

SoapySDRUtil --probe=sdrplay

The output here (I have an RSP2 connected at this moment) shows that 'rfnotch_ctrl' should be already enabled by default:

     * RfNotch Enable - RF Notch Filter Control
       [key=rfnotch_ctrl, default=true, type=bool]

I am not sure if you wrote your own application that uses the SoapySDRPlay driver, or if you are running a third party application, like CubicSDR; in the latter case, you may want to make sure the application does not disable the RF notch filter for your RSP1A (or perhaps there is a button somewhere in the UI to switch it on and off).

Hope this helps,
Franco

Answer 2 · 2020-12-12T17:40:12.000Z

Thank you so much!!!
I am running CubiSDR with API 3.07 and SoapySDR from this repository.
There is a button in the CubicSDR to switch it on and off, and it works great. When RF notch filter is on, I see excellent results of his work.
Yes, default value for filter "true", but it's not work.

When I use osmocom source block in GNURADIO with device argument "driver=sdrplay,soapy=0", RF notch filter is off, and I can't switch it on.
Is it possible to add SoapySDR argument called 'rfnotch_ctrl' to device argument?

Answer 3 · 2020-12-13T00:11:08.000Z

@iwiq - yes, you should be able to just add 'rfnotch_ctrl=true' to your device argument in osmocom, like this:

driver=sdrplay,soapy=0,rfnotch_ctrl=true

and it should work with osmocom.
Are you using osmosdr with the application 'gqrx'?

If it still doesn't work, you may want to try out this fork of the gr-osmosdr GNU Radio module (https://github.com/fventuri/gr-osmosdr); there I made all the changes to the original 'gr-osmosdr' module to support SDRplay API version 3.X (3.07) natively, without requiring the SoapySDR framework (and therefore the SoapySDRPlus driver).

Franco

Answer 4 · 2020-12-17T10:58:44.000Z

Thank you. Perhaps I am doing something wrong, because it not work. I still have to try.
Yes, I'm using osmosdr with gqrx too.

There is similar question in your repository. fventuri/gr-osmosdr#1

Answer 5 · 2020-12-18T03:04:55.000Z

@iwiq - first of all, sorry for the confusion about the 'gr-osmosdr' module, since it looks that API does not support RF notch and several other settings (see my comment there).

In order to troubleshoot your problem with the argument rfnotch_ctrl, I just created a temporary branch called 'debug' (https://github.com/SDRplay/SoapySDRPlay/tree/debug), which will print some log messages on your console that should look like this:

DEBUG - writeSetting(key=<some key>, value=<some value>)

If you don't mind, please compile and install this debug version on your computer, and then run gqrx using this debug SoapySDRPlay driver two times:

the first time with the parameter rfnotch_ctrl=false
the second time with the parameter rfnotch_ctrl=true

Each run should have a few debug messages like the example above; please put those messages here (indicating the value you set for rfnotch_ctrl in each case), so I can take a look, and we can try to figure out where is the problem.

Franco

Answer 6 · 2020-12-20T19:49:50.000Z

I'm sorry to be late with the reply.
I run Gqrx through the terminal, but I don't see this messages in the terminal.
Where should I look for this message? Thank you.

API 3.07.1, Ubuntu 18.04 LTS, Gqrx 2.9



Launching I/O device editor
firstTimeConfig
CIoConfig : Available output devices:
    0 : "HD-Audio Generic Analog Stereo"
New input device selected: 7
  Label: "SDRplay Dev0 RSP1A 100009C497"
  Devstr: "driver=sdrplay,soapy=0,rfnotch_ctrl=true"
saveConfig
Loading configuration from: "/home/user/.config/gqrx/default.conf"
Configuration file: "/home/user/.config/gqrx/default.conf"
gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.11
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy airspyhf soapy redpitaya freesrp 
[INFO] Using format CF32.
IQ DCR samp_rate: 2e+06
IQ DCR alpha: 5e-07
Changing NB_RX quad rate: 96000 -> 2e+06
New antenna selected: "RX"
********************
Gain name: "IFGR"
      min: 20
      max: 59
     step: 1
Gain name: "RFGR"
      min: 0
      max: 9
     step: 1
********************
No change in output device:
  old: 
  new: 
IQ DCR samp_rate: 2.048e+06
IQ DCR alpha: 4.88281e-07
Changing NB_RX quad rate: 2e+06 -> 2.048e+06
Requested sample rate: 2048000
Actual sample rate   : "2048000.000000"
New FFT rate: 25 Hz
Requested bandwidth: 0 Hz
Actual bandwidth   : 200000 Hz
setFreqCorr : 0 ppm
New LNB LO: 0 Hz
New mode index: 2
Filter preset for mode 2 LO: -5000 HI: 5000
Generating taps for new filter   LO:-5000   HI:5000 TW:2000   Taps: 115
setFftRate to "25 fps"
New FFT rate: 25 Hz

Answer 7 · 2020-12-21T02:01:28.000Z

@iWig - those messages should show in the terminal where you launched gqrx from; if you don't see anything like that there, it almost looks like the method writeSetting() never gets called. which seems a bit odd to me.

In order to replicate (and then troubleshoot) the behavior you are seeing there, I tried to rebuild gqrx here, but unfortunately I am having some problems compiling it with the version of GNU Radio I have on my computer right now (3.8.2), so I'll have to figure out in the next few days where is the problem, and then go back to look into how the parameter rfnotch_ctrl gets set.

I'll send you and update as soon as I have gqrx built and running on my computer.

Franco

Answer 8 · 2020-12-21T12:54:56.000Z

Thank you

I'll have to figure out in the next few days where is the problem, and then go back to look into how the parameter rfnotch_ctrl gets set.

Answer 9 · 2020-12-21T14:58:25.000Z

Hi Franco.

I built your temp debug SoapySDRPlay branch to make test with gqrx.

I confirm what @iwiq wrote, no debug when enablig rfnotch_ctrl=true in the device arguments form.
Same for dabnotch_ctrl.

Answer 10 · 2020-12-22T09:19:38.000Z

@nmaster2042 Thank you
It is interesting that notch filter works through an argument "rfnotch_ctrl=true" with a version 2.13 and gr-osmosdr from repository @willcode (sdrplay2 branch).
fventuri/gr-osmosdr#1 (comment)

Answer 11 · 2020-12-22T09:26:45.000Z

Hmmmmmmmm, Debug logging can be enabled in Gqrx by setting the QT_LOGGING_RULES environment variable:
What that means?
https://github.com/csete/gqrx#debugging

Answer 12 · 2020-12-22T10:06:51.000Z

@iwiq it means you can enable debuging of gqrx by starting the app that way:

$ QT_LOGGING_RULES=".debug=true;plotter.debug=false;qt..debug=false" gqrx

It adds debug in the terminal but in my case, not the one @fventuri added in the SoapySDRPlay driver for testing.

That could mean function is not called so rf notch filter actually isn't activated.

Answer 13 · 2020-12-22T12:30:25.000Z

Thanks @iwiq and @nmaster2042 for your detailed report and info.

Quick update on my side: I still have problems compiling gr-osmosdr here on my computer with GNU Radio 3.8 (the problems are due to the SWIG bindings for Python, which seem to use sdt::shared_ptr instead of boost::shared_ptr). Once I figure out those problems (hopefully tonight after work), I should be able to compile gr-psmosdr and gqrx, and then have a way to see why it is not calling that setting rfnotch_ctrl=true in the SoapySDRPlay driver.

Franco

Answer 14 · 2020-12-22T19:15:18.000Z

@fventuri It might be easier to download "GNU Radio Live" iso and run with Pre-Installed SDR Hardware Drivers and Applications.
Download

Answer 15 · 2020-12-23T13:18:25.000Z

Thanks @iwiq for your suggestion; I didn't know about 'GNU Radio Live'.
I didn't have much time last night; tonight I'll try one last time and, if don't get things to build, I'll create a new VM and I'll run 'GNU Radio Live' there, so it will get me good to go.

I also thought last night that perhaps the reason for my build problems is the incompatibility among the different versions of GNU Radio, the gr-osmosdr OOT module, and gqrx; I'd like to know which version of the GNU Radio, gr-osmosdr, and gqrx (and the Linux distro) you and @nmaster2042 are running there, to see if I am using the wrong version for one of these components.

Thanks,
Franco

Answer 16 · 2020-12-23T14:59:26.000Z

I installed everything from repositories, it is very fast and simple on Ubuntu 18.04 LTS.
GNU Radio 3.7.11, gr-osmosdr 0.1.5, GQRX 2.9.

Even faster with a live distro that is installed on a USB flash drive - 1-2 minutes. But I haven't tried it with a virtual machine.

Answer 17 · 2020-12-23T15:59:41.000Z

@fventuri.

Here I'm using kubuntu 20.10.
gnuradio-dev from package v3.8.1.0
gr-osmosdr buitt from source v0.2.0 from officiel git://git.osmocom.org/gr-osmosdr, master branch
gqrx 2.14.3 built from source official github repo, mastre branch
soapysdr v0.8.0 built from source
SDRplay API v3.07
SoapySDRPlay 0.3.0-2bb7ff8 repo: https://github.com/SDRplay/SoapySDRPlay, debug branch

Answer 18 · 2020-12-24T02:43:51.000Z

Good news @iwiq and @nmaster2042 !

I figured out my problem with SWIG - I had some include files from an older gr-osmosdr install back in June still under /usr/local/include/osmosdr, and swig had /usr/local/include before the local source directory, so it was pulling in the wrong include files when creating the mega C++ file with the Python bindings. After I removed that directory with those old osmosdr include files, I was able to build gr-osmosdr 0.2.0 (my setup here is very similar to the one that @nmaster2042 has, except that I am on Fedora 33, instead of kubuntu). I then was able to compile the latest version of gqrx
I ran gqrx with the SoapySDRPlay driver from the debug branch, and I didn't see any of the messages with the 'DEBUG' string I added a couple of nights ago, as you also noticed in your earlier comments
I then spent some time looking through the Settings.cpp source file and I noticed that those additional device string arguments are never processed through the writeSetting() function, so I added a few lines at the end of the constructor for the SoapySDRPlay device that run each additional argument through writeSetting(); this should take care not only of refnotch_ctrl=true, but also of the other configurable settings like dabnotch_ctrl, biasT_ctrl, and so on
I just pushed the code with the fix to a new branch called device_string_args (https://github.com/SDRplay/SoapySDRPlay/tree/device_string_args); this branch has still the message with the 'DEBUG' string at the very beginning of writeSetting(), and this time I was able to see the message on the terminal when running gqrx, so I have good confidence that it should work for you too now

Please pull the code from the new device_string_args branch, build it, run it with gqrx, and let me know how it goes.
If it looks good to you too, I'll remove that 'DEBUG' message, and merge that branch into 'master'; this way the fix will be available for the new builds of the SoapySDRplay driver.

Thanks for your patience while I was troubleshooting these build problems on my computer,
Franco

Answer 19 · 2020-12-24T09:59:05.000Z

@fventuri I pulled, built and tested the device_string_args branch.

Now I have the debug messages in terminal.

Here, rfnotch_ctrl=true and dabnotch_ctrl=true are working.

biasT_ctrl=true I can see the debug message but bias T doesn't seem to activate on port B.

I'm using a RSP Duo, signe tuner mode for my tests.

Update: BiasT is working with this SoapySDRPlay driver version with Cubic SDR just built from source for testing.

Answer 20 · 2020-12-24T13:07:12.000Z

@nmaster2042
The problem with biasT_ctrl is that it looks like gqrx initializes the device without specifying the antenna being used, so biasT gets enabled on the default antenna (i.e. antenna A), and only later it selects the actual antenna by calling setAntenna() (it actually looks like gqrx selects antenna A again, and then it switches to antenna B).

To better explain what I mean, I added a couple more of those 'DEBUG' messages to the code in the device_string_args branch; please rebuild the SoapySDRPlay driver with the latest code from that branch, run gqrx, and you'll see what I mean.

Franco

Answer 21 · 2020-12-24T14:26:33.000Z

@fventuri

I understand what you mean but on rsp devices with more than one antenna port (RSP2, Duo and Dx), bias T is only available on B port.

2 years ago I had a RSP1A, only one antenna port, that's probably why it worked.

It means in soapySDRplay, biasT is enabled only when actual RX antenna is the B port witch makes sense.

Answer 22 · 2020-12-24T15:08:32.000Z

Good point @nmaster2042 ; I didn't realize that bias T is only available on antenna B.

Based on this, I just added a couple of lines to the code in setAntenna() where the RSPduo switches from one tuner to the other (because of the change in antenna port) to preserve the value of the biasT setting.

Please download the latest code from the device_string_args branch, and let me know if it works for you.

Thanks for your feedback,
Franco

Answer 23 · 2020-12-24T16:19:12.000Z

Thank you very much @fventuri , It's ok now, I can enable/disable Bias T on the RSP Duo.
the 2 notch (rf and dab filters are ok too.

I don't know if other options are working, ex extref_ctrl I haven't hardware to test and I don't know what iqcorr_ctrl is actually doing. But when enabling it doesn't makes gqrx to crash.

Will your changes work with RSP2 and Dx ?
I have these devices too.

Answer 24 · 2020-12-24T16:43:00.000Z

Thanks for checking Bias-T on your RSPduo @nmaster2042

As per the RSP2 and RSPdx, I took a quick look at the code in setAntenna() this morning, and I saw that the RSP2 and RSPdx do not change tuner when you switch antenna (because they only have one tuner), so there is only one biasTEnable in the RX parameters; because of that, I think they should work fine without any changes, but I would like to confirm this assumption, if you have time to try Bias-T on your RSP2 and RSPdx.

Thanks for all your help,
Franco

Answer 25 · 2020-12-24T18:01:03.000Z

Thank you for your great support @fventuri.

I will try with my other RSPs ASAP and let you know here.

Answer 26 · 2020-12-25T15:41:58.000Z

Super! Thank you so much! Works with RSP1A.

Answer 27 · 2020-12-25T16:22:31.000Z

Hi, I just made new tests this time with RSP2 and RSP Dx.

Everything is working on all devices: bias T, rfnotch and dab notch.

Thank you very much @fventuri.

I think you can merge this to the master branch. It will greatly improve RSP family sdrs support.

Answer 28 · 2020-12-25T22:40:00.000Z

I just merged these changes, i.e. the ability to control RF notch, DAB notch, and Bias-T using the device string, to the master branch (without the 'DEBUG' messages), and removed the device_string_args branch.

Thanks for testing the new code with your RSPs, and confirming that everything works as expected, @nmaster2042 and @iwiq

I'll leave this issue open for another few days, just in case you (or someone else) finds any problem with these changes.

Franco