path: root/2012/rtlsdr-freedomhec2012/rtl-sdr.tex

% $Header: /cvsroot/latex-beamer/latex-beamer/solutions/conference-talks/conference-ornate-20min.en.tex,v 1.7 2007/01/28 20:48:23 tantau Exp $

\documentclass{beamer}

\usepackage{url}
\makeatletter
\def\url@leostyle{%
  \@ifundefined{selectfont}{\def\UrlFont{\sf}}{\def\UrlFont{\tiny\ttfamily}}}
\makeatother
%% Now actually use the newly defined style.
\urlstyle{leo}


% This file is a solution template for:

% - Talk at a conference/colloquium.
% - Talk length is about 20min.
% - Style is ornate.



% Copyright 2004 by Till Tantau <tantau@users.sourceforge.net>.
%
% In principle, this file can be redistributed and/or modified under
% the terms of the GNU Public License, version 2.
%
% However, this file is supposed to be a template to be modified
% for your own needs. For this reason, if you use this file as a
% template and not specifically distribute it as part of a another
% package/program, I grant the extra permission to freely copy and
% modify this file as you see fit and even to delete this copyright
% notice. 


\mode<presentation>
{
  \usetheme{Warsaw}
  % or ...

  \setbeamercovered{transparent}
  % or whatever (possibly just delete it)
}


\usepackage[english]{babel}
% or whatever

\usepackage[latin1]{inputenc}
% or whatever

\usepackage{times}
\usepackage[T1]{fontenc}
% Or whatever. Note that the encoding and the font should match. If T1
% does not look nice, try deleting the line with the fontenc.


\title{rtl-sdr}

\subtitle
{Turning USD 20 Realtek DVB-T receiver into a SDR}

\author{Harald Welte <laforge@gnumonks.org>}

\institute
{gnumonks.org\\hmw-consulting.de\\sysmocom GmbH}
% - Use the \inst command only if there are several affiliations.
% - Keep it simple, no one is interested in your street address.

\date[] % (optional, should be abbreviation of conference name)
{June 12, FreedomHEC, Taipei}
% - Either use conference name or its abbreviation.
% - Not really informative to the audience, more for people (including
%   yourself) who are reading the slides online

\subject{Communications}
% This is only inserted into the PDF information catalog. Can be left
% out. 



% If you have a file called "university-logo-filename.xxx", where xxx
% is a graphic format that can be processed by latex or pdflatex,
% resp., then you can add a logo as follows:

% \pgfdeclareimage[height=0.5cm]{university-logo}{university-logo-filename}
% \logo{\pgfuseimage{university-logo}}



% Delete this, if you do not want the table of contents to pop up at
% the beginning of each subsection:
%\AtBeginSubsection[]
%{
%  \begin{frame}<beamer>{Outline}
%    \tableofcontents[currentsection,currentsubsection]
%  \end{frame}
%}


% If you wish to uncover everything in a step-wise fashion, uncomment
% the following command: 

%\beamerdefaultoverlayspecification{<+->}


\begin{document}

\begin{frame}
  \titlepage
\end{frame}

\begin{frame}{Outline}
  \tableofcontents[hideallsubsections]
  % You might wish to add the option [pausesections]
\end{frame}


% Structuring a talk is a difficult task and the following structure
% may not be suitable. Here are some rules that apply for this
% solution: 

% - Exactly two or three sections (other than the summary).
% - At *most* three subsections per section.
% - Talk about 30s to 2min per frame. So there should be between about
%   15 and 30 frames, all told.

% - A conference audience is likely to know very little of what you
%   are going to talk about. So *simplify*!
% - In a 20min talk, getting the main ideas across is hard
%   enough. Leave out details, even if it means being less precise than
%   you think necessary.
% - If you omit details that are vital to the proof/implementation,
%   just say so once. Everybody will be happy with that.

\begin{frame}{About the speaker}
\begin{itemize}
	\item Using + toying with Linux since 1994
	\item Kernel / bootloader / driver / firmware development since 1999
	\item IT security expert, focus on network protocol security
	\item Former core developer of Linux packet filter netfilter/iptables
	\item Board-level Electrical Engineering
	\item Always looking for interesting protocols (RFID, DECT, GSM)
	\item OpenEXZ, OpenPCD, Openmoko, OpenBSC, OsmocomBB, OsmoSGSN
\end{itemize}
\end{frame}


\begin{frame}{Disclaimer}
\begin{itemize}
	\item This talk is not about the Linux kernel
	\item This talk is not about consumer mass market
	\item It's about turning a single-purpose device into many more features
	\item ... and to illustrate the creativity unleashed when hardware / chipset makers don't lock their devices down
\end{itemize}
\end{frame}

\section{Software Defined Radio}

\subsection{Traditional radio receivers vs. SDR}

\begin{frame}{Traditional Radio}
\begin{itemize}
	\item uses hardware-based receiver + demodulator
	\item uses analog filtering with fixed filters for given
		application
	\item recovers either analog signal or digitizes demodulated bits
	\item has not changed much in close to 100 years of using radio
		waves for communications
\end{itemize}
\end{frame}

\begin{frame}{Software Defined Radio (SDR)}
\begin{itemize}
	\item uses a more or less classic radio fronted / tuner to
		down-convert either to IF or to baseband
	\item uses a high-speed ADC to digitize that IF or baseband
		signal
	\item uses digital signal processing for filtering,
		equalization, demodulation, decoding
\end{itemize}
\end{frame}

\begin{frame}{SDR advantages vs. traditional radio}
\begin{itemize}
	\item more flexibility in terms of communication system
	\item as long as tuner input frequency, ADC sampling rate and
		computing power are sufficient, any receiver can be
		implemented in pure software, without hardware changes
	\item this is used mostly by military (JTRS, SCA) and commercial
		infrastructure equipment (e.g UMTS NodeB / LTE eNodeB)
\end{itemize}
\end{frame}

\subsection{How the industry normally uses SDR}

\begin{frame}{SDR technology in consumer electronics}
\begin{itemize}
	\item lots of consumer devices already implement SDR technology
	\begin{itemize}
		\item GSM/UMTS/LTE baseband processor in mobile phones
		\item WiFi, Bluetooth, GPS
	\end{itemize}
	\item flexibility of such implementations is restricted to
		manufacturer, as low-level access to DSP code and/or raw
		samples is not intended / documented / activated
	\item user is locked out from real benefits and flexibility of SDR
\end{itemize}
\end{frame}

\begin{frame}{Existing SDR hardware marketed as SDR}
\begin{itemize}
	\item regular consumer-electronics SDR don't provide low-level
		access or documentation
	\item military / telco grade SDR device are way too expensive
		(five-digit USD per unit)
	\item Ettus developed the famous USRP family (four-digit USD per
		unit). Used a lot in education + research
	\item Even lower-cost devices now like Fun Cube Dongle Pro
		(FCDP) or OsmoSDR  (three-digit USD per unit)
\end{itemize}
\end{frame}

\subsection{How the community wants to use SDR}

\begin{frame}{Universal Software Radio Peripheral}
\begin{itemize}
	\item A general-purpose open-source hardware SDR
	\begin{itemize}
		\item Schematics and component placement information public
	\end{itemize}
	\item Generally available to academia, professional users and individuals
	\item Modular concept
	\begin{itemize}	
		\item Mainboard contains Host PC interface and baseband codec
		\item Daughter boards contain radio frontend with rf up/downconverter
	\end{itemize}
	\item Big step forward in pricing, but still not affordable for everyone
	\begin{itemize}
		\item USD~700 for mainboard
		\item frontends from USD~75 to USD~250
	\end{itemize}
\end{itemize}
\end{frame}

\begin{frame}{USRP Circuit Board Photograph}
\begin{figure}[h]
	\centering
	\includegraphics[width=55mm]{usrp_board_photo.jpg}
\end{figure}
\end{frame}

\begin{frame}{USRP Block Diagram}
\begin{figure}[h]
	\centering
	\includegraphics[width=75mm]{usrp-block-diagram.png}
\end{figure}
\end{frame}

\begin{frame}{USRP technical specs}
\begin{itemize}
	\item $4\times$ 12~bit ADCs @ 64~MS/s (digitize band of up to 32~MHz)
	\item $4\times$ 14~bit DACs @ 128~MS/s (useful output freq from DC...44~MHz)
	\item $64\times$ Digital I/O ports, 16 to each daughter-board
	\item The USRP mainboard has 4 slots for daughter-boards (2 Rx, 2 Tx)
	\item transceiver frontends occupy 2 slots (1 Rx, 1 Tx)
\end{itemize}
\end{frame}

\begin{frame}{The second generation USRP: USRP2}
Main differences from USRP1
\begin{itemize}
	\item Gigabit Ethernet replacing USB2 (full-duplex, 1~GBit/sec)
	\item 25~MHz of instantaneous RF bandwidth
	\item Xilinx Spartan 3-2000 FPGA
	\item $2\times$ 100~MHz 14~bit ADC
	\item $2\times$ 400~MHz 16~bit DAC
	\item 1~MByte high-speed SRAM
	\item Clock can be locked to external 10~MHz reference
	\item 1~pulse-per-second input (GPS clock conditioning)
	\item FPGA configuration can be stored on SD card
	\item Stand-alone operation without host PC
	\item Multiple systems can be connected for MIMO
	\item Daughterboards compatible with USRP(1)
\end{itemize}
\end{frame}

\begin{frame}{Fun Cube Dongle Pro (2010)}
\begin{itemize}
	\item 64 MHz to 1700 Mhz USB SDR receiver (193 USD)
	\item limited to 96 kHz I/Q baseband sampling
	\item great for amateur radio and TETRA, but most other
communications systems (like GSM introduced in 1992) use wider band-widths
	\item great progress in terms of size and cost, but much more
limited than USRP
	\item Hardware design and firmware sadly are proprietary
\end{itemize}
\end{frame}

\begin{frame}{Fun Cube Dongle Pro (2010)}
\begin{figure}[h]
	\centering
	\includegraphics[width=110mm]{fcdp_pcb.jpg}
\end{figure}
\end{frame}


\begin{frame}{OsmoSDR (2012)}
\begin{itemize}
	\item small, low-power / low-cost USB SDR hardware (225 USD)
	\item higher bandwidth than FunCubeDonglePro (1.2 MHz / 14bit)
	\item much lower cost than USRP, but more expensive than FCDP
	\item Open Hardware (schematics), software (FPGA, firmware)
\end{itemize}
\begin{figure}[h]
\centering
\includegraphics[width=70mm]{osmosdr.jpg}
\end{figure}
\end{frame}



\section{Gnuradio Software Defined Radio}

\subsection{Gnuradio SDR Architecture}

\begin{frame}{Gnuradio architecture}
\begin{itemize}
	\item Philosophy: Implement SDR not as hand-crafted special-case hand-optimized assembly code in some obscure DSP, but on a general purpose PC
	\begin{itemize}
		\item with modern x86 systems at multi-GHz clock speeds and with many cores this becomes feasible
		\item of course way too expensive for a mass-produced product, but very suitable for research, teaching and rapid prototyping
	\end{itemize}
	\item Implement various signal processing elements in C++
	\begin{itemize}
		\item assembly optimized libraries for low-level operations
		\item provide python bindings for all blocks
	\end{itemize}
	\item Python script to define interaction, relation, signal~routing between blocks
\end{itemize}
\end{frame}

\subsection{Gnuradio blocks and flow graphs}

\begin{frame}{Gnuradio blocks and flow graphs}
\begin{description}[flow graph]
	\item[block] represents one element of signal processing
	\begin{itemize}
		\item filters, adders, transforms, decoders, hardware interfaces
	\end{itemize}
	\item[flow graph] defines routing of signals and interconnection of blocks
	\begin{itemize}
		\item Think of it as the {\em plumbing} between the blocks
	\end{itemize}
\end{description}
Data passing between blocks can be of any C++ data type
\end{frame}

\begin{frame}{GRC flow graph for Wideband FM}
\begin{figure}[h]
	\centering
	\includegraphics[width=110mm]{grc_wbfm.png}
\end{figure}
\end{frame}

\begin{frame}{GRC flow graph for SSB}
\begin{figure}[h]
	\centering
	\includegraphics[width=100mm]{ssb_rcv_grc.png}
\end{figure}
\end{frame}


\subsection{Gnuradio sinks and sources}

\begin{frame}{Gnuradio sinks and sources}
\begin{description}[source]
	\item[sink] special block that consumes data
	\begin{description}[hardware sinks]
		\item[hardware sinks] USRP, Sound card, COMEDI
		\item[software sinks] Scope UI, UDP port, Video card
	\end{description}
	\item[source] special block that sources data
	\begin{description}[hardware sources]
		\item[hardware sources] USRP, Sound card, COMEDI
		\item[software sources] Noise source, File, UDP port
	\end{description}
\end{description}
Every flow graph needs at least one sink and one source!
\end{frame}

\section{Finally: rtl-sdr}

\subsection{The Realtek RTL2832U and its primary application}

\begin{frame}{Realtek RTL2832U based DVB-T receivers}
\begin{itemize}
	\item Realtek RTL2832U based DVB-T receivers are cheaply
		available on the market (USD 20)
	\item RTL2832U implements ADC, DVB-T demodulator and high-speed
		USB device
	\item Normal mode of operation includes full DVB-T receiver
		inside RTL2832U hardware and only sends MPEG2-TS via USB
	\item Realtek released GPL-licensed Linux kernel driver for
		watching TV (not mainline style, but at least GPL)
	\item Realtek released limited manual to V4L developers
\end{itemize}
\end{frame}

\begin{frame}{RTL2832U based devices: EzTV 668}
\begin{figure}[h]
	\centering
	\includegraphics[width=110mm]{ezcap_top.jpg}
\end{figure}
\end{frame}

\begin{frame}{RTL2832U based devices: Hama nano1}
\begin{figure}[h]
	\centering
	\includegraphics[width=110mm]{hama_nano1.jpg}
\end{figure}
\end{frame}

\begin{frame}{RTL2832U based devices}
\begin{itemize}
	\item more than 20 different devices from various vendors
	\item Brand names include ezcap, Hama, Terratec, Compro, GTek, Lifeview, Twintech, Dexatek, Genius, Gigabyte, Dikom, Peak, Sveon
	\item all based on the identical RTL2832U reference design
	\item only major difference is mechanical shape/size and silicon
tuner used.  Best tuner we know is Elonics E4000 (high frequency range)
\end{itemize}
\end{frame}

\begin{frame}{RTL2832U FM and DAB radio}
\begin{itemize}
	\item Some people realized certain windows drivers for RTL2832U
		based products implement FM Radio, others even DAB
	\item Linux driver had no FM radio or DAB support
	\item Realtek-disclosed limited data sheet didn't mention it
		either
	\item Sniffing USB protocol on Windows revealed that raw samples
		are passed from ADC over USB, FM or DAB demodulation
		happens in x86 software.
	\item Realtek didn't provide documentation or source code for
		this on request
\end{itemize}
\end{frame}

\begin{frame}{RTL2832U towards rtl-sdr}
\begin{itemize}
	\item Reverse engineering the USB protocol and replaying certain
		commands from custom libusb based code was able to trigger the raw
		sample transmission
	\item remaining Realtek driver provided information on how to
		use the I2C controller to control the tuner frontend
	\item Harald already developed Elonics E4000 driver for
		osmo-sdr, which could be re-cycled
	\item Tuning to arbitrary frequencies allows digitizing spectrum
		of any communications system within the tuner range
\end{itemize}
\end{frame}

\begin{frame}{RTL2832U towards rtl-sdr}
\begin{itemize}
	\item {\em librtlsdr} contains the major part of the driver
	\item {\em rtl\_sdr} command line capture tool
	\item {\em gr-osmosdr} gnuradio source block
	\item Homepage: http://sdr.osmocom.org/trac/wiki/rtl-sdr
	\item libusb is portable, there even are pre-built windows
		binaries
\end{itemize}
\end{frame}

\subsection{Some of the software supporting rtl-sdr}

\begin{frame}{rtl-sdr software support}
\begin{itemize}
	\item gnuradio (of course), using gr-osmosdr
	\item gr-pocsag (POCSAG pagers)
	\item simple\_fm\_rcv (FM receiver)
	\item python-librtlsdr / pyrtlsdr (generic python bindings)
	\item QtRadio
	\item qgrx
	\item rtl\_fm
	\item SDR\#
	\item gr-air-modes 
	\item tetra\_demod\_fft (TETRA radio)
	\item airprobe (GSM receiver)
\end{itemize}
\end{frame}

\begin{frame}{Free Software SDR Receivers}
Full FOSS receivers/demodulators/decoders available for
\begin{itemize}
	\item Old analog modes like AM/FM/WFM/SSB
	\item DAB (Digital Audio Broadcasting)
	\item GSM downlink + uplink (airprobe)
	\item TETRA downlink (OsmocomTETRA)
	\item ETSI GMR / Thuraya (OsmocomGMR)
	\item P25 (OsmocomOP25)
	\item AIS (Maritime transponders)
	\item Gen2 UHF RFID
	\item DECT (Digital European Cordless Telephony)
\end{itemize}
\end{frame}


\begin{frame}{Who needs all of this?}
\begin{itemize}
	\item Students learning about digital signal processing
	\item Radio Amateurs
	\item Communications (security) resarchers
	\item Anyone interested in building their own software radio
		receivers
\end{itemize}
This is of course not the 100k / million quantity consumer mass market.
But nonetheless, definitely thousands to tens of thousands
\end{frame}

\subsection{Signal Plots}

\begin{frame}{rtl-sdr: Multi-Carrier TETRA}
\begin{figure}[h]
	\centering
	\includegraphics[width=110mm]{tetra.png}
\end{figure}
\end{frame}

\begin{frame}{rtl-sdr: ETSI GMR (Thuraya Satphone)}
\begin{figure}[h]
	\centering
	\includegraphics[width=110mm]{rtl-sdr-gmr.png}
\end{figure}
\end{frame}

\begin{frame}{rtl-sdr: GPS (after filter / LNA)}
\begin{figure}[h]
	\centering
	\includegraphics[width=110mm]{gps-sps2048e3.png}
\end{figure}
\end{frame}

\begin{frame}{rtl-sdr: inmarsat (after LNA)}
\begin{figure}[h]
	\centering
	\includegraphics[width=75mm]{inmarsat.png}
\end{figure}
\end{frame}


\begin{frame}{Thanks}
I'd like to thank the many Osmocom developers and contributors,
especially
\begin{itemize}
	\item Steve Markgraf
	\item Dimitri Stolnikov
	\item Hoernchen
	\item Sylvain Munaut
\end{itemize}
also, Realtek for providing at least some (DVB oriented) documentation
and for releasing GPL licensed code for their hardware in the first
place.
\end{frame}


\begin{frame}{Thanks}
Thanks for your attention.  I hope we have time for Q\&A.
\end{frame}


\end{document}