SRTN Testing with NooElec R820T SDR & DVB T NESDR Mini - BenningtonCS/Telescope-2014 GitHub Wiki

Results indicate that using this device will be successful. The below will be edited and improved as additional testing continues.

Useful Resources

NooElec USB R820T product page

Osmocom 3rd party software (uses same rtlsdr lib as SRTN)

RealTek RTL2832U info

Dongle Recognition

When the USB is plugged in, using the lsusb command should reveal the device:

~$ lsusb
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 003 Device 002: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 003 Device 003: ID 047d:1029 Kensington Mouse*in*a*Box Optical Elite
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 0ac8:c444 Z-Star Microelectronics Corp. 
Bus 001 Device 004: ID 0bda:0129 Realtek Semiconductor Corp. 
Bus 001 Device 005: ID 8087:07da Intel Corp. 
Bus 002 Device 003: ID 17ef:6018 Lenovo

Where in this case, it recognizes the device as Bus 003 Device 002: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T. While the chipset is a RTL2832U, the product name is RTL2838, which is why it shows up as RTL2838.

Test with Osmocom rtl-sdr Library

Thusfar, one method seems to show some promise, so I will detail the procedure below so I don't forget it...

From this website, the instructions are more or less laid out. First, however, you must get cmake if you do not already have it

~$ sudo apt-get install cmake

Once this finishes, we can continue with the directions on the site, also listed below.

~$ git clone git://git.osmocom.org/rtl-sdr.git
~$ cd rtl-sdr/
~/rtl-sdr$ mkdir build
~/rtl-sdr$ cd build
~/rtl-sdr/build$ cmake ../
~/rtl-sdr/build$ make
~/rtl-sdr/build$ sudo make install
~/rtl-sdr/build$ sudo ldconfig

This should get all the files you need and compile them. From here, you can

~/rtl-sdr/build$ cd src

and you will see the programs it comes with that can be run. Currently I'm looking into rtl_test.

rtl_test

Running the test:

~/rtl-sdr/build/src$ sudo ./rtl_test

Currently yields the results:

~/rtl-sdr/build/src$ sudo ./rtl_test
Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 00000001

Using device 0: Generic RTL2832U OEM

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
Failed to open rtlsdr device #0.

So, we know that the program recognizes and identifies the USB Dongle, but it appears that something is currently accessing it. Later I will try to figure out what this is and see if I can get the test to run successfully.

After blacklisting what the prompt said to blacklist (dvb_usb_rtl28xxu),

$ sudo -i
$ echo "blacklist dvb_usb_rtl28xxu" > /etc/modprobe.d/librtlsdr-blacklist.conf

and restarting the computer, I ran the srt_test script again and got the results:

~/rtl-sdr/build/src$ sudo ./rtl_test 
[sudo] password for edaniszewski: 
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 
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...

Which seems good!! It recognizes the device and seemingly is able to interface with it. Next I will run a test to try and capture data at a certain radio frequency.

Test with SRTN

As it turn out, the MIT Haystack code utilizes the rtl-srt library as well, so similarities exist between SRTN and the test method described above.

Editing the frequency range in SRTN program

The program defaults to around 1420.406 MHz, and for no good reason won't let you assign an arbitrary frequency too far off from that. After looking at the source briefly, I believe if you change the FREQUENCY fields in the srt.cat file, the frequency range will change. It definitely changes the displayed frequency on the GUI and on PS images made, but it is still unclear if it changes the frequency it is receiving behind the scenes, as the 'noise' pattern in the graph remains similar to the one observed at 1420 MHz (seen in picture below)