Trying to get a new SDR receiver to work with gqrx

[Thornton DeRevoires]

Hello. I am new to the group and to SDR receivers. I have just received my new SDR receiver in the post and am trying to give it a quick test so I first tried it on Windows, but could not get either of the 3 software packages I downloaded (HDSPR, SDR# and SDR-Radio) to work. So I then decided it might be better from a diagnostic point of view to get this running on Linux, but so far I am struggling here too and am wondering whether my receiver is faulty or whether this is down to configuration, although I suspect it is probably the latter.

It would be nice if I could just do a quick test to prove whether the receiver is, in fact working. The receiver is a generic RTL2832U/T820T2 device. I am presently running on Linux MINT 18.2 with Cinnamon 3.4.6. The device is being recognized with lsubs as follows:

Bus 002 Device 007: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T

I have downloaded and run gqrx. I get the GUI window. Under IO devices I have Generic RTL2832U OEM. There is a device string (rtl=0) as well as an input rate and Decimantion is set to 0. Bandidth and LNB LO are showing 0.000000 MHz. I have tried experimenting and setting these to random values but it made no difference. The audio output device is set to default with a sample rate of 48kHz. I seem to be getting absolutely nothing. no audio, no waterfall. Nothing. File | Start DSP does nothing.

In user mode, the command line output gives me an error, so I assume a user permissions issue:

Using device #0 Generic RTL2832U OEM
usb_open error -3
Please fix the device permissions, e.g. by installing the udev rules file rtl-sdr.rules

FATAL: Failed to open rtlsdr device.

So I have also tried with sudo gqrx. This reported:

Using device #0 Realtek RTL2838UHIDIR SN: 00000001

Kernel driver is active, or device is claimed by second instance of librtlsdr.
In the first case, please either detach or blacklist the kernel module
(dvb_usb_rtl28xxu), or enable automatic detaching at compile time.

usb_claim_interface error -6

So I blacklisted the dvb_usb_rtl28xxu driver in /etc/modprobe.d/blacklist.conf and did a 'sudo update-initramfs -u'. IThis got rid of the blacklist error, but I now get as follows:

FATAL: Wrong rtlsdr device index given.

Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to gnuradio bug #528.
...
Failed to set RX input rate to 1.8e+06
Your device may not be working properly.

How do I determine whether this means my device is faulty, or whether I am missing something in the configuration?


Here is the full current command line output:

$ linux; GNU C++ version 5.3.1 20151219; Boost_105800; UHD_003.009.002-0-unknown

Controlport disabled
No user supplied config file. Using "default.conf"
gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.9
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy redpitaya
Using Volk machine: avx_64_mmx_orc
FM demod gain: 1.52789
IQ DCR alpha: 1.04166e-05
Using audio backend: N/A
New filter offset: 0 Hz
BookmarksFile is /home/johnc/.config/gqrx/

bookmarks.csv
Loading configuration from: "default.conf"
Configuration file: "/home/johnc/.config/gqrx/default.conf"
gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.9
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy redpitaya

FATAL: Wrong rtlsdr device index given.

Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to gnuradio bug #528.

********************
********************
No change in output device:
  old:
  new:

Failed to set RX input rate to 1.8e+06
Your device may not be working properly.

IQ DCR samp_rate: 1.8e+06
IQ DCR alpha: 5.55555e-07
Changing NB_RX quad rate: 96000 -> 1.8e+06
Requested sample rate: 1800000
Actual sample rate   : "1800000.000000"
New FFT rate: 25 Hz
Requested bandwidth: 999999 Hz
Actual bandwidth   : 0 Hz
setFreqCorr : 0 ppm
New LNB LO: 1000000 Hz
New LNB LO: 1000000 Hz
updateHWFrequencyRange failed fetching new hardware frequency range
New mode index: 0
Filter preset for mode 0 LO: 0 HI: 0
New filter offset: 122000 Hz
setFftRate to "25 fps"
New FFT rate: 25 Hz
New FFT rate: 25 Hz
setFftSize to "8192"
New FFT rate: 25 Hz

[Alexandru Csete]

You can test your device using the rtl_test application. I believe it
is in the rtl-sdr package.

Alex

> --
> You received this message because you are subscribed to the Google Groups
> "Gqrx SDR" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to gqrx+uns...@googlegroups.com.
> To post to this group, send email to gq...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/gqrx/bd0e65b9-02c5-4158-b4d4-1b34fb67da27%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Thornton DeRevoires]

Just an update.

I have now blacklisted the kernel driver by creating a new file called blacklist-rtl.conf in /etc/modprobe.d with the following contents:

# Kernel module for RTL_SDR
blacklist dvb_usb_rtl28xxu

The computer has been retarted. I have also added a file called 60-rtl-sdr-rules to /etc/udev/rules.d with the following contents:

# Realtek Semiconductor Corp. RTL2838 DVB-T 
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="2838", MODE:="0666", GROUP="adm", SYMLINK+="rtl_sdr"

I have also restarted udev with:

service udev restart

The latter seems to have resolved the permissions issue. However still seem to be having problems getting the dongle to work. Having done a bit more research I found that I could run:

rtl_test -u

This seems to identify the device and the tuner chip:

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
.
.
.

but as you can see there are errors.

I also tried tuning to an FM station using:

rtl_fm -M wbfm -f 106.6M | play -r 32k -t raw -e s -b 16 -c 1 -V1 -

106.6FM is the frequency for Smooth FM which should be easily picked up here. This is what I got:

Found 1 device(s):

-: (raw)

  Encoding: Signed PCM   
  Channels: 1 @ 16-bit  
Samplerate: 32000Hz     
Replaygain: off        
  Duration: unknown     

In:0.00% 00:00:00.00 [00:00:00.00] Out:0     [      |      ]        Clip:0      0:  , , SN:

Using device 0: Generic RTL2832U OEM
rtlsdr_write_reg failed with -1
Resetting device...
rtlsdr_write_reg failed with -4
rtlsdr_write_reg failed with -4
rtlsdr_write_reg failed with -4
rtlsdr_write_reg failed with -4

Running rtl_test after this results in:

No supported devices found.

Unplugging the device from the USB port and plugging it back in again resets it but I have also found that the same happens when I run gqrx and the device does not come up in the device list. The rtlsdr_write and rtlsdr_demod errors are now present in the command line output.

Not sure where to go from here?

[Thornton DeRevoires]

Alex,

Thank you. Your post crossed with my update and I discovered this also in the meantime.

[Alexandru Csete]

> Not sure where to go from here?

Since you have tried many different software packages and none of them
worked, it is safe to assume that there is a hardware fault. It could
be the dongle or it could be your computer. A logical next step would
therefore be to try this dongle on a different computer, or try a
different dongle on this computer.

Alex

[Robin Gape]

Thornton,

it's possible that there's still some software junk getting in the way.
The attached note was written because a great deal of what has been
written about RTL dongles running in SDR mode under Linux (usually from
2013) is now (2017) suffering from bit-rot, as time goes by and things
change.

Adding to what Alex just wrote, RTL hardware is not very robust, and is
prone to overheating. That's why Nooelec offer a dongle in a metal case,
which gets hot, to drain the heat away from the silicon in an effort to
avoid premature death of the chips.

Good luck,

Robin, G8DQX

[Thornton DeRevoires]

Robin,

Thanks for your notes which I found very helpful. I have saved a copy.

In the meantime it has been suggested by another party that this might be a USB power issue. However, I have measured the current drawn by the device and found it to be around 100mA, perhaps dropping a little to 95mA once the unit is initialised. This should be comfortably well within the limits of the USB port to deliver, especially with no other devices connected. Since I have now also tried it on another computer, I am inclined to rule out a power issue.

Testing on another computer gave me exactly the same result. I then added all of the blacklist lines in your notes and this unfortunately made no difference either.

I was also concerned that the software appears not to have been updated for quite some time. This device is an RT820T2 rather than the original RT820 and I did wonder about compatibility. I have uploaded a picture of the device in question. This is more than just the basic dongle in a plastic case. it is enclosed in a quite nice aluminium case and does get slightly warm during operation. I had a quick look at the Nooelec dongles on eBay, but these seem to be quite expensive by comparison, although still much cheaper than some of the purpose built SDR radios.

One rather curious thing with this device is that it identifies itself as idVendor=0bda and idProduct=2838, rather than product ID 2832. I understand that device ID 2838 should refer to an SDR radio with an E4000 tuner. This particular device however, has an RT820T2 tuner, which has been visually confirmed by looking at the IC inside.

Still, all things considered, I don't think rtl_test is able to communicate successfully with the device and since this is confimed on more than one computer. The device seems to get reset and is then no longer detectable and has to be unplugged and then plugged back in to be recognized. I have noticed that the external LED no longer comes on, or just briefly flashes sometimes, but this device has an intenal daughterboard which appears to be the actual SDR dongle board and there is also a LED on this board. That LED does light up and stay on while power is applied. The conclusion would seem to be that the device is faulty in some way and maybe the problem lies with the host board rather than the actual SDR dongle board.

I have contacted the seller but have yet to receive a response.

[David Ranch]

The USB VID and PID only point out high level details and doesn't necessarily point to a E4000 vs RT820T2 tuner.  Anyway, looking up your VID/PID, this guide might help:

   http://www.instructables.com/id/rtl-sdr-on-Ubuntu/

--David
KI6ZHD

[Robin Gape]

You can find USB details at http://www.linux-usb.org/usb.ids, which confirms Realtek as the manufacturer. There is more info at https://www.linuxtv.org/wiki/index.php/RealTek_RTL2832U, which supports the 2832/2838 co-identity.

That page also shows the dmesg trace for a non-blacklisted device.

For a blacklisted system, the trace, use the dmesg command in a terminal, is something like:

[487397.310210] usb 3-1: new high-speed USB device number 12 using xhci_hcd
[487397.339383] usb 3-1: New USB device found, idVendor=0bda, idProduct=2838
[487397.339393] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[487397.339399] usb 3-1: Product: RTL2838UHIDIR
[487397.339403] usb 3-1: Manufacturer: Realtek
[487397.339407] usb 3-1: SerialNumber: 00000001

With luck, that may allow you to diagnose and confirm what is happening.

R.

[Robin Gape]

David,

those instructions are, regrettably, horribly out-of-date! The GRC graph would require modification to run on GNU Radio 3.7. Steps 1 & 2 are overtaken by the far simpler and more reliable GNU radio PPAs installed as part of installing GQRX from PPA. Step 3 on setting up the udev rule still applies. Step 4 does not, for some reason, suggest the easy-to-use rtl_test approach. [Although you seem to be using Centos rather than Ubuntu or a derivative, I'm sure that similar arguments apply to RH-based systems.]

The comments at the bottom betray the instructions as over 5 years old!

That, plus other outdated stuff from the net, was why I put together a 2017 version of how to get an RTL dongle going—if only for my own benefit. That version will also, undoubtedly, have a finite life before bitrot inevitably sets in.

73,

Robin, G8DQX

[Thornton DeRevoires]

David, thanks for that reference. I have already seen it and it was useful background information. I appreciate that the vid and pid are only basic level hardware identifiers. I was just observing that two bits of hardware with different tuners seemed to be sharing the same pid. However I now note from the link provided by Robin, that this is not unexpected. I have not gone as far as installing GNU Radio, only gqrx and rtl_sdr from the MINT/Ubuntu repository. After running gqrx and failing, it seemed to me that the first neccessary step was to successfully run rtl_test to ensure that the hardware is working. However, unfortunately I have been unable to get past this step.

Robin, thanks for the info on the co-identity. That clarifies the matter and I assume therefore that rtl_test must be attempting to determine which tuner is actually present. It seems now to be consistently after several error messages reporting 'No supported tuner found' before a few more error messages and then 'No E4000 tuner found, aborting'. I think rtl_test is not able to find and communicate with the R820T2 for some reason.

The output from dmesg on mine is very similar:

[ 1393.290706] usb 2-1.6: new high-speed USB device number 7 using ehci-pci
[ 1393.394948] usb 2-1.6: New USB device found, idVendor=0bda, idProduct=2838
[ 1393.394953] usb 2-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1393.394956] usb 2-1.6: Product: RTL2838UHIDIR
[ 1393.394958] usb 2-1.6: Manufacturer: Realtek
[ 1393.394960] usb 2-1.6: SerialNumber: 00000001

The only differences I can see is the device numer (which depend on computer hardware configuration and USB port being used) and it is using ehci-pci instead of xhci-pci. Otherwise the output looks pretty much the same. Since your device works, then it would seem to follow that so should mine!

[Thornton DeRevoires]

Well I finally managed to get some output from this device but it is all still very baffling. The seller asked me to re-solder 5 solder points on the back of the board. This initially made no difference. However, later I cleaned the board with IPA and removed every trace of flux as well as a very tiny blob of solder I noticed under the microscope. I then probed with a DMM to make sure power was getting where it was supposed to be and next time I powered it up, the blue LED lit. However this still made no difference until I changed the USB cable.

Now I had already tried this replacement cable, but here we are - this time it worked. So clearly not only did I have a faulty USB cable, but evidently cleaning the board had done something as well.

I tried rtl_test again, and this time got a sensible result:

$ rtl_test

Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 00000001

Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner

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

[R82XX] PLL not locked!
Sampling at 2048000 S/s.

Info: This tool will continuously read from the device, and report if
samples get lost. If you observe no further output, everything is fine.

Reading samples in async mode...
^CSignal caught, exiting!

User cancel, exiting...
Samples per million lost (minimum): 0

At this point I noticed that the LED was not working again, but the receiver was still accessible under Linux, so it seemed worthwhile giving gqrx another go. I got some FM reception, but it was awfull. The signal was weak and disapearing onto the backround noise. I tried an external antenna as well as a random wire. It made no difference. When running HDSDR under Windows this was much worse and I could not get an intelligeable signal, just fractions of voice and lots of noise.

I tried tuning with gqrx into HF frequencies. For this I used the HF antenna socket and an external antenna but found that I could not go tune below 24MHz. With a bit of research I discovered that I had to add direct_samp=2 to the device string, but the program crashes every time I do that. I tried with and without a comma. Once crashes, the other gives no audio and resets the device to 'Other...'

Although I have managed to get something from the receiver, I still think there are unacceptable faults. The received signal is very weak and swamped by noise, the power LED will not stay lit and a faulty USB cable appears to have been supplied, so I will be pursuing a replacement.

In the meantime, can anyone help me with getting gqrx to work with HF? I cannot find any instructions for this anywhere.

Regards.

[Alexandru Csete]

The tool rtl_fm can be used to test actual reception with audio. You
can use that even to test direct sampling.

As for gqrx, you probably need to update to a more recent version than
the one that comes with Mint. You can use out Ubuntu PPA after you
have uninstalled the other packages, see
http://gqrx.dk/download/install-ubuntu

Having said that I would like to point out that personally I have
never had much luck using direct sampling in rtl-sdr.

Alex

> --
> You received this message because you are subscribed to the Google Groups
> "Gqrx SDR" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to gqrx+uns...@googlegroups.com.
> To post to this group, send email to gq...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/gqrx/588cefdb-7529-43bd-9208-1b465ebff557%40googlegroups.com.

[Thornton DeRevoires]

Alexandru,

I managed to update to the latest version following the instructions on the gqrx website and using their PPA. This version now allows me to add the direct_samp=1 or direct_samp=2 parameters, so at least that part is now resolved. Thanks.

Unfortunately my device does not give the expected signal output. Nothing on LW, MW or SW frequencies except high pitched squeals. AFAIKT its not even CW or RTTY so I'm thinking maybe its PLL noise or something. However I'm guessing that this is probably not a software issue.

[Robin Gape]

What sort of an aerial are you using? And where is it? Is the location
urban, suburban or rural? Have you compared the dongle, with the same
aerial, to another receiver?

Robin, G8DQX