[bug] tuning LO across frequency border leads to reset gain setting

[qrp73]

Steps to reproduce:

1. Install rtl-sdr-blog on linux OS
2. Start SDR++
3. tune LO to >80 MHz and notice noise floor and signal levels
4. setup gain to 40.2 dB
5. tune LO to 5 MHz (it leads to tune acress frequency border between different RF path)
6. tune LO step-by-step with step about 0.1-1 MHz back to >80 MHz

Expected result: since gain is set to 40.2 dB and didn't changed it should restore proper 40.2 dB gain

Actual result: the actual gain is reset to 0 dB, but SDR++ still shows 40.2 dB and it didn't changed by user. You can check it with noise floor and signals level.

[qrp73]

current workaround - when it happens, just change gain for some value and return it back, it will restore proper gain. Unfortunately there is no way to detect when it happens, so you're needs to be careful with change LO across HF and VHF bands

[qrp73]

just tested what returns driver function rtlsdr_get_tuner_gain when this issue happens.
It returns last value of rtlsdr_get_tuner_gain.

For example here is sequence which demonstrate the bug in the driver:

// select VHF RF path...
rtlsdr_set_center_freq(hDev, 145500000);
// setup gain 40.2 dB
rtlsdr_set_tuner_gain_mode(_this->openDev, 1);
rtlsdr_set_tuner_gain(_this->openDev, _this->gainList[_this->gainId]);

// select HF RF path...
rtlsdr_set_center_freq(hDev, 1500000);

// now select VHF RF path again
rtlsdr_set_center_freq(hDev, 145500000);

// check driver gain
int gain = rtlsdr_get_tuner_gain(hDev);

// DRIVER BUG: rtlsdr_get_tuner_gain returns 402, but actual gain is 0 dB

So, this is a bug of rtl-sdr-blog driver.

[rtlsdrblog]

I'll have a look at this on Linux in a few days time. I just did a quick test on Windows with SDR# but couldn't reproduce it there.

[qrp73]

just tried driver from original repository:

git clone https://github.com/osmocom/rtl-sdr.git

it works ok, with no this issue and it appears more fresh than your code and already supports RTLSDRv4.

The issue is present in the driver code from your reporsitory.

Please fix it, or just apply changes from original osmocom repository to your repository. Because it confuses users who installed driver. My first impression was that I got broken RTLSDRv4 device, because it didn't received signals when I tune it from HF band to VHF. Now it's clean that it appears due to this gain issue.

[rtlsdrblog]

Hm I just tested this on Linux with the rtl-sdr-blog driver and SDR++, but I still cannot reproduce it using your steps. Can I know the details of what system you are running on?

The rtl-sdr-blog fork is almost exactly the same as the osmocom drivers, so I suspect the problem you are having is something to do with ef7651c. I added this commit to fix a problem with another group of users who noticed that osmocom and the old rtl-sdr-blog driver versions were having issues with rapid tuning used for scanning on AMD devices. This fixed that issue, but I did suspect that it could have unintended consequences for other systems. Though no system I have available to test on shows any problems.

[qrp73]

I'm running on raspberry pi OS bookworm aarch64.
This issue can be reproduced with source code cloned from this repository.

[rtlsdrblog]

I just tested on a Pi 5 Bookworm with SDR++ but still can't reproduce. What model Raspberry Pi are you running on?

tune LO step-by-step with step about 0.1-1 MHz back to >80 MHz

To reproduce do you have to slowly step up back to >80 MHz in 0.1-1 MHz steps, or does larger 10Mhz step changes also trigger the issue? I've tried both but both are working fine from what I see.

[qrp73]

I'm using RPI4 with 6.6.17-v8+ kernel, you can install this latest kernel with

rpi-update rpi-6.6.y

but I don't think it related to platform or kernel.

It happens with code from your repository cloned on 30-JAN-2024. It was compiled and installed according to your instructions here: https://www.rtl-sdr.com/V4/
So, if you had changes after that date, it may be the reason why you cannot reproduce it.

The issue happened when you tune LO slowly from 5 MHZ to 100 MHz with step about 100 kHz-1 MHz using mouse wheel and placing mouse cursor on frequency digit. I reproduce it when SDR++ was in LO mode. Usually I tested it with RTLSDRv3, but as I remember it also happened for RTLSDRv4 either, because it happens just at first RTLSDRv4 test.

This issue was stable reproduced on the driver code compiled from your repository, so I have no idea why you cannot reproduce it. May be you're using driver with changes from latest osmocom driver which already fix it.

Currently I switched to the latest osmocom driver which don't have such issue. I compare source and yes there is some minor difference which you posted above. I think these difference is the root of cause for this issue.

For more reliable steps to reproduce, you can use c++ code that I posted above:

// select VHF RF path...
rtlsdr_set_center_freq(hDev, 145500000);
// setup gain 40.2 dB
rtlsdr_set_tuner_gain_mode(hDev, 1);
rtlsdr_set_tuner_gain(hDev, 402);

// select HF RF path...
rtlsdr_set_center_freq(hDev, 1500000);

// now select VHF RF path again
rtlsdr_set_center_freq(hDev, 145500000);

// check driver gain
int gain = rtlsdr_get_tuner_gain(hDev);

// DRIVER BUG: rtlsdr_get_tuner_gain returns 402, but actual gain is 0 dB

[qrp73]

Some new finding probably related with this issue.
I just catch similar issue with new OS setup. It appears that v4 unable to receive something on 145 MHz, it just shows some strange two noise peaks and don't react on input signals. While v3 works ok.

Installing osmocom driver version didn't helped. But my old OS setup works ok with v4.

Detailed investigation shows that process loads incorrect library:

$ sudo lsof -n | grep librtlsdr
rtl_tcp   1073                              pi  mem       REG              179,2    69136      26108 /usr/lib/aarch64-linux-gnu/librtlsdr.so.0.6.0
rtl_tcp   1073 1077 libusb_ev               pi  mem       REG              179,2    69136      26108 /usr/lib/aarch64-linux-gnu/librtlsdr.so.0.6.0

It appears that there is librtlsdr0 and librtlsdr-dev packages are installed, so I removed it:

sudo apt remove librtlsdr0 librtlsdr-dev

And it solved the issue, now it loads correct library (which is installed with sudo make install):

$ sudo lsof -n | grep librtlsdr
rtl_tcp   1229                              pi  mem       REG              179,2    80504       1875 /usr/local/lib/librtlsdr.so.2.0.1
rtl_tcp   1229 1233 libusb_ev               pi  mem       REG              179,2    80504       1875 /usr/local/lib/librtlsdr.so.2.0.1

And now it works ok.