Adaptive range error when adjusting rtlsdr gain

[rcarsey1]

Still digging into this issue.. not quite sure of the cause yet. Compiled on Ubuntu 20.04.3 LTS. Blue FlightAware dongle (orange and others with the same chipset exhibit same problem):

Oct 30 23:26:34 ubuntu dump1090-fa[50068]: adaptive: available dynamic range (29.5dB) < required dynamic range (30.0dB), continuing downwards scan
Oct 30 23:26:34 ubuntu dump1090-fa[50068]: adaptive: changing gain from 49.6dB (step 28) to 48.0dB (step 27) because: probing dynamic range gain lower bound
Oct 30 23:26:34 ubuntu dump1090-fa[50068]: rtlsdr_demod_write_reg failed with -9
Oct 30 23:26:34 ubuntu dump1090-fa[50068]: r82xx_write: i2c wr failed=-9 reg=05 len=1
Oct 30 23:26:34 ubuntu dump1090-fa[50068]: rtlsdr: failed to disable tuner AGC

These errors occur repeatedly, trying to step down (from and to) the same gain level without success.

Here is the command I'm executing:

/usr/bin/dump1090-fa --device-type rtlsdr --device-index 1090 --gain 60 --adaptive-range [other non-relevant options omitted]

Here are the libraries installed with Ubuntu 20.04.3 LTS (if you aren't already familiar):

root@ubuntu:/usr/local/src/dump1090# apt list | grep rtl | grep sdr

librtlsdr-dev/focal,now 0.6.0-3 amd64 [installed] librtlsdr0/focal,now 0.6.0-3 amd64 [installed,automatic] rtl-sdr/focal,now 0.6.0-3 amd64 [installed] soapysdr-module-rtlsdr/focal,now 0.3.0-2build1 amd64 [installed] soapysdr0.7-module-rtlsdr/focal,now 0.3.0-2build1 amd64 [installed,automatic]

Here is what was built:

Building with: Version string: unknown DSP mix: x86 RTLSDR support: yes BladeRF support: no HackRF support: no LimeSDR support: no

and the libraries which were linked:

root@ubuntu:/usr/local/src/dump1090# ldd /usr/bin/dump1090-fa

        linux-vdso.so.1 (0x00007ffe2ffb1000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f2c11d0c000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f2c11bbd000)
        librtlsdr.so.0 => /lib/x86_64-linux-gnu/librtlsdr.so.0 (0x00007f2c11bac000)
        libncurses.so.6 => /lib/x86_64-linux-gnu/libncurses.so.6 (0x00007f2c11b83000)
        libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007f2c11b53000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2c11961000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f2c11daf000)
        libusb-1.0.so.0 => /lib/x86_64-linux-gnu/libusb-1.0.so.0 (0x00007f2c11943000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f2c1193d000)
        libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007f2c11910000)

I've also tried removing the Ubuntu rtlsdr libraries and pulling the latest from osmocom's git repo (v0.70 i believe).

Unsure what to try next, or if the problem is with dump1090-fa, librtlsdr, or the RTL2832U.

[mutability]

-9 is LIBUSB_ERROR_PIPE, i.e. we sent a control transfer and the 2832 is responding with a USB stall.

I believe this means that I2C communication with the tuner is failing i.e. this is a hardware problem.

I don't see this error on dongles here.

(I have seen one other report of a similar problem on the FA forums, but not enough info there to follow up, and the majority of installs seem fine)

[mutability]

Maybe one thing you can try is to get a wireshark capture of the USB traffic (https://gitlab.com/wireshark/wireshark/-/wikis/CaptureSetup/USB) to/from the dongle at the point where it's failing; maybe there's something informative beyond just "USB stall" in there.

[rcarsey1]

I believe the cause of the problem was either the hardware that I was using.. or the fact that I was running Ubuntu under VMWare ESXi 6.7 with the USB devices set as pass-thru so that they are presented to the VM. I ended up installing the same dongles on different hardware.. using the same install scripts (for the OS and dump1090-fa). If I had more time, I would troubleshoot further.. but alas, its not a dump1090-fa problem.. so we can close this issue now.

If anyone else wants to do further testing with USB passthru devices under VMWare ESXi, be my guest (pun intended).

[mutability]

Oh, it's a VM, okay. USB passthrough in VMs does have a history of working poorly with rtlsdr dongles (in particular it drops data like crazy, so mlat is unlikely to work) so I'm not too surprised that control transfers while data is flowing also has problems.