Re: New SDR dongle received but cannot get it to work

Okay, if you send another email with output of rtl_test -t I'm going to blacklist your email address. Use rtl_test to run the test for a 2832. Use rtl_test -t to run the test for a 2838. Type rtl_test --help It clearly indicates the -t flag in rtl_test is for the E4000. The system claims you have a 2832 - and not a 2838 or E4000 - so get over it. Clear enough? This is your device: Using device 0: Generic RTL2832U OEM Found Rafael Micro R820T tuner It clearly states it's a RTL2832 device with a Rafael Micro R820T tuner. No E4000 tuner found, aborting. This statement clearly indicates your device is NOT a E4000 - or a 2838. Did you remove the your home brewed file from /etc/udev/rules.d? If not then remove it and reboot. Send me a listing of /etc/modprobe.d and the contents of the file you're using to blacklist the RTL devices. Also, update your system listing and install the following apt-get update apt-get install librtlsdr-dev apt-get install libusb-1.0-0-dev What type of computer are you using? If you're using a computer with more than 1 USB port, try plugging the dongle into another port. It's possible the RTL dongle is bad or you have problems with your USB ports - but you need to eliminate system possible system software issues first. -- Cinaed John <mailto:subs@qcontinuum.plus.com> 22 October 2017 17:02 Cinead, Thank you for this information and the ruleset. I have been looking for an 'official' ruleset to try, but couln't find one. For whatever reason a ruleset was not automatically installed. However, I installed the software from the repository via apt-get rtl-sdr rather than downloading and compiling. I have now removed the file I created and installed the one you provided. Unfortunately it made no difference. I initially used just the two udev commands to re-initialise udev, but then also rebooted for good measure. You observation  is interesting however, as this device identifies itself as vendorID '0bda' and deviceID '2838' in lsusb: Bus 002 Device 012: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T and likewise in dmesg: [  622.683133] usb 2-1.6: new high-speed USB device number 12 using ehci-pci [  622.787405] usb 2-1.6: New USB device found, idVendor=0bda, idProduct=2838 [  622.787410] usb 2-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [  622.787413] usb 2-1.6: Product: RTL2838UHIDIR [  622.787415] usb 2-1.6: Manufacturer: Realtek [  622.787417] usb 2-1.6: SerialNumber: 00000001 As you point out however, it has an R820T tuner, which has now been visually confirmed by the markings on the IC, so if RTL and other programs are expecting an E4000 then this is probably not going to work. I expect that the device will always match the second rule in the ruleset and it seems that it is possible to access the device in user mode. However I'm not sure how to get around the expectations of the driver? Curiously the second rule refers to 'Newsky TV28T (E4000/R820T)' which mentions both radios for the same product ID, so then one might expect that the driver looks for either and tries to determine which it is? rtl_test seemed to identify it correctly - 'Found Rafael Micro R820T tuner' but then then also fails to find an E4000 radio 'No E4000 tuner found, aborting.' so my assumption was that it was trying to determine which one was present, but then I am not familiar with the code. So the question in my mind is whether rtl_test is indeed making a determination and the errors are due to a problem communicating with the device, or whether it is looking for E4000 hardware as you say and failing because it is sending inappropriate commands. If the latter, then is there a way to fool it, e.g. by temporarily changing the device ID or forcing the driver to communicate with an RT820T radio? I did find the -d flag and tried rtl_test -d0 but this yielded a similar response, although it did not identify any tuner and simply returned 'No supported tuner found'. The full output is below: $ rtl_test -t Found 1 device(s):   0:  Realtek, RTL2838UHIDIR, SN: 00000001 Using device 0: Generic RTL2832U OEM Found Rafael Micro R820T tuner r82xx_write: i2c wr failed=-1 reg=1a len=7 r82xx_write: i2c wr failed=-1 reg=0c len=1 r82xx_init: failed=-1 rtlsdr_demod_write_reg failed with -1 rtlsdr_demod_read_reg failed with -1 Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 48.0 49.6 rtlsdr_demod_write_reg failed with -1 rtlsdr_demod_read_reg failed with -1 r82xx_write: i2c wr failed=-1 reg=0a len=1 rtlsdr_demod_write_reg failed with -1 rtlsdr_demod_read_reg failed with -1 rtlsdr_demod_write_reg failed with -1 rtlsdr_demod_read_reg failed with -1 rtlsdr_demod_write_reg failed with -1 rtlsdr_demod_read_reg failed with -1 rtlsdr_demod_write_reg failed with -1 rtlsdr_demod_read_reg failed with -1 rtlsdr_demod_write_reg failed with -1 rtlsdr_demod_read_reg failed with -1 rtlsdr_demod_write_reg failed with -1 rtlsdr_demod_read_reg failed with -1 rtlsdr_demod_write_reg failed with -1 rtlsdr_demod_read_reg failed with -1 WARNING: Failed to set sample rate. No E4000 tuner found, aborting. rtlsdr_demod_write_reg failed with -1 rtlsdr_demod_read_reg failed with -1 rtlsdr_demod_write_reg failed with -1 rtlsdr_demod_read_reg failed with -1 rtlsdr_write_reg failed with -1 Cinaed Simson <mailto:cinaed.simson@gmail.com> 22 October 2017 03:53 On 10/21/2017 09:08 AM, John wrote: The output from rtl_test indicates it's a "2832" - but your home brewed rule is probing for a "2838" which is the E4000. I recommend you install the enclosed udev rules. After you copy them to /etc/udev/rules.d, try udevadm control --reload udevadm trigger If that doesn't work, reboot. The correct rules should have been installed when you installed the sofware - so you may have other problems. And use rtl_test The command rtl_test -t is for the E4000 - and your enclosed error message indicates it's not E4000. -- Cinaed > r82xx_write: i2c wr failed=-1 reg=13 len=7 > r82xx_write: i2c wr failed=-1 reg=0c len=1 > r82xx_init: failed=-1 > rtlsdr_demod_write_reg failed with -1 > rtlsdr_demod_read_reg failed with -1 > Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 > 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 > 43.4 43.9 44.5 48.0 49.6 > rtlsdr_demod_write_reg failed with -1 > rtlsdr_demod_read_reg failed with -1 > r82xx_write: i2c wr failed=-1 reg=0a len=1 > rtlsdr_demod_write_reg failed with -1 > rtlsdr_demod_read_reg failed with -1 > rtlsdr_demod_write_reg failed with -1 > rtlsdr_demod_read_reg failed with -1 > rtlsdr_demod_write_reg failed with -1 > rtlsdr_demod_read_reg failed with -1 > rtlsdr_demod_write_reg failed with -1 > rtlsdr_demod_read_reg failed with -1 > rtlsdr_demod_write_reg failed with -1 > rtlsdr_demod_read_reg failed with -1 > rtlsdr_demod_write_reg failed with -1 > rtlsdr_demod_read_reg failed with -1 > rtlsdr_demod_write_reg failed with -1 > rtlsdr_demod_read_reg failed with -1 > WARNING: Failed to set sample rate. > No E4000 tuner found, aborting. > > John <mailto:subs@qcontinuum.plus.com> 21 October 2017 17:08 Hello, I am new to this list and to SDR radio. I have purchased an SDR dongle but am having trougble getting it to work. The dongle was described as an RTL8232U/R820T2 device. I am running on Linux MINT version 18.2 and lsusb detects the device as follows: Bus 002 Device 051: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T Is it an RTL2832U or an RTL2838? I'm not really sure. From research it seems that It seems like the fist order of business is to blacklist the kernel driver? So I have done this by adding a backlist-rtl.conf file to /etc/modprobe.d and rebooted the computer. I have also added a rules file to /etc/udev/rules.d with the following content: # Realtek Semiconductor Corp. RTL2838 DVB-T SUBSYSTEMS=="usb", ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="2838", MODE:="0666", GROUP="adm", SYMLINK+="rtl_sdr" I can now access the device in user mode without permission errors so I assume that this is working OK. So my next step was to run rtl_test -t. The output I got contained errors.If I then try to run any sdr software such as rtl_fm or gqrx, the device is reset and the application fails to run. Subsequentlly running 'rtl_test -t' gives: No supported devices found. Even running rtl_test-t sometimes does the same so i'm not sure whether the device is 'dropping out' of its own accord. I am wondering whether the current crop of devices are supported? Or is this a configuration problem? The output from rtl_test: rtl_test -t Found 1 device(s):   0:  Realtek, RTL2838UHIDIR, SN: 00000001 Using device 0: Generic RTL2832U OEM Found Rafael Micro R820T tuner r82xx_write: i2c wr failed=-1 reg=13 len=7 r82xx_write: i2c wr failed=-1 reg=0c len=1 r82xx_init: failed=-1 rtlsdr_demod_write_reg failed with -1 rtlsdr_demod_read_reg failed with -1 Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 48.0 49.6 rtlsdr_demod_write_reg failed with -1 rtlsdr_demod_read_reg failed with -1 r82xx_write: i2c wr failed=-1 reg=0a len=1 rtlsdr_demod_write_reg failed with -1 rtlsdr_demod_read_reg failed with -1 rtlsdr_demod_write_reg failed with -1 rtlsdr_demod_read_reg failed with -1 rtlsdr_demod_write_reg failed with -1 rtlsdr_demod_read_reg failed with -1 rtlsdr_demod_write_reg failed with -1 rtlsdr_demod_read_reg failed with -1 rtlsdr_demod_write_reg failed with -1 rtlsdr_demod_read_reg failed with -1 rtlsdr_demod_write_reg failed with -1 rtlsdr_demod_read_reg failed with -1 rtlsdr_demod_write_reg failed with -1 rtlsdr_demod_read_reg failed with -1 WARNING: Failed to set sample rate. No E4000 tuner found, aborting. rtlsdr_demod_write_reg failed with -1 rtlsdr_demod_read_reg failed with -1 rtlsdr_demod_write_reg failed with -1 rtlsdr_demod_read_reg failed with -1 rtlsdr_write_reg failed with -1