Blogger and ham radio enthusiast F4GKR has written a brief tutorial post on his blog showing how he got an RTL-SDR working with an Aria G25, and in another post some benchmarking results. The Aria G25 is a very small low cost, Linux capable embedded computer, similar to the Raspberry Pi.
He was able to get rtl_tcp running with a 2 MSps sampling rate and found it used about 60% of the CPU.
To help you decide which of the recently released software defined radios is right for you, blogger Taylor Killian has written an article discussing and comparing the HackRF, BladeRF and new USRP models.
The HackRF, BladeRF and USRP are all high end SDRs which range in cost from $300 (HackRF) to $1100 USD (USRP B210). They differ from the RTL-SDR in that each is specifically designed for the purpose of software defined radio, and they all have large bandwidths and transmit capabilities.
A new command line wideband spectrum monitor utility called ‘rtl_power’ has been released by keenerd on Reddit. See the original thread here. This tool let’s you gather signal data over a very wide area of the frequency spectrum, and then that data can be used to find active areas of the spectrum.
Rtl_power is a small CLI tool for logging wide swaths of bandwidth. You can specify any chunk of spectrum, with any FFT bin size and any logging rate. (For sane values of any.)
For example
rtl_power -f 150M:200M:2k -i 10 logfile.csvwill monitor everything between 150MHz and 200MHz. The resolution will be at least 2kHz fine. It will integrate for 10 seconds and dump those numbers to the logfile. The structure of the logfile is:
date, time, Hz low, Hz high, Hz step, samples, dbm, dbm, ...So it is not quite the traditional CSV file. Each frequency hop gets its own line and the frequencies of each column are extrapolated.
Coupled with a python script, a heatmap can be generated from the excel data.
I’m scanning the region between 150MHz and 160MHz, where there is local emergency services chatter. Each pixel is 10kHz wide and 10 seconds long, over a period of seven hours
This is command line tool is somewhat similar to the Scanner Metrics SDRSharp plugin, which allows large areas of the frequency spectrum to be monitored from within SDRSharp.
A few days ago we posted a video by sm5bsz showing some comparisons between the E4000, R820T and FC0013 tuners, and also a comparison between the special linearity gain mode driver in Linrad and standard Osmocom driver in SDRSharp.
Now sm5bsz, programmer of Linrad and the special gain modes for the E4000 has done another test using only Linrad, which more fairly demonstrates the difference between the various tuners, and the effect of the special gain drivers in Linearity mode. He writes
In this video RTL2832 dongles are compared for sensitivity, spurs and intermodulation. The difference between the Linrad linearity mode and the original Osmocom gain setting is demonstrated as well as spurs in R820T and FC0013.
Which one to prefer depends on the local RF Environment and whether a selective filter is used between the antenna and the dongle.
Note: The Linrad vs SDRSharp video has been removed by the uploader.
Finally in this video, he also compares the standard Osmocom driver to the sensitivity mode available in the modified gain profile drivers. He writes
The sensitivity mode has very poor performance for signals far away from the passband, but it allows about 10 dB better dynamic range for interferences within the passband. Sensitivity mode is for usage with a selective preamplifier while the Osmocom gain mode is a reasonable compromise. The Linrad linearity gain mode is for use without filters in difficult RF Environments.
Linrad can be downloaded from here and the modified Osmocom drivers with linearity and sensitivity gain profiles for the E4000 can be downloaded here. SDRSharp can also use the modified Osmocom drivers with Linearity and Sensitivity modes with this plugin by Zefie.
In this video YouTube user ek6rsc shows a timelapse of meteor reflection observations during the yearly Perseids meteor shower which occurred in 2013 during August 10-15. To do this he uses an R820T RTL-SDR tuned to 59.25 MHz, and the HROFFT software to do the recording.
Meteors entering the atmosphere can cause radio frequency reflections which may allow extremely distant radio signals to be received briefly. Reception of such a signal may be a good indicator that a meteor has fallen. A good informational guide on meteor scatter with the RTL-SDR can be found in this pdf file by Marcus Leech.
The 28.8 MHz crystal oscillator on the RTL-SDR is known for being low quality. A low quality crystal means that the frequency tuning can be off by a few KHz and can cause the tuned frequency to drift over time.
In this article of the GBPPR ‘Zine (kindly mirrored by superkuh), the authors show a tutorial on how a cheap high quality 14.4 MHz temperature compensated crystal oscillator can be combined with a frequency doubler circuit to create a high quality 28.8 MHz clock source, which can then be used to replace the low quality oscillator on the RTL-SDR. A 14.4 MHz oscillator is used as high quality 28.8 MHz oscillators appear to be rare.
Over on Pawel Janowski’s blog (SQ7MRU) a writeup on how to set up an APRS iGate receiver with an RTL-SDR and cubieboard mini computer has been posted. The article has been written in Polish, but can be translated using Google Translate.
APRS stands for Automatic Packet Reporting System and is usually used by Amateur radio operators to broadcast the current GPS coordinates of something such as a transmitter site/car/boat or high altitude amateur balloon. These APRS packets are received by an iGate and then put onto the internet. Check out aprs.fi for an example.
To create an APRS iGate, Pawel runs a RTL-SDR compatible python program called pymultimonaprs which is used to receive and broadcast the APRS data on to the internet.
On YouTube sm5bsz has uploaded a video showing a comparison between the E4000, R820T and FC0013 tuners, and also comparing the receive performance of SDRSharp and Linrad. In the video Linrad showed superior receive performance with the E4000 when compared to SDRSharp due to some custom gain profiles which are enabled in Linrad only (but can also be enabled in SDRSharp with a plugin/mod).
Note that the reason Linrad showed better performance is purely due to the fact that he used a modified librtlsdr driver in Linrad which has the custom gain profiles. However, in a previous post we posted about a modification/plugin to SDRSharp which allows this modified librtlsdr to be used, which will allow SDRSharp to perform as well as Linrad for the E4000.
Linrad is another software defined radio program which is much more difficult to use, but was the first program to support the modified librtlsdr. Some people prefer Linrad due to it’s advanced GUI which has a lot of signal information on display.
