RTL-SDR v4 not working

[barf]

Hello the RTL-SDR v3 was working OK but after upgrading the librtlsdr to support v4 the module is failing to detect it with the --probe command.

The v4 is tested and working using rtl_test, rtl_tcp and SDR++ it seems only SoapyRTLSDR has trouble with it on my system now, after rebuilding against the newer librtlsdr from osmocom. Using Debian trixie's rtl-sdr package or the RTL-SDR blog fork gives me the same result.

After running the --probe command the device becomes unusable and needs to be removed and plugged back in again:

$ SoapySDRUtil --probe=driver=rtlsdr
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Probe device driver=rtlsdr
Found Rafael Micro R828D tuner
RTL-SDR Blog V4 Detected
[INFO] Opening Generic RTL2832U OEM :: 00000001...
rtlsdr_read_reg failed with -7
rtlsdr_write_reg failed with -7
rtlsdr_read_reg failed with -7
rtlsdr_write_reg failed with -7
rtlsdr_read_reg failed with -7
rtlsdr_write_reg failed with -7
No supported tuner found
rtlsdr_demod_write_reg failed with -7
rtlsdr_demod_read_reg failed with -7
rtlsdr_demod_write_reg failed with -7
rtlsdr_demod_read_reg failed with -7
rtlsdr_demod_write_reg failed with -7
rtlsdr_demod_read_reg failed with -7
rtlsdr_demod_write_reg failed with -7
rtlsdr_demod_read_reg failed with -7
Enabled direct sampling mode, input 1
rtlsdr_demod_write_reg failed with -7
rtlsdr_demod_read_reg failed with -7
rtlsdr_demod_write_reg failed with -7
rtlsdr_demod_read_reg failed with -7
rtlsdr_demod_write_reg failed with -7
rtlsdr_demod_read_reg failed with -7
rtlsdr_demod_write_reg failed with -7
rtlsdr_demod_read_reg failed with -7

----------------------------------------------------
-- Device identification
----------------------------------------------------
  driver=RTLSDR
  hardware=UNKNOWN
  index=0
  origin=https://github.com/pothosware/SoapyRTLSDR

----------------------------------------------------
-- Peripheral summary
----------------------------------------------------
  Channels: 1 Rx, 0 Tx
  Timestamps: YES
  Time sources: sw_ticks
  Other Settings:
     * Direct Sampling - RTL-SDR Direct Sampling Mode
       [key=direct_samp, default=0, type=string, options=(0, 1, 2)]
     * Offset Tune - RTL-SDR Offset Tuning Mode
       [key=offset_tune, default=false, type=bool]
     * I/Q Swap - RTL-SDR I/Q Swap Mode
       [key=iq_swap, default=false, type=bool]
     * Digital AGC - RTL-SDR digital AGC Mode
       [key=digital_agc, default=false, type=bool]
     * Test Mode - RTL-SDR Test Mode
       [key=testmode, default=false, type=bool]
     * Bias Tee - RTL-SDR Blog V.3 Bias-Tee Mode
       [key=biastee, default=false, type=bool]

----------------------------------------------------
-- RX Channel 0
----------------------------------------------------
  Full-duplex: NO
  Supports AGC: YES
  Stream formats: CS8, CS16, CF32
  Native format: CS8 [full-scale=128]
  Stream args:
     * Buffer Size - Number of bytes per buffer, multiples of 512 only.
       [key=bufflen, units=bytes, default=262144, type=int]
     * Ring buffers - Number of buffers in the ring.
       [key=buffers, units=buffers, default=15, type=int]
     * Async buffers - Number of async usb buffers (advanced).
       [key=asyncBuffs, units=buffers, default=0, type=int]
  Antennas: RX
  Full gain range: [0, 0] dB
    TUNER gain range: [0, 0] dB
  Full freq range: [23.999, 1764] MHz
    RF freq range: [24, 1764] MHz
    CORR freq range: [-0.001, 0.001] MHz
  Sample rates: [0.225001, 0.3], [0.900001, 3.2] MSps
  Filter bandwidths: [0, 8] MHz

rtlsdr_write_reg failed with -7

[zuckschwerdt]

So using the current Osmocom rtl-sdr lib (https://github.com/osmocom/rtl-sdr/ at v2.0.2) the RTL-SDR v4 is probed but somehow rendered unuseable?

This should happen without using SoapySDR, if we use the same rtlsdr_* API commands. We should find the sequence of commands used and create a minimal example.

[barf]

So using the current Osmocom rtl-sdr lib (https://github.com/osmocom/rtl-sdr/ at v2.0.2) the RTL-SDR v4 is probed but somehow rendered unuseable?

This is my understanding, yes. Just to confirm again the v4 receiver works (below the 24MHz limit on the v3) using the rtl_fm command also:

$ rtl_fm -f 10000000 -M am |hexdump -C -n 64
Found 1 device(s):
  0:  RTLSDRBlog, Blog V4, SN: 00000001

Using device 0: Generic RTL2832U OEM
Found Rafael Micro R828D tuner
RTL-SDR Blog V4 Detected
Tuner gain set to automatic.
Tuned to 10252000 Hz.
Oversampling input by: 42x.
Oversampling output by: 1x.
Buffer size: 8.13ms
Exact sample rate is: 1008000.009613 Hz
Allocating 15 zero-copy buffers
Sampling at 1008000 S/s.
Output at 24000 Hz.
00000000  48 00 d2 00 8a 00 20 01  ba 00 2a 00 1a 01 b4 00  |H..... ...*.....|
00000010  d2 00 ea 00 ba 00 72 00  0c 00 80 01 ae 00 d2 00  |......r.........|
00000020  36 00 f6 00 ba 00 32 01  86 01 ae 00 e4 00 32 01  |6.....2.......2.|
00000030  c6 00 26 01 78 00 b4 00  f0 00 02 01 a8 00 ba 00  |..&.x...........|

This should happen without using SoapySDR, if we use the same rtlsdr_* API commands. We should find the sequence of commands used and create a minimal example.

Looking at the Settings.cpp the SoapyRTLSDR object is instantiated with the RTLSDR_TUNER_R820T before any probing is done? But the v4 device features an R828T however I'm a bit out of my depth reading and writing C/C++ sorry.

There may also be a bug in the upstream driver causing this, a similar "failed with -7" error can be reproduced by running the rtl_fm command repeatedly (in quick succession), so maybe there is some wrong command sent, a timing issue or failure to wait/assert something but that's just me speculating. It occurs on 2/2 devices I have, testing with powered USB hubs on both Raspberry Pi (arm64) and PC (x64).

Thanks

[zuckschwerdt]

I don't think that SoapyRTLSDR is doing any unusual calls to the lib. rtl_fm will just open the first device and Soapy does a full enumeration opening and checking devices, then opens a selected device. The lib should prevent getting to an invalid state if just using a normal flow of API commands.

It's a R828D, right? Should be the same as the R820T but with selectable inputs.

We need someone with a V4 to unroll the used calls into an example to pinpoint where the crash occurs. Or you could try to ask RTL-SDR Blog or the implementers of the V4 features for assistance.

[barf]

Yes it is a R828D AFAIK. I'm not inclined to blame SoapySDR but the --probe reliably reproduces some bug, I'll look into reproducing it using the rtl_* tools and report to osmocom if I can.

Thanks for your help!

[zuckschwerdt]

If you can pinpoint the issue closer we might be able to do something. But it could be some timing issue and thus hard to write a test for if not sitting down with the hardware and trying things live.

[krutzy62]

Hello. I was wondering if there has been any progress on this issue?

[barf]

Hello. I was wondering if there has been any progress on this issue?

I think it's an upstream bug in librtlsdr, or maybe a simpler power supply issue: the v4 does needs more energy, and ~2A 5V DC Raspberry Pi power supplies are possibly not delivering enough: I noticed a USB mouse stop working at the same time as these errors. Either way more testing is required.