Home » Electronics

Category Archives: Electronics

Network Backups via Rsync and Rsnapshot

Network Backups via Rsync and Rsnapshot (via www.jeffskinnerbox.me)
I got a 4 Terabyte Seagate Backup Plus hard drive as a Christmas present and I plan to put it to use as a central backup for my Linux desktop, multiple Raspberry Pi, my laptop, and anything else that my come along. My plan is to keep things simple but I wish to do regular hourly, daily, weekly, and monthly incremental backups. This will give me the ability to recover files from the past, but also to recover from a hardware failure or software install that has gone very badly.

There are many backup tools you can pick from but I wanted to stick with something basic, widely used, and simple. Rsync is one of the most widely used Linux backup solutions, and in fact, it is often used by other backup tools as a foundational component. Rsync stands for remote synchronization tool. Rsync is a UN*X command line utility, containing a special protocal and algorithm, that synchronizes files and directories from one location to another while minimizing data transfer by using fast incremental file transfers. (rsync has also been ported to Microsoft Windows, Mac, and other operating systems.) The first time, rsync sends all the data over the network to your backup machine. The benefit comes the next time you backup………


Having Fun with Wine, VirtualBox, and TurboTax

Having Fun with Wine, VirtualBox, and TurboTax (via www.jeffskinnerbox.me)

Sometime ago, I committed myself to Linux and Wine, with the promise that I would sincerely abandon Microsoft Windows by notdual booting my system nor installing any virtualization software. Well, it is now tax-time and the Federial goverment wants their “fair share” of my income. Will my prefered tax software package, TurboTax, run with Linux & Wine? All the evidence I have gathered (see Wine’s ratings for one data point) on the web leads me to believe I will be very disapointed. I can’t find any success stories! Never the less, I will use this as a learning opportunity. I’m going to plung forward and try to get TurboTax working with Wine, …. and it it fails me, resort to VirtualBox, which appears to have at least some success stories…..


IPython Notebook in Virtualenv

IPython Notebook in Virtualenv (via www.jeffskinnerbox.me)
I discovered a problem with using nbconvert for posting IPython Notebooks to my blog. Basically it doesn’t work for my version of IPython, so I looked for an upgrade. I found it but its only delivered bundled with the latest version of IPython. Currently, I’m stuck with using IPython 0.13.2 on my Ubuntu system, at least if I use the distribution provide via Ubuntu. And I can only expect to have problems if I try mixing an older version of IPython with the latest version of nbconvert.

I sure Ubuntu will be getting around to supporting the latest version of IPython (i.e. IPython 1.1.0). in the next few weeks to months, but that doesn’t help me now. I’m hesitant to do a whole sale upgrade of IPython on my system since it my upset other thing I got going on.

The answer to my dilemma will be using the Python Org tool virtualenv (see this for full documentation). This tool will give me a virtual environment that will not disrupt my other projects. Virtualenv is a tool to create isolated Python environments, quite likechroot jail on Unix systems. In a chroot, programs cannot access anything outside of chroot but in virtualenv as the name implies, it creates isolated environments only with respect to libraries, but the programs can still access the files and folders normally. With this, I can support my blog IPython 1.1.0 while also maintaining my other projects which requires IPython 0.13.2……


I’m Moving so I can Blog with IPython Notebook

I have moved to www.jeffskinnerbox.me

Signals & Systems for Dummies

Signals & Systems for Dummies

To gain a deeper understanding of the GNU Radio software, I want to rebuild some skills & insights in digital signal processing.  But before I take on this topic, I want to refresh my signals & systems skills I learned long ago while in college.  I have chosen Mark Wickert’s book, Signals and Systems For Dummies, to do this.

Learning IPython for Interactive Computing and Data Visualization

Learning IPython for Interactive Computing and Data Visualizatio

Go ahead and laugh if you wish, but I got good reasons for choosing this book. I like its brevity, since I don’t want to spend a great deal of time re-honing these old skills (I expect them to come back quickly), and its use of IPython will help me master a powerful tool that I foresee using within this blog; specifically the IPython Notebook.  To begin learning IPython, I’m currently reading Learning IPython for Interactive Computing and Data Visualization by Cyrille Rossant.  So it’s currently “back to school” for me on many levels.

IPython Notebook Spectrogram

Example of a IPython Notebook

So this brings me to the topic of this posting.  Initially I considered moving my blog off of WordPress.com to a WordPress.org hosting site.  This should allow me to post IPython Notebook pages.  WordPress.com  is very restrictive on what you can do with your blog, but the WordPress software, when  self hosted via WordPress.org, can provide you a great deal of blogging freedom.  I need to take advantage of some of the powerful WordPress Plugins and WordPress.com will not support any of them.  Moving to a self-hosted WordPress blog doesn’t appear to be very difficult.  The biggest trick will be picking the right web hosting company that is strong WordPress supporter who will make it easily move my blog from WordPress.com to WordPress.org.

I then took a closer look at how others have successfully using IPython Notebook for blogging.   I took a very close look at Carl Boettiger’s online Lab Notebook.  This introduced me to GitHub Pages and Jekyll.   With these tools you can create an archived, static site that is hosted for free.  I saw the synergy between these tools and how I work with my Linux box, electronics, and now IPython and its seemed like the way to go. The site “Learning Jekyll By Example: Build a Jekyll Website, Start to Finish” says it well:

    • Jekyll can be hosted on any web hosting service that serves static files.
    • Jekyll-powered websites are also extremely secure.
    • Jekyll is mainly targeted at tech-savvy bloggers.
    • But what Jekyll lacks in newbie-friendliness it makes up for in power and flexibility.
    • Jekyll allows you, the content author, to display your work as you see fit, without the typical restrictions imposed by other blogging platforms.

Continues at the new site … www.jeffskinnerbox.me

GNU Radio and Gqrx SDR Receiver

grc logoIn my last post, I was using the RTL2832 TV tuner dongle to get a simple Software Defined Radio (SDR) operational.  I wanted to use the SDR# program as my receiver but found that the MS Windows tool would not work and so I targeted Gqrx as an alternative. Gqrx is dependent on the GNU Radio.  So in this post, I plan to get Gqrx and GNU Radio up and operational with the RTL-SDR dongle.  I spend some time with other tools to help further verify (with mixed success) that GNU Radio is working.

The contain here comes from multiple source and I attempt to list those sources below.  For a good video to get a sense of what your in for, check out this video. Also, this post covers many of the topics here.

GNU Radio is a free & open-source software development toolkit that provides signal processing blocks to implement software defined radios. It can be used with readily-available low-cost external RF hardware to create software-defined radios, or without hardware in a simulation-like environment. It is being used in hobbyist, academic, and commercial environments to support both wireless communications research and real-world radio systems. 

Gqrx is an experimental AM, FM and Single Side Band (SSB) software defined receiver implemented using GNU Radio and the Qt GUI toolkit. Currently it works on Linux and can use the RTL_SDR dongles as input source.

Also within this post, I venture out from gqrx to examine a few other tools.  I don’t cover much territory, nor have much success.  The insperation to examine these other tools comes mainly from the lengthy post “RTL-SDR and GNU Radio with Realtek RTL2832U [Elonics E4000/Raphael Micro R820T] software defined radio receiver“.  Also check out “Getting Started with GNU Radio and RTL-SDR (on Backtrack)“.

Build GNU Radio on Ubuntu

The GNU Radio web site has specific instructions and a build script for installing it on Ubuntu (I’m using version 13.04).  This process claims it may take 1-2 hours to do the install (for me it ran in 1 hour 14 minutes).  The steps are as follows:

cd ~/src
mkdir ~/gnuradio
cd ~/gnuradio
wget http://www.sbrac.org/files/build-gnuradio && chmod a+x ./build-gnuradio && ./build-gnuradio --verbose

When prompted, tell it to proceed and give it sudo privilege by typing “Y”. Because of the --verbose option, you will see a lot of text whizzing by as the build-gnuradio script does its thing. You’ll also see a percentage complete indicator as the script works its way down it tasks.

The GNU Radio build creates a large variety of tools which get installed into /usr/local/bin.  You also notice that tools not directly related to GNU Radio are also created. I’ll leave it for another time to understand and explain the GNU Radio environment.

The “Hello World” of GNU Radio

To verify that the software is working, best thing is to create the typical “Hello, World” program, just we might have done for our first foray into C++, Python, or other programming language.  In the world of GNU Radio, this program has come to be the phone dial tone. To do this, I followed the video The “Hello World” of GNU Radio: Dial Tone and the gnuradio.org.  I did this using the GNU Radio Companion (executable located at /usr/local/bin/gnuradio-companion).  GNU Radio Companion (GRC) is a graphical tool for creating signal flow graphical models and generating Python source code for the model created.

GRC’s generated flow and code for the “Hello, World” program is listed below. The Python code for the dial tone program was placed in the home directory, and in my case, it was called dail_tone.py. While it can be executed via the gnuradio-companion, it can also be executed via python dial_tone.py. The user interface for the GRC and the corresponding Python code it generated is listed below:

dial_tone.grc - -home-jeff - GNU Radio Companion_006

#!/usr/bin/env python
# Gnuradio Python Flow Graph
# Title: Dial Tone
# Author: Jeff Irland
# Description: "Hello, World" program - produces phone dial tone
# Generated: Sat Jun 22 21:24:56 2013

from gnuradio import analog
from gnuradio import audio
from gnuradio import blocks
from gnuradio import eng_notation
from gnuradio import gr
from gnuradio import window
from gnuradio.eng_option import eng_option
from gnuradio.gr import firdes
from gnuradio.wxgui import fftsink2
from gnuradio.wxgui import forms
from gnuradio.wxgui import scopesink2
from grc_gnuradio import wxgui as grc_wxgui
from optparse import OptionParser
import wx

class dial_tone(grc_wxgui.top_block_gui):

	def __init__(self):
		grc_wxgui.top_block_gui.__init__(self, title="Dial Tone")
		_icon_path = "/usr/share/icons/hicolor/32x32/apps/gnuradio-grc.png"
		self.SetIcon(wx.Icon(_icon_path, wx.BITMAP_TYPE_ANY))

		# Variables
		self.samp_rate = samp_rate = 32000
		self.noise_slider = noise_slider = .005

		# Blocks
		_noise_slider_sizer = wx.BoxSizer(wx.VERTICAL)
		self._noise_slider_text_box = forms.text_box(
		self._noise_slider_slider = forms.slider(
		self.wxgui_scopesink2_0 = scopesink2.scope_sink_f(
			title="Scope Plot",
		self.wxgui_fftsink2_0 = fftsink2.fft_sink_f(
			title="FFT Plot",
		self.blocks_add_xx_0 = blocks.add_vff(1)
		self.audio_sink_0 = audio.sink(32000, "pulse", True)
		self.analog_sig_source_x_1 = analog.sig_source_f(samp_rate, analog.GR_COS_WAVE, 350, .1, 0)
		self.analog_sig_source_x_0 = analog.sig_source_f(samp_rate, analog.GR_COS_WAVE, 440, .1, 0)
		self.analog_noise_source_x_0 = analog.noise_source_f(analog.GR_GAUSSIAN, noise_slider, 0)

		# Connections
		self.connect((self.blocks_add_xx_0, 0), (self.wxgui_scopesink2_0, 0))
		self.connect((self.blocks_add_xx_0, 0), (self.audio_sink_0, 0))
		self.connect((self.analog_sig_source_x_0, 0), (self.blocks_add_xx_0, 2))
		self.connect((self.analog_sig_source_x_1, 0), (self.blocks_add_xx_0, 1))
		self.connect((self.analog_noise_source_x_0, 0), (self.blocks_add_xx_0, 0))
		self.connect((self.blocks_add_xx_0, 0), (self.wxgui_fftsink2_0, 0))

	def get_samp_rate(self):
		return self.samp_rate

	def set_samp_rate(self, samp_rate):
		self.samp_rate = samp_rate

	def get_noise_slider(self):
		return self.noise_slider

	def set_noise_slider(self, noise_slider):
		self.noise_slider = noise_slider

if __name__ == '__main__':
	parser = OptionParser(option_class=eng_option, usage="%prog: [options]")
	(options, args) = parser.parse_args()
	tb = dial_tone()

When the GRC flow execution button is pressed, the scope and FFT plots are are created as shown below:

Dial Tone_005

The build for GNU Radio also installs the RTL-SDR software, so it would be wise to test GNU Radio with the RTL_SDR hardware and make sure everything is operating as expected.  I want to make a simple FM receiver, comparable to what was done via rtl_fm in RTL-SDR – Software Defined Radio (SDR) for $20. Something equivalent to:

rtl_fm -W -f 99.5M | play -r 32k -t raw -e signed-integer -b 16 -c 1 -V1 -

Using the following postings as a guide:

I had sufficient success to convince myself that GNU Radio was work.

Building Gqrx on Ubuntu

Gqrx is a software defined AM, FM and SSB software defined radio receiver for RTL-SDR based dongles (as well as the Universal Software Radio Peripherals and Osmo SDR devices).  It features a  Qt GUI.  As a QT program, you’ll need to make sure you have QT4 installed (version 5 will not work) and that you have the qtcreator tool is installed:

sudo apt-get install qt4-default
sudo apt-get install phonon-backend-gstreamer

Now download the source for Gqrx via its page on GitHub  and extract it into your target directory. The posting Getting Started With RTL-SDR and the README on the GitHub site where useful in understanding how to do the install.  I did the following:

cd ~/src
git clone git://github.com/csete/gqrx.git
cd gqrx
qmake gqrx.pro

At this point, you should find the gqrx executable in ~/src/gqrx directory.  Start up via ./gqrx and you’ll get the screen below (or set your values to equal this):

Configure I-O devices_001

Click “OK” and the screen below will pop up.  Make sure you have the RTL-SDR dongle plugged in and select the button on the top left to start processing data.  I have tuned the radio to a local FM station at 85.7MHz and listen to Washington Nationals vs. Phillies baseball!

Gqrx 0.0 - rtl=0_004

Building Multimode Radio Receiver

This radio receiver is capable of demodulating muitiple modes, specifically AM, FM, USB, LSB , WFM. TV-FM, PAL-FM. It’s easy to use and  has an automated scanning and spectral zoom features where clicking on the spectrogram or panorama to tune to the frequency of interest.

Multimode documentation is sparse to non existent. The posts “Using the Realtek RTL2832 USB “dongle” as a gnuradio multimode receiver” and “RTL-SDR and GNU Radio with Realtek RTL2832U [Elonics E4000/Raphael Micro R820T] software defined radio receiver” and “Getting Started with GNU Radio and RTL-SDR (on Backtrack)” gave some important hints on how to install multimode and get it operational.  I did the following:

cd ~
svn co https://www.cgran.org/svn/projects/multimode/trunk/ ~/src/multimode
make install

When I executed multimode.py, it didn’t product a display.  I suspect its some subtle Python code problem, or more likely.  incompatibility with the latest GNU Radio libraries.  For now, I’m going to abandon this.

GNU Radio Signal Scanner

gr-scan is a program  built upon GNU Radio, rtl-sdr, and the OsmoSDR Source Block.  This receiver constantly changes frequencies in a set order looking for a frequency that has someone transmitting. It is intended to scan a range of frequencies and print a list of discovered signals.  Installation involved the following steps:

cd ~./src
mkdir gr-scan
cd gr-scan

with your browser, download: http://www.techmeology.co.uk/gr-scan/gr-scan-2012082301.tar.gz
gzip -d gr-scan-2012082301.tar.gz
tar -xvvf gr-scan-2012082301.tar
cd gr-scan-2012082301

When I attempted to do the make, it complained about missing Gun Radio files.  I suspect the GNU Radio libraries and include files are layed out differently since the time gr-scan was designed (August of 2012).  I’m leaving fixing this to another time.

What’s Next

In this and the previous SDR posts, I focused on getting a taste of the technology without committing myself to much of an effort.  I really need to study and understand the tools that I have assembled. I still need to do a great deal more studying of  the radio spectrum itself … I feel like I’m wondering in the dark most of the time.

Also, I feel that I’m very limited by the antenna I’m presently using (the pitiful dipole that came with the RTL dongle).  I’m thinking of building a better antenna.  Maybe try to pickup a NOAA weather satellites, with its distinctive audio signal when demodulated, and decode one of its satellite weather photos …. maybe.

Another problem with the RTL-SDR is that its internal oscillator is cheap  and drifts, resulting in clock errors with  many kHz of frequency display error in SDR – depending on a band you’re listening to.  This is very annoying if you use your dongle as a radio scanner – what’s the point of knowing frequency of a transmitter if it’s almost random on your SDR?   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.  So I need to calculate this error offset so I can  calibrate the SDR software.

RTL-SDR – Software Defined Radio (SDR) for $20

While researching the GNU Radio project, I came upon references to the RTL2832 TV tuners. These dongle are made to receive and decode the European standard digital television, Digital Video Broadcasting — Terrestrial (DVB-T). (By the way, the North American standard is Advanced Television Systems Committee (ATSC), and not  compatible with DVB-T, so this will not work in North America for TV reception.)  In 2012, Antii Palosaari, discovered that there is a device mode for the Realtek DVB-T device chip (RTL2832U) in which raw samples can be captured and transferred to a host computer. This feature enables this device to be used as an inexpensive “front end”  for a Software Defined Radio (SDR) that could be implemented on a PC or other device.

A SDR provide the ability to sample and record the electromagnetic energy (or radio frequency, called “RF” for short) with no preconceived idea as to the structure of the RF signal.  In a sense, you can interact with the RF signal in its must fundamental form.  In addition, a SDR allows you to implement, by means of software, a radio communication system where components that have been typically implemented in hardware.

SDR solutions for the professional-grade applications and amateur radio have been around for some time, but the appearance of cheap solutions for the hacker is new.  There are general purpose SDR platforms for over $1000, like the Ettus Research Universal Software Radio Peripheral (USRP), the $525 SDR-IQ Receiver, to the $450 bladeRF from the Kickstarter Nuand or Great Scott’s DARPA-Funded HackRF for an estimate $300, and now the $20 hacker grade dongle discussed here.  But unlike most of the other referenced solutions,  the dongle  requires a PC, or some sort of attached processor, to provide the signal processing.

In all SDR solutions, a significant amounts of the signal processing is handed over to a numerical processor, rather than being done in special-purpose RF hardware. Such a design produces a radio which can receive and transmit widely different radio protocols (referred to as a waveform) based solely on the software used.  So in a SDR solution, the electromagnetic waveform is rapidly sampled, the sample values are converted to numerical values, and these numbers are manipulated via a discipline called digital signal processing (DSP).  Ultimately, the resulting DSP numerical values produced are converted to an analog signal that goes to a speaker, TV, or other such output device.

The DVB-T dongles can provide a critical component of a cheap SDR, since the chip allows transferring the raw I/Q samples to the host. What I/Q samples are is well beyond what I wish to describe here, but let it be said that practical hardware design concerns make I/Q data the critical for signal processing.  So the fact the dongle does the digital sampling, called a analog-to-digital converter (ADC), and outputs I/Q samples, makes it a valuable asset for a SDR solution.

So how does one get your PC configured to take the dongles I/Q output and create a SDR?  There is GNU Radio (where this post first begun), but a simpler starting point would be the popular, easy, and open source SDR#.  SDR# can perform the required signal processing in an intuitive user interface (if your into Ham Radio, or bit of a RF hacker, and such).  Unfortunately, I couldn’t get SDR# (a MS Windows application) to operate under  Linux and I had to resorted to some simpler utilities.

The Dongle

All this sounds exciting to me (what a geek!) so I purchased from Amazon one of the dongles, specifically the NooElec TV28T v2 USB DVB-T,  FM+DAB & RTL-SDR Receiver, RTL2832U & R820T Tuner, MCX Input.


NooElec TV28T

    • NooElec TV28T – This is the manufacture and model name for the device
    • DVB-T – This device is made to receive and decode the European standard digital television, Digital Video Broadcasting — Terrestrial (DVB-T)
    • FM+DAB & RTL-SDR Receiver – The device can also receive FM radio and Digital Audio Broadcasting (DAB) used in several countries, particularly in Europe. RTLSDR is the popular name give to this class of device, which contain the RTL2832U chip, which can be hacked for SDR use.
    • RTL2832U & R820T Tuner – These are the DVB-T demodulator and TV Tuner chips used in the device.
    •  MCX Input – Is a 3.6 millimeter (0.14 in) micro coaxial (MCX) coaxial RF connector 30% smaller that Sub-Miniature version B (SMB) connectors that are typically used in the USA.  MCX is a standard in Europe. It provides broadband capability from DC to 6 GHz.

From the research I have done, I have found that this dongle provides an approximate tuning range of 25MHz-1700MHz for the SDR.  It has been demonstrated to be compatible with most SDR software, including SDR#.  You can pick up FM radio but  don’t expect to pick up long-wave or AM broadcasts since their spectrum lies below 25MHz. You can listen to the 12m 10m 6m 2m 1.25m 70cm 33cm and 23cm ham band, as well as CB, Marine VHF, RC Band, FRS, GMRS, and Airband (Aviation).

The dongle will not provide the desired SDR function out of the box.  It must first be configured (aka hacked) to stream the I/Q samples to the USB output.  This is where Antii Palosaari’s discovery comes into play.  The wiki’s rtlsdr.org and OsmoSDR are good sources for disparate information concerning RTL2832U based SDR, typically called RTL-SDR.  For my purposes, I wanted to get something initially working on my PC (Linux OS) but ultimately I wanted to have the dongle attached to a Raspberry Pi (RPi) and have the RPi be a server or archive of I/Q samples (sort of a intelligent wide band scanner as done in Raspberry Pi and DVB-T receivers and here Raspberry Pi as Remote Server for RTL2832u SDR and here SDR with Raspberry Pi and DVB-T receivers) that could be processed by my PC.  Therefore, the first step is to get the dongle and a good SDR processor working on my PC.

Building rtl-sdr Library and Capture Tools

The  OsmoSDR wiki has some good instructions on how to build the rtl-sdr software. I basically followed the wiki’s instructions but I had to first install cmake (sudo apt-get install cmake) and libusb (sudo apt-get install libusb-1.0-0-dev) to get a successful make.  I then using the following commands:

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

The result is source code placed in ~/src/rtl-sdr/build/src and the executables are placed in /usr/local/bin: rtl_adsb, rtl_eeprom, rtl_fm, rtl_sdr, rtl_tcp, rtl_test.  The documentation for these utilities is nearly non-existent.  The only documentation I could fine is for the rtl_fm, a posting called Rtl_fm Guide: The long lost documentation.  If you use the command line option --help, you will get some description for each of the tools (see the very end of this post for some screen captures).  Here is a short description and some example usages:

    • rtl_sdr – This is an I/Q recorder for RTL2832 based DVB-T receivers. To send 10 samples to stdout, and sampled at 1.8Ms/s with frequency tuned to 392MHz: rtl_sdr -s1.8e6 -f392e6 -n10 -.
    • rtl_test – Bench-marking tool for RTL2832 based DVB-T receivers.  The -t option only works for Elonics E4000 tuners (Therefore, on non-E4000 tuners, you can not test for the tuning range).  To check the possible tuning range: rtl_test -t.  To check the maximum sample-rate possible on your machine (change the rate down until no sample loss occurs): rtl_test -s 2.5e6
    • rtl_fm – A simple narrow band FM demodulator for RTL2832 based DVB-T receivers.  Rtl_fm is a general purpose analog demodulator. It can handle FM, AM and SSB. It can scan more than a hundred frequencies a second. Make sure rtl_fm and the player are both set to use the same data rate.  Tune into a local FM radio station : rtl_fm -W -f 99.5M | play -r 32k -t raw -e signed-integer -b 16 -c 1 -V1 -
    • rtl_tcp –  An I/Q sample server for RTL2832 based DVB-T receivers.  I/Q samples are streamed to a specified IP address and port.
    • rtl_adsb – A simple Automatic dependent surveillance-broadcast (ADS-B) decoder.  ADS-B is a surveillance technology for tracking aircraft as part of the Next Generation Air Transportation System (NextGen).
    • rtl_eeprom – An EEPROM programming tool for RTL2832 based DVB-T receivers.

First Run of the Dongle

The first thing to do is to plug in the dongle and run the test rtl_test -t.  It gave me an error statement expressing “installing the udev rules file rtl-sdr.rules”.  The site “rtl-sdr on Ubuntu” provides some instructions on how to fix this.  The command lsusb | grep Realtek gives me the information I need to create the following entry into /etc/udev/rules.d:

SUBSYSTEM=="usb", ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="2838", GROUP="adm", MODE="0666", SYMLINK+="rtl_sdr"

After another try, I got a successful test.  Next, I sent ten I/O samples to stdout and then tuned into a local FM radio station using these commands:

rtl_sdr -s1.8e6 -f392e6 -n10 -
rtl_fm -W -f 99.5M | play -r 32k -t raw -e signed-integer -b 16 -c 1 -V1 -


SDR Sharp

Getting SDR# Running in Linux (didn’t work)

The  rtlsdr.org wiki has some instructions on how to get SDR# working within Linux.  Also, the SDR# home page has a link called One shot install script for Linux. Both these sites require you to build the software from source code. Mono is able to run Microsoft .NET applications in Linux.  I attempted this and got errors that I could not figure out (I’m not a MS Windows developer type and I’m not interested becoming one!).

Given this, I chose a different path. I found another posting that claim to get SDR# running in Linux. In this case, only executable will be loaded, not source code that needs to be compiled. You can download SDR# executable from this posting.  You’ll also need to install mono and PortAudio.  Here is how I did it:

sudo apt-get install mono-complete monodevelop
sudo apt-get install libportaudio2
cd ~/src
mkdir sdrsharp
cd sdrsharp

Within ~/src/sdrsharp, install the downloaded SDR# zip file and unzip it.

cd sdr-nightly
ln -s /usr/local/lib/librtlsdr.so librtlsdr.dll
ln -s /usr/lib/i386-linux-gnu/libportaudio.so.2 libportaudio.so

Note, for the above link, you may need to use locate libportaudio.so.2 to find the PortAudio library.

To test things out, I ran the application using mono sdrsharp.exe and got a core dump.  I attempted this again using the stable version of SDR# instead of the nightly build and got the same results.  After the typical thrashing about, I found a bug report for this problem.  Also see “SDR Software – Good, bad and very ugly“.  Also, there seems to be some sort of dispute between SDR# and a new group calling itself Open SDR#.  I’m not sure, but what appears to be at the heart of this is the level of support of SDR# within Linux.  All this is disappointing since SDR# is a very popular tool and I wish I could find away to make use of it within Linux.

The next logical SDR tool to try would be the Linux-based Gqrx SDR receiver, but in this case, it is dependent on GNU Radio.  I’m attempting to delay my conquest of GNU Radio until I do some experimenting with the dongle.  So lets turn our attention to a much simpler tool.

Getting RTLSDR Scanner Running

RTLSDR Scanner is a simple frequency scanning GUI using the OsmoSDR rtl-sdr library.  I more or less followed the installation instructions but they are confusing/out-of-date and you’ll needed to do some adjustments.  The OsmoSDR rtlsdr library has already been installed earlier in the text, so its not listed here.  To get the required files for RTLSDR Scanner:

sudo apt-get install python python-wxgtk2.8 python-matplotlib python-numpy
cd ~/src
git clone git://github.com/roger-/pyrtlsdr.git
cd pyrtlsdr
sudo setup.py
cd ~/src
git clone git://github.com/EarToEarOak/RTLSDR-Scanner.git

With this, I found I could run ~/src/pyrtlsdr/demo_waterfall.py.  Make sure to read the comments in the file to understand how to change the center frequency, gain, etc.  The image below is demo_waterfall.py tuned to the amateur radio 6 meters band.  The image is called a spectrogram (sometimes call spectral waterfall) is a dynamic, visual representation of the spectrum of frequencies in the RF signal.  Blue is low signal strength, where yellow, and red are higher strengths.



To get ~/src/RTLSDR-Scanner/src/rtlsdr_scan.py to work, I had to do some coping of files as shown below:

cp ~/src/pyrtlsdr/rtlsdr/rtlsdr.py  ~/src/RTLSDR-Scanner/src/rtlsdr.py
cp ~/src/pyrtlsdr/rtlsdr/librtlsdr.py  ~/src/RTLSDR-Scanner/src/librtlsdr.py

The image below is from rtlsdr_scan.py, again tuned to the amateur radio 6 meters band.  Here again you see the signal strength of the individual amateur radios as vertical spikes.



So we now have auditory and visual proof the dongle is doing its job. Now its on to GNU Radio!

Command-Line Options for RTLSDR Capture Tools

For reference purposes, below are screen shots of the RTLSDR capture tool’s command line options.

rtl_test -s

rtl_test -s











A Better Mobile Display for the Raspberry Pi

2013-04-10 20.37.23

iSSH Terminal Session

As I described in an earlier post, I run my Raspberry Pi (RPi) as a headless system, using Cygwin/X‘s xterm for command line interaction with the RPi, with my PC being my X server to support any X Window applications.  I can move files between the PC and the RPi via my pseudo-Dropbox.  I really recommend this configuration and its working perfectly for me.

This configuration gives me a great deal of utility but no mobility …. I’m still tied to my desktop PC.  Maybe I should consider replacing the desktop PC with a laptop but I don’t want to spend the money.  I have seen some small,  inexpensive keyboards and displays that could be connected directly to the RPi, and you could cobble together a mobile unit, or the more elegant Kindle version, but this still doesn’t give me the mobility look & feel I would like.

iPad to the rescue (assuming you have one ….)!   I found a great app call iSSH by Zingersoft.  Its claims that it is a “comprehensive VT100, VT102, VT220, ANSI, xterm, and xterm-color terminal emulator over SSH and telnet, integrated with a tunneled X server, RDP and VNC client. ”   I installed it, configured it quickly, and got  a terminal connection to the RPi without reading the documentation …. Impressive since successfully configuring ssh, Xserver, etc. can be challenging sometimes.  (Note: The easy of this was largely due to setting up RPi environment properly in the first place. See the earlier post).  To top it off, iSSH has a slick look & feel.

Configuring iSSH

iSSH X Server Session

iSSH X Server Session

Zingersoft’s documentation on configuring iSSH is easy to follow and requires just a few steps.  I had no problem getting an terminal session working to the RPi but I did have problems with graphics programs (i.e. X Window client programs).  It appears that iSSH’s terminal isn’t really xterm but a terminal emulation (secured via ssh).  The iSSH terminal doesn’t use the X server.  In fact, while in the terminal session,  to see the X server display (i.e. to see graphics applications rendered via the RPi X client) you must hit the button at the top right of the iPad display.

Frankly, the fact that the X application didn’t work the first time wasn’t a big surprise to me.  I have been struggling with getting my X Window configuration set up to work reliably for some time.  What I was observing was that X would work fine for sometime but at some point I would get the error message “couldn’t connect to display”.

This error is very common and nearly every X user has seen some version of this before.  I assume that the right way to solve this was to gain a deeper understanding of X Windows and discover its root cause .  I did gain a deeper understanding of X Windows, but a solution to my problem never jumped out from the “official” materials I read.  I found the solution when I happened upon the blog “X11 Display Forwarding Fails After Some Time“.

The root cause of my error message is the time out of the X Forwarding.  I have been using the -X option when using ssh.  This is the more secure option for X Forwarding, but comes at a price, as shown below.

    • Using ssh -X, X forwarding is enabled in “Untrusted” mode, making use of various X security extensions, including a time-limited Xauth cookie.
    • Use ssh -Y to enable “Trusted” mode for X, which will enable complete access to your X server. There is no timeout for this option.

So my Display problem isn’t really an error, per say, but ssh timing out on me.  To fix this, I added the entry ForwardX11Timeout 596h into my ~/.ssh/config file on my PC.  With this problem solved, I continued my journey into X.

My Journey to a Better Understanding of X

Using X Windows for the first time can be somewhat of a shock to someone familiar with other graphical environments, such as Microsoft Windows or Mac OS.  X was designed from the beginning to be network-centric, and uses a “client-server” model. In the X model, the “X server” runs on the computer that has the keyboard, monitor, and mouse attached. The server’s responsibility includes tasks such as managing the display, handling input from the keyboard and mouse, and other input or output devices (i.e., a “tablet” can be used as an input device, and a video projector can be an output device, etc.). Each X application (such as xterm) is a “client”. A client sends messages to the server requesting things like “Please draw a window at these coordinates”, and the server sends back messages such as “The user just clicked on the OK button”. These standardized set of messages make up the X Protocol.

The X server and the X clients commonly run on the same computer. However, it is perfectly possible to run the X server on a less powerful computer (e.g. in my case a PC or iPad), and run X applications (the clients) on a powerful machine that serves multiple X servers (or it can be a simple RPi, as in my case). In this scenario the communication between the X client and server takes place over the network (WiFi for my iPad), via the X Protocol. There is nothing in the protocol that forces the client and server machines to be running the same operating system, or even to be running on the same type of computer.

The Display

It is important to remember that the X server is the is the software program which manages the monitor, keyboard, and pointing device. In the X window system, these three devices are collectively referred to as the “display”.  Therefore, the X server serves displaying capabilities, via the display, to other programs, called X clients, that connect to  the X server.  All these connections are established via the X protocol.

The relationship between the X server and the display are tight, in that the X server is engineered to support a specific display (or set of displays).  As a user of X, you don’t have any control over this relationship, only the software developer who created the server can modify this relationship (generally speaking).  On the other hand, as a user you have free hand in configuring the X protocol connection between the X server and the X clients.

How do you establish a X Protocol connection between any given server and a client?  This is done via the environment variable “DISPLAY”.  A Linux environment variable DISPLAY tells all its X clients what display they should use for their windows. Its value is set by default in ordinary circumstances, when you start an X server and run jobs locally. Alternatively, you can specify the display yourself.  One reason to do this is when you want log into another system, and run a X client there, and but have the window displayed at your local terminal.  That is, the DISPLAY environment variable must point to your local terminal.

So the environment variable “DISPLAY” stores the address for X clients to connect to. These addresses are in the form: hostname:displaynumber.screennumber where

    • hostname is the name of the computer where the X server runs. An omitted hostname means the localhost.
    • displaynumber is a sequence number (usually 0). It can be varied if there are multiple displays connected to one computer.
    • screennumber is the screen number. A display can actually have multiple screens. Usually there’s only one screen though where 0 is the default.

Setting the DISPLAY variable depends of your shell, but for the Bourne, Bash or Korn shell, you could do the following to connect with the systems local display:

export DISPLAY=localhost:0.0

The remote server knows where it have to redirect the X network traffic via the definition of the DISPLAY environment variable which generally points to an X Display server located on your local computer.

X Security

So you see, as the user, you have full control over where you wish to display the X client window.   So what prevents you from doing something malicious,  like popping up window on someone else  terminal or read their key strokes?  After all, all you really need is their host name.  X servers have three ways of authenticating connections to it: the host list mechanism (xhost) and the magic cookie mechanism (xauth). Then there is ssh, that can forward X connections, providing a protected connection between client and server over a network using a secure tunnelling protocol.

The xhost Command

The xhost program is used to add and delete host (computer) names or user names to the list of machines and users that are allowed to make connections to the X server. This provides a rudimentary form of privacy control and security.  A typical use is as follows: Let’s call the computer you are sitting at the “local host” and the computer you want to connect to the “remote host”. You first use xhost to specify which computer you want to give permission to connect to the X server of the local host. Then you connect to the remote host using telnet. Next you set the DISPLAY variable on the remote host. You want to set this DISPLAY variable to the local host. Now when you start up a program on the remote host, its GUI will show up on the local host (not on the remote host).

For example, assume the IP address of the local host is and the IP address of the remote host is

On the local host, type the following at the command line:

xhost +

Log on to the remote host


On the remote host (through the telnet connection), instruct the remote host to display windows on the local host by typing:

export DISPLAY=

Now when you type xterm on the remote host, you should see an xterm window on the local host.  You should remove the remote host from your access control list as follows.

xhost -

Some additional xhost commands:

xhost    List all the hosts that have access to the X server
xhost + hostname    Adds hostname to X server access control list.
xhost - hostname    Removes hostname from X server access control list.
xhost +     Turns off access control (all remote hosts will have access to X server … generally a bad thing to do)
xhost -    Turns access control back on (all remote hosts blocked access to X server)

Xhost is a very insecure mechanism. It does not distinguish between different users on the remote host. Also, hostnames (addresses actually) can be spoofed. This is bad if you’re on an untrusted network.

The xauth Command

Xauth allows access to anyone who knows the right secret. Such a secret is called an authorization record, or a magic cookie. This authorization scheme is formally called MIT-MAGIC-COOKIE-1.  The cookies for different displays are stored together in the file .Xauthority in the user’s home directory (you can specify a different cookie file with the XAUTHORITY environment variable).  The xauth application is a utility for accessing the .Xauthority file.

On starting a session, the X server reads a cookie from the.Xauthority file. After that, the server only allows connections from clients that know the same cookie (Note: When the cookie in .Xauthority changes, the server will not pick up the change.).  If you want to use xauth, you must start the X server with the -auth authfile argument.   You can generate a magic cookie for the .Xauthority file using the utility mcookie (typical usage: xauth add :0 . `mcookie`).

Now that you have started your X session on the server and have your cookie in .Xauthority, you will have to transfer the cookie to the client host. There are a few ways to do this.  The most basic way is to transfer the cookie manually by listing the magic cookie for your display with xauth list and injecting it into the remote hosts .Xauthority via the xauth utility.

Xauth has a clear security advantage over xhost. You can limit access to specific users on specific computers and it does not suffer from spoofed addresses as xhost does.

X Over SSH

Even with the xhost and xauth methods, the  the X protocol is transmitted over the network with no encryption.  If you’re  worried someone might snoop on your connections (and you should worry), use ssh.  SSH, or the Secure Shell, allows secure (encrypted and authenticated) connections between any two devices running SSH. These connections may include terminal sessions, file transfers, TCP port forwarding, or X Window System forwarding.  SSH supports a wide variety of encryption algorithms. It supports various MAC algorithms, and it can use public-key cryptography for authentication or the traditional username/password.

SSH can do something called “X Forwarding” makes the communication secure by “tunneling” the X protocol over the SSH secure link.  Forwarding is a type of interaction with another network application, through a inter-mediator, in this case SSH. SSH intercepts a service request from some other program on one side of an SSH connection, sends it across the encrypted connection, and delivers it to the intended recipient on the other side. This process is mostly transparent to both sides of the connection: each believes it is talking directly to its partner and has no knowledge that forwarding is taking place.  This is called tunneling since X protocol is encapsulated within the a SSH protocol.

When setting up an SSH tunnel for X11, the Xauth key will automatically be copied to the remote system(in a munged form to reduce the risk of forgery) and the DISPLAY variable will be set.

To turn on X forwarding over ssh, use the command line switch -X or write the following in your local ssh configuration file:

Host remote.host.name
ForwardX11 yes

The current version of SSH supports the X11 SECURITY extension, which provides two classes of clients: trusted clients, which can do anything with the display, and untrusted clients, which cannot inject synthetic events (mouse movement, keypresses) or read data from other windows (e.g., take screenshots). It should be possible to run almost all clients as untrusted, leaving the trusted category for screencapture and screencast programs, macro recorders, and other specialized utilities.

If you use ssh -X remotemachine the remote machine is treated as an untrusted client and ssh -Y remotemachine the remote machine is treated as trusted client.  ‘-X’ is supposedly the safe alternative to ‘-Y’.  However, as a Cygwin/X maintainer says “this is widely considered to be not useful, because the Security extension uses an arbitrary and limited access control policy, which results in a lot of applications not working correctly and what is really a false sense of security”.

You can configuring SSH via the following files:

    • per-user configuration is in ~/.ssh/config
    • system-wide client configuration is in /etc/ssh/ssh_config
    • system-wide daemon configuration is in /etc/ssh/sshd_config

The ssh server (sshd) at the remote end automatically sets DISPLAY to point to its end of the X forwarding tunnel. The remote tunnel end gets its own cookie; the remote ssh server generates it for you and puts it in~/.Xauthority there. So, X authorization with ssh is fully automatic.

X over SSH solves some of the problems inherent to classic X networking. For example, SSH can tunnel X traffic through firewalls and NAT, and the X configuration for the session is taken care of automatically. It will also handle compression for low-bandwidth links.  Also, if you’re using X11 forwarding, you may want to consider setting ForwardX11Trusted no to guard against malicious clients.

The Window Manager

The X design philosophy is much like the Linux/UNIX design philosophy, “tools, not policy”.  This philosophy extends to X not dictating what windows should look like on screen, how to move them around with the mouse, what keystrokes should be used to move between windows, what the title bars on each window should look like, etc.  Instead, X delegates this responsibility to an application called a “Window Manager”.

There are many window managers available for X and each  provides a different look and feel.  Some of them support  highly configurable virtual desktops like, KDE and GNOME, some of them are lightweight desktop like LXDE which comes with the RPi, or you can operate bare bones (like I am on my PC while using the RPi) and let MS Windows be your Window Manager via Cygwin/X.  The iPad’s iSSH can run without a Window Manager.  In effect, X server uses the display as it sees fit and your unable to control where things loaded. iSSH does have a Window Manage your can use as an option called dwm.  Its a tiling window manager, which is a reasonable way to go given that your pointing device is your finger on the iPad.

X Display Manager

The X Display Manager (XDM) is an optional part of the X Window System that is used for login session management.  XDM provides a graphical interface for choosing which display server to connect to, and entering authorization information such as a login & password.  Like the Linux getty utility, it performs system logins to the display being connected to and then runs a session manager on behalf of the user (usually an X window manager).  XDM then waits for this program to exit, signaling that the user is done and should be logged out of the display. At this point, XDM can display the login and display chooser screens for the next user to login.

In the small world of my RPi’s, a PC, and an iPad, I have no need for an XDM and don’t use one.

Enough of the X Journey … Now in Conclusion

So what does the iSSH give me? I can now sit on the couch, watch TV, and simultaneously login into the RPi with full X Windows support.  Some would call this Nirvana but I call it just VERY NICE.  The iPad/iSSH combination isn’t the perfect user experience but Zingersoft did a good job.

By the way …. the above iPad screen shot of the X Server display with a globe was rendered using the following code:

#!/usr/bin/env python

    Source: http://www.scipy.org/Cookbook/Matplotlib/Maps

from mpl_toolkits.basemap import Basemap
import matplotlib.pyplot as plt
import numpy as np

Use_NASA_blue_marble_image = False

# set up orthographic map projection with
# perspective of satellite looking down at 50N, 100W.
# use low resolution coastlines.
# don't plot features that are smaller than 1000 square km.
map = Basemap(projection='ortho', lat_0=50, lon_0=-100, resolution='l', area_thresh=1000.)

# draw coastlines, country boundaries, fill continents.
if Use_NASA_blue_marble_image:

# draw the edge of the map projection region (the projection limb)

# draw lat/lon grid lines every 30 degrees.
map.drawmeridians(np.arange(0, 360, 30))
map.drawparallels(np.arange(-90, 90, 30))

# lat/lon coordinates of five cities.
lats = [40.02, 32.73, 38.55, 48.25, 17.29]
lons = [-105.16, -117.16, -77.00, -114.21, -88.10]
cities = ['Boulder, CO', 'San Diego, CA', 'Washington, DC', 'Whitefish, MT', 'Belize City, Belize']

# compute the native map projection coordinates for cities.
x, y = map(lons, lats)

# plot filled circles at the locations of the cities.
map.plot(x, y, 'bo')

# plot the names of those five cities.
for name, xpt, ypt in zip(cities, x, y):
        plt.text(xpt + 50000, ypt + 50000, name)

# make up some data on a regular lat/lon grid.
nlats = 73
nlons = 145
delta = 2. * np.pi / (nlons - 1)
lats = (0.5 * np.pi - delta * np.indices((nlats, nlons))[0, :, :])
lons = (delta * np.indices((nlats, nlons))[1, :, :])
wave = 0.75 * (np.sin(2. * lats) ** 8 * np.cos(4. * lons))
mean = 0.5 * np.cos(2. * lats) * ((np.sin(2. * lats)) ** 2 + 2.)

# compute native map projection coordinates of lat/lon grid.
x, y = map(lons * 180. / np.pi, lats * 180. / np.pi)

# contour data over the map.
CS = map.contour(x, y, wave + mean, 15, linewidths=1.5)

%d bloggers like this: