SatNOGS 3649 - RTL-SDR Blog V4 Issues

Hello everyone

I could use some assistance with my SatNOGS station.

I am having a hard time with getting my RTL-SDR blog V4 to work properly on a raspberry pi v3b+ with the SatNogs image on it. There is also a SAWbird +NOAA LNA/BPF on the setup powered by the internal bias tee on the RTL-SDR.

I am consistently getting a blank spectrum, and I’ve been led to believe that it is a driver issue due to the V4 requiring different drivers than the V3 or other rtl-sdrs.

I tried following the instructions for updating the drivers for the V4 from this link:

but now I get "RuntimeError: soapysdr: :device: :make() no match error when the setup attempts an observation.

Here is the metadata from a failed observation in case I’m making an error in my satnogs-setup:
{

radio: {
    name: "gr-satnogs",
    version: "v2.3-compat-xxx-v2.3.5.0",
    parameters: {
        soapy-rx-device: "driver=rtlsdr",
        samp-rate-rx: "2.048e6",
        rx-freq: "137100000",
        file-path: "/tmp/.satnogs/data/receiving_satnogs_9785284_2024-07-04T02-07-13.out",
        waterfall-file-path: "/tmp/.satnogs/data/receiving_waterfall_9785284_2024-07-04T02-07-13.dat",
        decoded-data-file-path: "/tmp/.satnogs/data/receiving_data_9785284_2024-07-04T02-07-13.png",
        doppler-correction-per-sec: null,
        lo-offset: null,
        ppm: null,
        rigctl-port: "4532",
        gain-mode: "Overall",
        gain: "49.6",
        antenna: "RX",
        dev-args: null,
        stream-args: null,
        tune-args: null,
        other-settings: null,
        dc-removal: null,
        bb-freq: null,
        bw: null,
        enable-iq-dump: "0",
        iq-file-path: null,
        udp-dump-host: null,
        udp-dump-port: 57356,
        wpm: null,
        baudrate: null,
        framing: null
    }
},
latitude: 45.96299067991878,
longitude: -66.62266471226759,
elevation: 12,
frequency: 137100000

Any assistance would be greatly appreciated!

1 Like

Short answer, you need an updated librtlsdr library.

When you run the following command, you will see based on the output that you are using and can support the V4.

SoapySDRUtil --probe="driver=rtlsdr"

######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Probe device driver=rtlsdr
Found Rafael Micro R820T/2 tuner
Found Rafael Micro R828D tuner
RTL-SDR Blog V4 Detected
[INFO] Opening Generic RTL2832U OEM :: 40000600...
Found Rafael Micro R828D tuner
RTL-SDR Blog V4 Detected

Let me check if there is already an updated package, otherwise for now, we need to do this manually

Ok I did the SoapySDRUtil --probe=“driver=rtlsdr” command and got the following:

Probe device driver=rtlsdr

Error probing device: SoapySDR: :Device: :make(): no match

Thank you for the instruction - I assume the next step is to manually update the drivers.

Unofficial build from me, tested on a V3 and V4.

Download deb here:
https://download.opensuse.org/repositories/home:/knegge:/branches:/home:/librespace:/satnogs-unstable/Debian_11/

Or build it yourself (will require a bunch of dependencies):

sudo apt install devscripts build-essential cmake libusb-1.0-0-dev
dget -q -u https://download.opensuse.org/repositories/home:/knegge:/branches:/home:/librespace:/satnogs-unstable/Debian_11/rtl-sdr_2.0.2-3satnogs1.dsc
cd rtl-sdr-2.0.2
dpkg-buildpackage -us -uc -b
cd ..
sudo dpkg -i rtl-sdr_2.0.2-3satnogs1_amd64.deb librtlsdr0_2.0.2-3satnogs1_amd64.deb
# OR
sudo dpkg -i rtl-sdr_2.0.2-3satnogs1_armhf.deb librtlsdr0_2.0.2-3satnogs1_armhf.deb
1 Like

Thank you for the build - I ran the code after getting the dependencies figured out - what is the next step? I still get the error probing device issue when i use the SoapySDRUtil function.

I’m quite new to debian and linux, so I am greatly appreciative of you patience!

That sounds like the device isn’t connected or has some usb issue, running lsusb should look something like this:

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

run dmesg -w and re-plug the device, it should show it connect.

If the udev rules are ok, it should show up in /dev
ls -lR /dev/bus/usb/|grep plugdev

crw-rw---- 1 root plugdev 189, 2 Jul  3 14:04 003

Thank you so much for the continued assistance.

Everything you’re describing is working fine and giving expected results per your instructions, except for the SoapySDRUtil function, which is still indicating that there’s not match for the device.

Do you recommend doing a fresh SatNOGS image and starting from the beginning?

Following on from this, what’s the current recommended approach for enabling a RTLSDR Bias-Tee?

The only instructions I’ve find relate to the rtl_biast utility - is this really still the only way to do this?

  Other Settings:
     * Bias Tee - RTL-SDR Blog V.3 Bias-Tee Mode
       [key=biastee, default=false, type=bool]

iirc this can be added to the dev args, SATNOGS_DEV_ARGS: biastee=true
@PE0SAT has this on station 431

And this will also work: driver=rtlsdr,biastee=true

1 Like

I recently bought the RTL-SDR Blog V.4 and am finding that it’s a big improvement over the V.3 for my UHF station (I am in the middle of a city). I followed the RTL-SDR Blog how-to to update the rtl-sdr, librtlsdr0, and librtlsdr-dev packages, and these work fine. When I now do a “sudo apt update”, the upgrade path from version 0.7.0~rtlsdrblog1 to 2.0.2-2~bpo11+1satnogs1 is offered. If I simply do a “sudo apt upgrade”, will I break the V4 capabilities that are now working fine?

My inquiry is essentially how to maintain the latest drivers in the longer term, going forward. Thanks for your help!

73 de VA2WBT

1 Like

Did you build a updated .deb package and install, or just the make install ?
Depending on the exact details on how you did this, you will end up with more than one installed version and YMMV.
We did end up releasing the 2.0.2 version since it had reverted some of the issues with the 0.6 to 2.0 transition had.
If you think 2.0.2 suffices for your needs, it should be fine. Depending on how you installed the other version, the mentioned issue will persist.

I did the first of the two options you mentioned: build the updated .deb package and install, i.e. the exact instructions described as “Alternative Debian Package Installation Method” in the V4 manual here https://www.rtl-sdr.com/v4/. Would this give me a straightforward upgrade path to your 2.0.2 version, which I have not yet tried?

1 Like

That should works just fine, replacing the package versions is usually a smooth operation. do the apt upgrade and run a rtl_test, it should just work.
And no, it’s not my version, I did work on it and made a package, but @Acinonyx ended up reworking it again. “we” as in satnogs-developers (:

1 Like

Indeed, I did the apt upgrade, then ran an rtl_test as well as a Mode U observation. All looks good so far. Thanks very much!

Now I just need to figure out a way to prevent my nearby digital (FT8) HF transmissions from overloading my SatNOGS station during observations…

VA2WBT

1 Like

Thank you, too. Mine (v4) was dead to the world until I read this. HI 73

2 Likes