571 lines
17 KiB
TeX
571 lines
17 KiB
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}
|