R820T2 not receiving signals if LOOP_THROUGH is ON

[rsmatias]

I’m involved in an ADS-B project that use librtlsdr now at v0.5.4 and at this point I have a problem when initialising my receiver.

I found that when the function r82xx_set_tv_standard() is called, some R820T2 registers are programmed and I receive nothing on the RF signal chain. But, if I change this function to return (return rc;) just before the "need_calibration = 1;”, skipping all the rest of the function, then my receiver works properly.

My hardware is based on the RTL2382U and R820T2. I already had another hardware working properly. I made some investigations on my own to figure out if something on the PCB layout could be the problem. It is a 6 LAYER PCB because it is attached to the main CPU (everything is on the same board). I also have a small dongle (alone with no CPU part) and with this exact problem. Also with same PCB specifications.

I ran several tests around librtlsdr at function r82xx_set_tv_standard() and concluded that the LOOP_THROUGH ON/OFF (register 0x05 mask 0x80) and LOOP_THROUGH_ATTENUATION (register 0x1F mask 0x80 - not documented) at R820T chip have direct impact on our dongle functionality.

   If I comment these function calls everything works properly.

###CUT FROM tuner_r82xx.c source code###

/* rc = r82xx_write_reg_mask(priv, 0x05, loop_through, 0x80);
if (rc < 0)
{
printf("Return at Loop Through\n");
return rc;
}/
/ Loop through attenuation /
/ rc = r82xx_write_reg_mask(priv, 0x1f, lt_att, 0x80);
if (rc < 0)
{
printf("Return at Loop_Through Attenuation.\n");
return rc;
}*/

###END OF CUT###

If I keep this LOOP off, our dongle starts to receive signals immediately and works properly. Looks like our PCB with 6 copper layers and substrate with only 0.2mm thickness have impact in this feature but we cannot get rid of it because all HW is on same PCB.

So, my question is if you can add this new feature to your LIB to give developers the option to switch LOOP_THROUGH ON or OFF to deal with this.

I know that for years, since the development started, many new features and improvements have been made. Would you consider it? Our goal is to help improve and to keep using standard librtlsdr, not a modified version.

Thanks for your support. I would also like to ear some feedback from other users to understand if my thoughts are correct.

Regards.
Rodrigo Matias

[satmandu]

Was there ever any resolution to this? I found that reverting to 0.5.3 solves my ADS-B problems, whereas I receive no data at all when I upgrade to 0.5.4. This is a problem for ubuntu users as upgrading to Cosmic will download the 0.5.4 version of the rtl-sdr software, which breaks ads-b setups using software like dump1090.

[steve-m]

Loop through was disabled in commit 5c3073f included in the latest release version 0.6.0, as it is unused on the hardware anyways. Can you build rtl-sdr from source as described in the wiki and test if ADS-B reception is working?

[satmandu]

wget https://github.com/steve-m/librtlsdr/archive/0.6.0.zip
unzip 0.6.0.zip
cd librtlsdr-0.6.0/
dpkg-buildpackage -b
 cd ..
ls
0.6.0.zip                            rtl-sdr_0.6git_arm64.buildinfo
librtlsdr0_0.6git_arm64.deb          rtl-sdr_0.6git_arm64.changes
librtlsdr-0.6.0                      rtl-sdr_0.6git_arm64.deb
librtlsdr0-dbgsym_0.6git_arm64.ddeb  rtl-sdr-dbgsym_0.6git_arm64.ddeb
sudo dpkg -i *.deb
(Reading database ... 186005 files and directories currently installed.)
Preparing to unpack librtlsdr0_0.6git_arm64.deb ...
Unpacking librtlsdr0:arm64 (0.6git) over (0.5.3-13) ...
Preparing to unpack librtlsdr-dev_0.6git_arm64.deb ...
Unpacking librtlsdr-dev (0.6git) over (0.5.3-13) ...
Preparing to unpack rtl-sdr_0.6git_arm64.deb ...
Unpacking rtl-sdr (0.6git) over (0.5.3-13) ...
Setting up librtlsdr0:arm64 (0.6git) ...
Setting up librtlsdr-dev (0.6git) ...
Setting up rtl-sdr (0.6git) ...
Processing triggers for libc-bin (2.28-0ubuntu1) ...
Processing triggers for man-db (2.8.4-2) ...
sudo systemctl stop dump1090-mutability
sudo /usr/bin/dump1090-mutability --raw
Mon Oct  8 17:04:51 2018 EDT  dump1090-mutability v1.15~dev starting up.
Using sample converter: UC8, integer/table path
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001 (currently selected)
Found Rafael Micro R820T tuner
Max available gain is: 49.60 dB
Setting gain to: 49.60 dB
Gain reported by device: 49.60 dB
Allocating 15 zero-copy buffers
[ nothing happens here ]
^CMon Oct  8 17:05:04 2018 EDT  Caught SIGINT, shutting down..
cd ~/oldrtl
ls
librtlsdr0_0.5.3-13_arm64.deb     rtl-sdr_0.5.3-13_arm64.deb
librtlsdr-dev_0.5.3-13_arm64.deb
sudo dpkg -i *
dpkg: warning: downgrading librtlsdr0:arm64 from 0.6git to 0.5.3-13
(Reading database ... 186006 files and directories currently installed.)
Preparing to unpack librtlsdr0_0.5.3-13_arm64.deb ...
Unpacking librtlsdr0:arm64 (0.5.3-13) over (0.6git) ...
dpkg: warning: downgrading librtlsdr-dev from 0.6git to 0.5.3-13
Preparing to unpack librtlsdr-dev_0.5.3-13_arm64.deb ...
Unpacking librtlsdr-dev (0.5.3-13) over (0.6git) ...
dpkg: warning: downgrading rtl-sdr from 0.6git to 0.5.3-13
Preparing to unpack rtl-sdr_0.5.3-13_arm64.deb ...
Unpacking rtl-sdr (0.5.3-13) over (0.6git) ...
Setting up librtlsdr0:arm64 (0.5.3-13) ...
Setting up librtlsdr-dev (0.5.3-13) ...
Setting up rtl-sdr (0.5.3-13) ...
Processing triggers for libc-bin (2.28-0ubuntu1) ...
Processing triggers for man-db (2.8.4-2) ...
sudo /usr/bin/dump1090-mutability --raw
Mon Oct  8 17:06:27 2018 EDT  dump1090-mutability v1.15~dev starting up.
Using sample converter: UC8, integer/table path
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001 (currently selected)
Found Rafael Micro R820T tuner
Max available gain is: 49.60 dB
Setting gain to: 49.60 dB
Gain reported by device: 49.60 dB
*5dab4ae1590e56;
*5daaee43ad6351;
*5daaee43ad6351;
*5daaee43ad6351;
*02a1863c824894;
*5dab4ae1590e56;

TL;DR: 0.6.0 also produces no output.
Downgrading back to 0.5.3 restores function.
(Also FYI 0.6.0 labels itself as 0.6git when I use "dpkg-buildpackage -b")

So maybe this needs a new ticket opened?

[steve-m]

Interesting, the only R820T-relased change that I see between 0.5.3 and the current version are those two commits: d892279, 92df068.

Can you revert them (clone the repository and do git revert d892279 and git revert 92df068) and try again?

[satmandu]

That works.

[steve-m]

So it seems like dump1090 should set the bandwidth to a higher value with rtlsdr_set_tuner_bandwidth(), because for all other (narrowband) applications lowering the IF bandwidth actually helped reducing interferece from strong adjacent transmitters.

[satmandu]

If rtlsdr_set_tuner_bandwidth() isn't set, it default to automatic bandwidth selection, yes?

Can that default be the same as before rtlsdr_set_tuner_bandwidth() was added, so as not to break existing applications? Or do most applications benefit from a smaller default bandwidth? I don't know what the distribution is of applications using rtl-sdr libraries, but I suspect that number of dump1090 users out there might be considerable.

Even a userspace toggle to make that happen might be meaningful so as not to have to recompile existing applications.