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.
donglecmp3
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.
e4000 sensitivity mode
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.
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).
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.
Over on the SDRSharp Yahoo group, HB9AJG has posted an interesting report in a PDF file containing some measurements (Note you will need to be a member of the group to download the file titled "Some Measurements on E4000 and R820 Tuners.pdf". Here is a Direct Mirror of the file.) quantifying the performance of both the E4000 and R820T RTL-SDR DVB-T dongles. See the discussion in the Yahoo group here.
These results confirm the feeling that many RTL-SDR users have had: that the E4000 is more sensitive in the lower frequencies, and that the R820T is more sensitive in the higher frequencies, which is why it is recommended for ADS-B. The results also show that the R820T is better in terms of Image Rejection and Internal Signal Birdies.
He comprehensively summarizes his results in the following
Image Rejection Because the E4000 is a Direct Conversion Receiver, it has an Image Rejection problem. By switching on Correct IQ in SDR# a more or less acceptable 50dBs are reached. For the same reason, a "hump" shows in the center of the spectrum display. By using a well filtered external power supply (not from the USB connector) the hump might be reduced. Internal signals The E4000 shows many signals actually not present at its input ("birdies"). Birdies are easy to recognize: most of them (except the harmonics of the clock) vary their frequency when moving the spectrum window in frequency. Many of them even move up if you move the window down in frequency.
The R820 is much cleaner in this respect: besides the harmonics of the clock (28.8MHz) only few birdies show up.
Sensitivity Both dongles have a very high sensitivity. Between about 50 and 450MHz the E4000 is about 5dB better than the R820 (-139dBm vs -134dBm). At 1000MHz the E4000 is about 8dB less sensitive (-129dBm vs -137dBm). No measurements could be made above 1040MHz.
Overload and 1dB Compression If a signal is strong enough, it may cause overload, i.e. many (unwanted) signals show up on the spectrum display that are not present at the antenna input. Also, if we listen to a desired signal, another signal (if strong enough) may cause a reduction of the S/N ratio of the desired signal.
Both dongles have a digitally tuned RF filter after the preamplifier that (together with the following digital signal processing) improves the overload/1dB compression limit considerably.
- The filter of the E4000 is about +/-0.8MHz wide, but less steep than the filter of the R820. - The filter of the R820 is about +/-3MHz wide, but steeper than the filterof the E4000.
For the E4000 the overload/1dB compression limit is not linearly dependent of the gain set in Configuration of SDR#: if the gain is reduced by 13/20/30dB, the overload limit is improved by only 7/14/25dB (measured on 145MHz only).
For the R820 the overload/1dB compression limit is quite linearly dependent of the gain set in Configuration of SDR#: if the gain is reduced by 11/20/30dB, the overload limit is improved by 12/20/30dB (measured at 145MHz only).
For both dongles it seems there is nothing to be gained from activating RTL AGC or Tuner AGC.
Intermodulation Intermodulation products in general show up close to the overload/1dB compression limits. However, if the strong signal is on the roll off of the filter, they appear well before this limit.
Aliasing Aliasing always occurs if an insufficiently band limited signal is sampled, i.e. if the signal to be sampled contains frequencies above half the sampling frequency. Thus, aliasing is an effect showing up in many SDRs, not only in these dongles. In both types of dongles there is not much space for brick wall filters. Therefore, aliasing effects are well visible with both dongles.
What do we learn from these tests?
- Both types of dongles are very sensitive. The choice depends on which frequency range you are most interested in.
- Considering internal signals and image rejection, the R820 is much cleaner than the E4000.
- Set the spectrum display of SDRSharp to show a range of not more than 60db above the noise floor. If a signal is close to the top, you know you are close to overload.
- Both types of dongles are prone to overload by strong signals within their filter bandwidth: +/-0.8MHz for the E4000, +/-3MHz for the R820. Therefore, keep signals within this bandwidth to not more than about 60dB above the noise floor by reducing the gain. If increasing the gain does not audibly increase the signal to noise ratio of the desired signal any more, reduce the gain by one step. Do not switch on RTL AGC or Tuner AGC, as it seems there is nothing to be gained.
- Outside their filter bandwidth both types of dongles can live with much higher signals without showing serious degradation. Use the gain control as explained above to check a possible reduction of signal to noise ratio of the desired signal or the appearance of "new" signals not present at the antenna input.
- Intermodulation occurs if several strong signals are present within the bandwidth of the dongle. Their individual power adds up (add 3dB per equally strong signal). Therefore, in frequency bands with many strong signals, e.g. broadcast bands, the gain must be reduced even further. Watch for "new" signals appearing when increasing the gain, and then reduce the gain by one step.
- If very strong signals are present at the antenna input >-40dBm), they should be attenuated by bandstop or notch filters.
YouTube user Superphish has posted a video showing the trick mentioned in this Reddit thread by Anonofish that enables the E4000 tuner to receive a small portion of the broadcast AM band without doing the direct sampling solder mod, or using an upconverter.
It simply involves tuning to a frequency between 3686.6 – 3730 MHz, at which point AM signals start showing up on the spectrum. It isn’t that useful as you can only tune to the very lowest AM stations, but it is still interesting.
Around the world meteorological weather balloons are launched twice daily, and continuously transit weather telemetry to a ground station using something called a radiosonde. The RTL-SDR software defined radio combined with a decoding program can be used to intercept this telemetry, and display it on your own computer. You will be able to see real time graphs and data of air temperature, humidity, pressure as well as the location and height of the balloon as it makes it's ascent.
This tutorial is also applicable to other software defined radios such as the Funcube dongle, Airspy, HackRF, BladeRF or even hardware radios with discriminator taps, but the RTL-SDR is the cheapest option that will work.
Examples
In this example YouTube user Superphish shows a radiosonde being received and decoded using a RTL-SDR, SDRSharp and SondeMonitor.
Weather Balloon (Radiosonde) tracking with RTL SDR (RTL2832), Sondemonitor and SDR Sharp
YouTube user NeedSec has posted a good tutorial video showing how to use Kalibriate-RTL, a program used to determine the frequency offset error of your RTL-SDR dongle. Every RTL-SDR dongle will have a small frequency error as it is cheaply mass produced and not tested for accuracy. This frequency error is linear across the spectrum, and can be adjusted in most SDR programs by entering a PPM (parts per million) offset value.
Kalibrate is a Linux program that uses GSM mobile cell phone base stations to determine the PPM offset, by using the GSM signals own frequency correction bursts. See the tutorial video below.
YouTube user Eric William has posted a useful video explaining the different types of antenna adapters he had to buy (all for under $10) to connect his RTL-SDR (E4000 and R820T) and Ham-it-up upconverter to his antennas.
The RTL-SDR software defined radio can be used to analyze cellular phone GSM signals, using Linux based tools GR-GSM (or Airprobe) and Wireshark. This tutorial shows how to set up these tools for use with the RTL-SDR.
Example - Analysing GSM with RTL-SDR Software Defined Radio
Here is a screenshot and video showing an example of the type of data you can receive. You can see the unencrypted GSM packet information. You will not be able to see any sensitive information like voice or text message data since that part is encrypted. Decryption of messages that are not your own is very difficult, illegal and is not covered in this tutorial.
Analyzing Cellular GSM with RTL-SDR (RTL2832), Airprobe and Wireshark
First, you will need to find out at what frequencies you have GSM signals in your area. For most of the world, the primary GSM band is 900 MHz, in the USA it starts from 850 MHz. If you have an E4000 RTL-SDR, you may also find GSM signals in the 1800 MHz band for most of the world, and 1900 MHz band for the USA. Open up SDRSharp, and scan around the 900 MHz (or 850 MHz) band for a signal that looks like the waterfall image below. This is a non-hopping GSM downlink signal. Using NFM, it will sound something like the example audio provided below. Note down the strongest GSM frequencies you can find.
The rest of the tutorial is performed in Linux and we assume that you have basic Linux skills in using the terminal. For this tutorial we used Ubuntu 14.04 in a VMWare session. You can download the various ready to go Ubuntu VMWare images from here, and the free VMWare player from here. Note that virtual box is reported not to work well with the RTL-SDR, as its USB bandwidth capabilities are poor, so VMWare player should be used.
Plug in your RTL-SDR and connect it to your VM if necessary. Run grgsm_livemon by typing grgsm_livemon at the terminal. A new window should open.
In the new window tune to a GSM downlink frequency which you determined while browsing in SDR# and set the gain appropriately.
Start Wireshark by using sudo wireshark -k -Y '!icmp && gsmtap' -i lo which will automatically start wireshark in the loopback mode with the gsmtap filter activated. You may get an error when opening Wireshark but this can be ignored.
You should now see the GSM data scrolling along in Wireshark.
[expand title = "Old Method using Airprobe (Click to Expand)"]
Install GNU Radio
You will need to install GNU Radio first in order to get RTL-SDR to work. An excellent video tutorial showing how to install GNU Radio in Kali Linux can be found in this video shown below. Note that I had to run apt-get update in terminal first, before running the build script, as I got 404 not found errors otherwise. You can also use March Leech's install script to install the latest version of GNU Radio on any Linux OS. Installation instructions can be found here. I recommend installing from source to get the latest version. http://www.youtube.com/watch?v=B8Acp6_3DA0
Update: The new version 3.7 GNU Radio is not compatible with AirProbe. You will need to install GNU Radio 3.6. However, neeo from the comments section of this post has created a patch which makes AirProbe compatible with GNU Radio 3.7. To run it, place the patch file in your airprobe folder and then run patch -p1 < zmiana3.patch.
Install Airprobe
Airprobe is the tool that will decode the GSM signal. I used multiple tutorials to get airprobe to install. First from this University of Freiberg tutorial, I used their instructions to ensure that the needed dependencies that airprobe requires were installed.
Update: Thanks to shyam jos from the comments section who has let us know that some extra dependencies are required when using the new Kali Linux (1.0.5) for airprobe to compile. If you've skipped installing GNURadio because you're using the new Kali 1.0.5 with SDR tools preinstalled, use the following command to install the extra required dependencies.
git clone git://git.osmocom.org/libosmocore.git
cd libosmocore
autoreconf –i
./configure
make
sudo make install
sudo ldconfig
Clone Airprobe
Now, I discovered that the airprobe git repository used in the University tutorial (berlin.ccc.de) was out of date, and would not compile. From this reddit thread I discovered a more up to date airprobe git repository that does compile. Clone airprobe using the following git command.
git clone git://git.gnumonks.org/airprobe.git
Now install gsmdecode and gsm-receiver.
Install gsmdecode
cd airprobe/gsmdecode
./bootstrap
./configure
make
Install gsm-receiver
cd airprobe/gsm-receiver
./bootstrap
./configure
make
Testing Airprobe
Now, cd into to the airprobe/gsm-receiver/src/python directory. First we will test Airprobe on a sample GSM cfile. Get the sample cfile which I found from this tutorial by typing into terminal.
cd airprobe/gsm-receiver/src/python
wget https://svn.berlin.ccc.de/projects/airprobe/raw-attachment/wiki/DeModulation/capture_941.8M_112.cfile
Note: The tutorial and cfile link is sometimes dead. I have mirrored the cfile on megaupload at this link. Place the cfile in the airprobe/gsm-receiver/src/python folder. Now open wireshark, by typing wireshark into a second terminal window. Wireshark is already installed in Kali Linux, but may not be in other Linux distributions. Since Airprobe dumps data to a UDP port, we must set Wireshark to listen to this. Under Start in Wireshark, first set the capture interface to lo (loopback), and then press Start. Then in the filter box, type in gsmtap. This will ensure only airprobe GSM data is displayed. Back in the first terminal that is in the python directory, type in
./go.sh capture_941.8M_112.cfile
If everything installed correctly, you should now be able to see the sample GSM data in wireshark.
Receive a Live Channel
To decode a live channel using RTL-SDR type in terminal
./gsm_receive_rtl.py -s 1e6
A new window will pop up. Tune to a known non-hopping GSM channel that you found earlier using SDRSharp by entering the Center Frequency. Then, click in the middle of the GSM channel in the Wideband Spectrum window. Within a few seconds some GSM data should begin to show constantly in wireshark. Type ./gsm_receive_rtl.py -h for information on more options. The -s flag is used here to set the sample rate to 1.0 MSPS, which seems to work much better than the default of 1.8 MSPS as it seems that there should be only one GSM peak in the wideband spectrum window.
Capturing a cfile with the RTL-SDR (Added: 13/06/13)
I wasn't able to find a way to use airprobe to capture my own cfile. I did find a way to capture one using ./rtl_sdr and GNU Radio however. First save a rtl_sdr .bin data file using where -s is the sample rate, -f is the GSM signal frequency and -g is the gain setting. (rtl_sdr is stored in 'gnuradio-src/rtl-sdr/src')
Next, download this GNU Radio Companion (GRC) flow graph (scroll all the way down for the link), which will convert the rtl_sdr .bin file into a .cfile. Set the file source to the capture.bin file, and set the file output for a file called capture.cfile which should be located in the 'airprobe/gsm-receiver/src/python' folder. Also, make sure that 'Repeat' in the File Source block is set to 'No'. Now execute the GRC flow graph by clicking on the icon that looks like grey cogs. This will create the capture.cfile. The flow chart will not stop by itself when it's done, so once the file has been written press the red X icon in GRC to stop the flow chart running. The capture.cfile can now be used in airprobe. However, to use this cfile, I found that I had to use ./gsm_receive.py, rather than ./go.sh as a custom decimation rate is required. I'm not sure why, but a decimation rate of 64 worked for me, which is set with the -d flag.
./gsm_receive.py -I rtl_sdr_capture.cfile -d 64
[/expand]
Going Further with Decryption
We don't cover how to decode the actual encrypted GSM data here, but this is possible to do with messages going to your own phone once you extract the encryption code for your sim card. But note that if you want to do this you'll need to put in some good study and research into understanding how GSM actually works before you can even think about trying it. Disclaimer: Only decrypt signals that you are legally allowed to (such as from/to your own cell phone) to avoid breaching privacy.
A reader wrote in to let us know some information on obtaining the TMSI and Kc numbers, which are useful if you wish to go further and actually decode messages coming from your own phone. He writes:
For some reason, most of posts on the Internet concerning GSM sniffing provide very few examples of how to get our own TMSI and Kc numbers. These rely either on the BlackBerry engineering screen or the use of a SIM-card reader (see for example http://domonkos.tomcsanyi.net/?p=369). I know there are other methods like the one you describe in www.rtl-sdr.com/rtl-sdr-cell-phone-imsi-tmsi-key-sniffer/.
However, I have rarely seen anything related to the Android IMSI-Catcher Detector app. This can be easily installed via the standard repositories and it allows us to send AT commands to the modem provided we root the MS. This procedure works on many devices (I checked it on a Motorola Moto E).
Just a quick reminder of the basic AT+commands:
1. Extraction of IMSI -> AT+CRSM=176,28423,0,0,3.
2. Extraction of Ciphering Key Kc -> AT+CRSM=176,28448,0,0,9 (for SIM), AT+CRSM=176,20256,0,0,9 (for USIM). First 16 entries.
3. Extraction of TMSI -> AT+CRSM=176,28542,0,0,11. First 8 entries.
The Android IMSI-Catcher Detector provides some additional interesting data, like the cell ID the device is connected to, the LAI, etc.
We note that software such as SimSpyII together with a Sim Card reader can also be used to easily acquire the Kc value.
If you enjoyed this tutorial you may like our book available on Amazon. Available in eBook and paperback formats.
First, you will need to find out at what frequencies you have GSM signals in your area. For most of the world, the primary GSM band is 900 MHz, in the USA it starts from 850 MHz. If you have an E4000 RTL-SDR, you may also find GSM signals in the 1800 MHz band for most of the world, and 1900 MHz band for the USA. Open up SDRSharp, and scan around the 900 MHz (or 850 MHz) band for a signal that looks like the waterfall image below. This is a non-hopping GSM downlink signal. Using NFM, it will sound something like the example audio provided below. Note down the strongest GSM frequencies you can find. 
