Tag: radio

ep-4yy13 DSP – week 13

“I think its just the biggest conceptual art project uninentional or otherwise that anyone ever made. it puts Christo and those other guys to shame. Its planetary”

Roman Mars “Episode 97 – Numbers Stations” from 99% Invisible


  • Measuring the invisible
  • What is the difference between sound waves and radio waves?
  • What is an antenna?
  • Wave propagation is frequency dependent
  • Sunspots and magnetic fields http://spaceweather.com
  • Extreme frequencies, negative frequencies?


Internet radio streams and recordings

Frequencies and modes
  • Macbook trackpad: Noise 5 mHz. (try holding radio near screen too)
  • Macbook AC adapter: Noise 600-1400 kHz. (~1000)
  • AC adapters, LED’s, Utility poles: 3.2 Khz
  • Arduino transmitter: AM 1330 kHz.
  • Laser light at 650nM
  • Wireless micorophone (Orange-brown): Wide FM 614.150 MHz. (R band)
  • Cordless phone: Narrow FM 926 mHz.
  • Cell phone: Digitally encrypted trunking FM 836 mHz.
  • Wifi: Digitally encoded PCM 2.4 gHz.
  • FM broadcast band: Wide FM 89.7 mHz (Raspberry Pi example 98.1 Mhz)
  • TV audio 600 mhz/660 mhz FMW
  • The sun http://www.ips.gov.au/Solar/3/4

Topics not covered

(due to snow and stuff)



  • d3
  • processing
  • jitter
  • hardware control




Please send me a copies of your earlier compositions. Have a prototype ready to demonstrate or talk about for the next class.


rtlsdr, Pd, linux


Today was able to get the rtlsdr~ object running in Pd on Ubuntu 14.04 on a Macbook pro.

Audio quality seems rough. The only driver I could get to work was Alsa at 44.1KHz – may be able to get help with this from Pd community.

Ended up using 64bit libraries for librtlsdr and libusb-1.0 . In fact, needed to using the shared (.so) libraries, not the static ones (.a) due to a weird linker error. Its possible that it happened due to mixing shared and static and I might try again using both static for these 2 libs.

See notes from previous post about issues with USB capture, and non-root user in Linux – there are 2 flags on the cmake for rtlsdr that might help resolve both of these, but I wasn’t having any luck and needed to use the method described in previous post.

The source code for linux version is in the /usr/lib/pd-extended/extra/rtlsdr~ folder – and the test pd file is in ~/pd/rtlSDR-block.pd, along with some abstractions.

There is also a makefile to build a local version of rtl_fm (rtl_fm3.c) in ~/rtl-sdr-new/rtl-sdr/rtl-fm3/

This makefile mixes the static and shared libs with no problem… hmm…?


Need to package this stuff up and send it to pdsdr github with source for Max/Pd on mac and Pd on linux. + instructions… etc.,

Would like to try running on r-pi – but will need to adapt the test patch to receive Osc messages because there is no gui on r-pi

Also I am some skeptical about running at low sample rates for audio – we’ll see…

another note

Just thinking, that even if I am not able to run rtlsdr~ on r-pi that we could adapt rtl_fm so it receives control input from Pd using Osc and work that way…


rtlsdr – Ubuntu installation

Notes for Ubuntu 14.04 LTS

Basic install:

1. use instructions at http://sdr.osmocom.org/trac/wiki/rtl-sdr

You will also need to install the following dependencies:

  • git
  • cmake
  • make
  • libusb-1.0
  • sox (optional)

Two issues:

  • rtlsdr device gets captured by OS, preventing application access
  • Standard installation process doesn’t allow non-root users to use a device

To prevent OS from capturing device…

Set up a blacklist file as explained in this post:


As the message suggests, there are two solutions.  The quickest is to
simply unload the driver:

sudo rmmod dvb_usb_rtl28xxu rtl2832

Not sure whether “rtl2832” on the end there is required or not, but it
can’t hurt.  This is only a temporary solution, as the driver will be
loaded again the next time you unplug and replug the USB device, so
you’ll have to run the command again.

If this works, and you don’t want to use the device for TV reception,
you can stop the module from ever being loaded, solving the problem
permanently.  The exact method depends on your Linux distribution, but
for me (running Arch Linux) I create a file in /etc/modprobe.d with
a .conf extension (I called it “no-rtl.conf”) with these contents:

blacklist dvb_usb_rtl28xxu
blacklist rtl2832
blacklist rtl2830

Again not sure whether it’s necessary to blacklist all three of these
or just the first, but I was erring on the side of caution and chose to
list everything to do with the Realtek DVB device.

Once you have created this blacklist file, you may need to unload the
driver one last time if it was already running – the blacklist
prevents it from loading but doesn’t do anything if it’s already

To allow non-root users to use the device…

Set up a udev rule as explained in this post:


Next, you need to add some udev rules to make the dongle available for the non-root users. First you want to find the vendor id and product id for your dongle.

The way I did this was to run:


The last line was the Realtek dongle:
Bus 001 Device 008: ID 0bda:2838 Realtek Semiconductor Corp.

The important parts are “0bda” (the vendor id) and “2838” (the product id).

Create a new file as root named /etc/udev/rules.d/20.rtlsdr.rules that contains the following line:

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

With the vendor and product ids for your particular dongle. This should make the dongle accessible to any user in the adm group. and add a /dev/rtl_sdr symlink when the dongle is attached.

It’s probably a good idea to unplug the dongle, restart udev (sudo restart udev) and re-plug in the dongle at this point.