Rtl_sdr fails with -O 'agc=0'

1

Hi,
I have been running strf for 402 MHz for quite some time now. The biggest problem was that the AGC for the RTL V3 dongle kicked in many times making it hard to view the actual strf results. With the help of PE0SAT I managed to replace the rtl_sdr tool with an updated version ( GitHub - rtlsdrblog/librtlsdr: Software to turn the RTL2832U into an SDR ) which has the -O after which may other options can be used. So I changed my grabbing script and added -O ‘agc=0’ to the script:

Start channelizer

nice -20 ./rffft -i $FIFO -p $WORKINGDIR/data -f $FREQ -s $RATE -q -c 50 -F char &

Start rx_samples_to_file

nice -20 rtl_sdr -d 0 -p 0 -O ‘agc=0’ -g $GAIN -f $FREQ $FIFO &

nice -20 ./rtl_sdr -d 0 -p 0 -g $GAIN -f $FREQ $FIFO &

This has been working for weeks with very nice results. My focus went to S-band strf so I did not use this setup for some time, until last week I decided to see what T11 launch did bring to the strf results.

The output of my strf plot made me wonder if my antenna / filter / preamp setup was broken somehow. It looks like this (screenshot from today) where I have a strong buoy signal at 401.1 MHz which is totally invisible:

image
image1044×823 221 KB

If I remove the -O option and run the script ( with 401000000 10m 43,4 ) as center frequency , duration and gain, I get a nice strf screen with a lot of signals. Same when I run sdrpp on the same rtl device, there are plenty of signals showing up.

So, I made a sudo make uninstall and made a fresh git clone, make, sudo make install and sudo ldconfig. rtl_sdr shows the -O as option , but the output is still the same strf plot with lack of signal.

Output without the -O option:

image
image1044×823 124 KB

Shoot me. I am clueless…

2

My guess is, that you have multiple libraries and you need to have a good look on what library is used when building.

Before running make, go over the cmake output.

Some ways to look at version available

dpkg -l | grep librtl

sudo ldconfig -v | grep sdr

ldconfig: Path `/usr/lib/x86_64-linux-gnu' given more than once
ldconfig: Path `/lib/x86_64-linux-gnu' given more than once
ldconfig: Path `/usr/lib/x86_64-linux-gnu' given more than once
ldconfig: Path `/usr/lib' given more than once
	librtlsdr.so.0 -> librtlsdr.so.0.9git
	librtlsdr.so.0 -> librtlsdr.so.2.0.1

Also check if you multiple rtl_sdr version on your system:

sudo find / -name rtl_sdr -print

example:

sudo find /usr -name rtl_sdr -print

/usr/bin/rtl_sdr
/usr/local/bin/rtl_sdr

Check what version will be used:

command -v rtl_sdr

/usr/local/bin/rtl_sdr
1 Like
3

cmake output:

cmake ../ -DINSTALL_UDEV_RULES=ON
-- Build type not specified: defaulting to release.
-- Extracting version information from git describe...
-- Building with kernel driver detaching disabled, use -DDETACH_KERNEL_DRIVER=ON to enable
-- Building for version: 33f0 / 0.9git
-- Using install prefix: /usr/local
-- Configuring done
-- Generating done
-- Build files have been written to: /home/hacker/librtlsdr/build

The message " Building for version: 33f0 / 0.9git is the / a reference to the library used ?

dpkg -l | grep librtl
ii librtlsdr-dev:amd64 0.6.0-4 amd64 Software defined radio receiver for Realtek RTL2832U (development)
ii librtlsdr0:amd64 0.6.0-4

but sudo ldconfig -v grep sdr shows 2 appearances of librtlsdr.so

librtlsdr.so.0 -> librtlsdr.so.0.9git
	libsdrplay_api.so.3.07 -> libsdrplay_api.so.3.07
	libosmosdr.so.0 -> libosmosdr.so.0.0.0
	libgnuradio-osmosdr.so.0.2.0 -> libgnuradio-osmosdr.so.0.2.0.0
	libmirisdr.so.0 -> libmirisdr.so.0.0.0
	librtlsdr.so.0 -> librtlsdr.so.0.6.0

There is only one rtl_sdr in /usr/local/bin/rtl_sdr which automatically matches the version that will be used,

command -v rtl_sdr
/usr/local/bin/rtl_sdr

What is a good next step ?

Thanks,
Ben

4

The main issue here is that the deb packages version is installed at the same time as a source built one in another location. In this case, always try to build the .deb package and install that over the old one. This can be tricky sometimes but it means that the files are closely tracked with future installs and upgrades.
Another less safe method is to build and install by source, but with the same paths as the deb package. ymmv on this one as the complete list of files does not necessarily overlap 100%.

The OBS repos also contain a updated version if you want to try that instead. But you need to clean up the mess first (:
repos for Debian 11 and Debian 12

1 Like