Pale blue cloud  



Running rtl-sdr and dump1090 on the BeagleBone Black



This article explains how to configure a brand new BeagleBone Black computer to run the rtl-sdr software: software that implements 'software defined radio' on a very cheap DVB-T dongle.

Specifically: I will install and run rtl_tcp on this BeagleBone Black and connect to it from a remote location with rtl-sdr, to listen to the radio.

The article also serves as a list of actions that I need/want to do in case I have to reprovision a BeagleBone Black from scratch for whatever reason.

If you do not know what this means, and if you care, then you should probably check out these site:

This article will be in the form of sections describing particular aspects of the provisioning/installation/configuration process of a new BeagleBone Black (BBB from now, for short). I wrote this for people who feel comfortable working on the Linux command line, using the root account. If you're not then you can accept the challenge, go for it and learn something, or not.

Switching it on

Plug the BBB into a network socket and power it on. Blinky LEDs should come on and if your router provides IP addresses by DHCP then you should be able to obtain the BBBs IP address from the router logs.

Mine says:

A network computer (beaglebone) was assigned the IP address of

My guess is (not having read much about the BBB yet) that I can log in with root using ssh. Let's give it a try:

martijn@alnitak:~> ssh This email address is being protected from spambots. You need JavaScript enabled to view it.
The authenticity of host ' (' can't be established.

ECDSA key fingerprint is b1:a9:84:39:71:99:a3:af:9e:ba:26:d5:e6:XX:XX:XX.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '' (ECDSA) to the list of known hosts.
Debian GNU/Linux 7 BeagleBone Debian Image 2014-04-23

Last login: Wed Apr 23 20:21:18 2014
/usr/bin/xauth:  file /root/.Xauthority does not exist

The exact OS version is:

root@beaglebone:~# uname -a
Linux beaglebone 3.8.13-bone47 #1 SMP Fri Apr 11 01:36:09 UTC 2014 armv7l GNU/Linux

Update to the latest image and kernel

The BBB's image is from 23 April 2014 while the latest at time of writing is from November 2015.

You can install the latest release according to these instructions on the Element14 site, or the instructions on the BB site, when you want/can use Windows. Or you can use these instructions in case you want to write the image to the required SD card using Linux.

I chose the latter.

Don't copy/execute this willy-nilly, make sure you know what you do and do not accidentally overwrite the wrong partition for example.

  1. Download the latest eMMC flasher image (console only, no graphical desktop): wget
  2. Check the sha256sum with the one published on the website: sha256sum BBB-eMMC-flasher-debian-7.9-console-armhf-2015-11-03-2gb.img.xz
  3. Unpack the archive: xz -d BBB-eMMC-flasher-debian-7.9-console-armhf-2015-11-03-2gb.img.xz
  4. Write it to the SD card (overwriting all that's on it, takes about 10 minutes): sudo dd if=./BBB-eMMC-flasher-debian-7.9-console-armhf-2015-11-03-2gb.img of=/dev/mmcblk0
  5. Continue with the section Flashing Debian Wheezy to the eMMC.
  6. Some installation sites mention that all LEDs are ON. I found that, for this release of the image, all LEDs are OFF after the flash procedure is completed.
  7. ssh into the BBB:ssh This email address is being protected from spambots. You need JavaScript enabled to view it. (your IP address will differ).
  8. Update the installed packages: apt-get update && apt-get upgrade.
  9. Install some stuff I like with apt-get install:
    1. less
    2. screen
    3. locales
  10. Upgrade the kernel with the BB-provided tools - intial failure.
    1. apt-get install lsb-release
    2. cd /opt/scripts/tools
    3. ./

The last step failed with the error: ERROR: The certificate of `' is not trusted. Perhaps because the date on the BBB is 6 weeks in the past? Need to configure ntp first, then!

  1. apt-get install ntp.
  2. Edit /etc/ntp.conf and add sone ntp servers that are geographically close:
  3. Configure to use the proper localtime settings:
    1. cd /etc
    2. mv localtime
    3. ln -s /usr/share/zoneinfo/Europe/Amsterdam localtime
    4. Check the date/time with 'date' - success.

Let's try again to update the kernel:

  1. cd /opt/scripts/tools
  2. ./
  3. A lot of text scrolls by and it appears I already have the latest kernel of this version (linux-image-3.8.13-bone79), so it just gets reinstalled. Which seems kind of pointless but there you go. At least the date and time have been setup properly.

Configure locale

A good explanation and instructions can be found here.

  1. Run dpkg-reconfigure locales
  2. I chose en_US.UTF-8 UTF-8 as my default locale.

Configure remote access

Change password for root

Out of the box the root account has an empty password, big security hole. Changing it:

  1. sudo su (if not already ligged in as root).
  2. passwd
  3. Enter new UNIX password: xxxxxxxx
    Retype new UNIX password: xxxxxxxx
    passwd: password updated successfully

Change password of the default user

The login message that greets the first time user is: default username:password is [debian:temppwd].

We're fixing this security hole as well.

  1. As root, type: passwd debian.
  2. Enter the new password (twice).
  3. Check that the password change did work before continuing with the next step.
  4. Remove the line default username:password is [debian:temppwd] from /etc/

Regenerate the ssh host keys

BBB comes with ssh host keys as part of the installation image. Meaning everyone who uses that image uses the same ssh host keys. I am not too paranoid about being hit by a man in the middle attack on my own little home network but it's wiser, and at last better admin-ship, to generate unique ssh keys for the BBB.

  1. cd /etc/ssh
  2. rm ssh_host_*
  3. dpkg-reconfigure openssh-server

Because I had already logged in before over ssh, and store the BBB's host key in my laptop's known_hosts file, I now get the following message when attempting to login remotely:

Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
Please contact your system administrator.
Add correct host key in /home/martijn/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/martijn/.ssh/known_hosts:24
You can use following command to remove all keys for this IP:
ssh-keygen -R beaglebone.localdomain -f /home/martijn/.ssh/known_hosts

Note the last line of that message, which explains how to remove the now-obsolete key from the known_hosts file.

After executing the command you will be prompted to accept the new ssh host key just once (it will be added to the known_hosts file again) and then you're done.

Disable SSH root login

Root access over ssh is considered a security risk so I'm disabling it. Before doing this make sure that:

  • ssh login of the debian user succeeds
  • sudo to root, by the debian user, succeeds

Perform the following steps, as root:

  1. Edit /etc/ssh/sshd_config:
  2. Change PermitRootLogin yes to PermitRootLogin no.
  3. Change PermitEmptyPasswords yes to PermitEmptyPasswords no.
  4. Restart sshd: /etc/init.d/ssh restart.

Set up passwordless login for the 'debian' user

I like to configure remote SSH access using public/private key authentication. That way I do not have to type in passwords and it allows me to have convenient shell aliasses like 'bbb', for executing the command ssh debian@beaglebone.

Follow these instructions on the Debian website.

I keep some other public keys around for various systems and authentication protocols. To make that work transparently, I added these new entries to the file ~/.ssh/config on my laptop:

Host beaglebone beaglebone.localdomain
Hostname beaglebone.localdomain
IdentityFile ~/.ssh/id_rsa.beaglebone

Assign a permanent IP address

DHCP is nice but it's annoying to have to obtain the BBB's IP address from the router after each reboot/lease renewal. Not to mention that it makes it hard to connect to rtl_tcp later on.

So I'm going to assign a static IP address.

  1. Edit /etc/network/interfaces.
  2. Change:
    # The primary network interface
    auto eth0
    iface eth0 inet dhcp
  3. To:
    # The primary network interface
    auto eth0
    iface eth0 inet static
  4. Restart network: /etc/init.d/networking restart.

Configure firewall

to be completed

Build and install the rtl-sdr software

I am using the instructions in the OsmoSDR Linux section on rtl-sdr, over here to build rtl-sdr from source. Everything will be done under the default 'debian' user, unless specified differently.

The following software should be installed (with apt-get) prior to building:

  • git
  • make, cmake
  • libusb-1.0-0-dev

Build the code

  1. git clone git://
  2. cd rtl-sdr
  3. mkdir build
  4. cd build
  5. cmake ../ -DINSTALL_UDEV_RULES=ON
  6. make
  7. sudo make install
  8. sudo ldconfig

The following files get installed:

-- Installing: /etc/udev/rules.d/rtl-sdr.rules
-- Installing: /usr/local/lib/pkgconfig/librtlsdr.pc
-- Installing: /usr/local/include/rtl-sdr.h
-- Installing: /usr/local/include/rtl-sdr_export.h
-- Installing: /usr/local/lib/
-- Installing: /usr/local/lib/
-- Installing: /usr/local/lib/
-- Installing: /usr/local/lib/librtlsdr.a
-- Installing: /usr/local/bin/rtl_sdr
-- Installing: /usr/local/bin/rtl_tcp
-- Installing: /usr/local/bin/rtl_test
-- Installing: /usr/local/bin/rtl_fm
-- Installing: /usr/local/bin/rtl_eeprom
-- Installing: /usr/local/bin/rtl_adsb
-- Installing: /usr/local/bin/rtl_power

Blacklist the USB DVB-T driver

The default DVB-T USB driver, which is loaded when the USB dongle is plugged in, must be blacklisted because it prevents the rtl-sdr driver from loading.

  1. create a text file rtlsdr.conf in /etc/modprobe.d and add the line blacklist dvb_usb_rtl28xxu

Does it work?

When I plugged in the RTL-SDR dongle its LED did not come on and dmesg did not show that the BBB had recognized it. But after a reboot (I know, should not be necessary, it's not that other OS) it does work as the output of rtl_test proves:

debian@beaglebone:~$ rtl_test
Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 00000001

Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 48.0 49.6
[R82XX] PLL not locked!
Sampling at 2048000 S/s.

Info: This tool will continuously read from the device, and report if
samples get lost. If you observe no further output, everything is fine.

Reading samples in async mode...
lost at least 124 bytes

What's next

rtl_tcp is running quite well on the BBB, using less than 10% CPU at a sampling rate of 2048000 with one client connected. I am not so happy with the client results, though. I have used gqrx before, running on the same host where rtl_sdr was installed and it worked well. But the TCP clients I tried so far on other networked clients were disappointing: there is a noticeable lag (a few seconds) between the moment a command is issued (for example, to tune another frequency) and the moment it takes effect.

  • SDRTouch, an Android app, works with rtl_tcp but I have to enter the TCP host each time I (re)connect, which is a pain. The sensitivity is bad, compared to gqrx/localhost (using the same dongle) and there are a lot of strong noise signals. Also when tuning a frequency in the GUI, the rtl_tcp verbose output on the BBB shows that the frequency that is actually commanded is a few hundred kb off...
  • Running gqrx on Ubuntu in a virtual machine is problematic, with a lot of packets being dropped even at the lowest sampling rates. Probably due to the Virtualbox overhead.
  • gqrx and the osmocom* applications from openSUSE 13.1, the hamradio repository, won't start due to undefined symbol: _ZN3uhd6device4findERKNS_13device_addr_tE

Update 29 December 2015

I tried Kali linux (on the SD card) but Gqrx does not work noticeably better, so for now I moved back to Debian Wheezy (7.9). I installed ACARS decoder 3.2 for listening to ACARS messages from aircraft, and dump1090-mutability to listen to Mode S/ADS-B messages.

The ACARS decoder works fine as long as it's listening to one ACARS frequency. When tuning two or more frequencies the CPU load becomes too high, resulting in lots of CRC errors and no decoded messages.

dump1090-mutability is a lot of fun to use. Not only does it receive and decode Mode S (ADS-B) transmissions from aircraft but it also implements a simple webserver and displays the aircraft on it. I've got my own FlightRadar24/FlightAware now :)  I'll be messing with antenna designs for some time, hopefully resulting in a design/implemantation that's good enough to mount outside. I also got a low noise antenna amplifier from this guy, which should improve signal quality and thus reception.

Update 6 January 2016

Install dump1090-mutability package

I like dump1090 enough to install it permanently on the BBB and have it started at boot time. Also, as recommended, I will no longer use the built-in web server. In stead I'll use lighttpd.

Malcolm Robb provides a forked version of dump1090 called 'dump1090-mutability', complete as a Debian package including configuration script and lighttpd configuration. Installation instructions here.

I did the following:

sudo dpkg -i mutability-repo_0.1.0_armhf.deb

Here I ran into problems because I chose to run under an existing user ('debian') and the installation script can't deal with that.

The solution is to remove the installation and start over, chosing a different, new, user to run dump1090-mutability under (e.g. 'dump1090'):

apt-get remove --purge dump1090-mutability
apt-get install dump1090-mutability
dpkg-reconfigure dump1090-mutability

Install the webserver:

apt-get install lighttpd
lighty-enable-mod dump1090
/etc/init.d/lighttpd force-reload

Now after starting the ADS-B software with 'service dump1090-mutability start' my website becomes available at my (internal) IP address

A different antenna and a low noise amplifier

I bought one of Adam Alicajic's low noise amplifiers for ADS-B, LNA4ALL, and I built a new Franklin antenna according to this design on the forums. So far I'm very pleased with the results: even with the antenna indoors the maximum range is about 180 km.

Looking through stats.json (generated by dump1090) there seems to be a high number of discarded messages. I have an idea that this is caused by a few nearby cell phone towers. There are two big ones within 1 kilometer from here and a small one on the neighbours roof, some kind of Vodaphone (?) experiment apparently.

Something will have to be done about that.

This is what the maximum range figures look like in adsbSCOPE (running under XP in VirtualBox):

And here's a snapshot from dump1090-mutability:

Update 9 January 2016

To do away with the interference from the GSM masts I decided to buy the FlighAware ADS-B bandpass filter from Amazon. The results are pretty astounding: I went from ~ 250 messages/sec to more than 400!

The maximum range increased, as well as the distance top where low-flying airplanes can be received. The below snapshot is with the same antenna and in the same position as the ones above.

 adsbscope franklin lna4all flightawarefilter3 20160116

Update 16 January 2016

Today I went out and got me some 75Ω coax, Aircell 7 and a bunch of N- and SMA connectors and made myself a collinear antenna for ADS-B, using the directions on Dusan Balara's site.

I do not have proper results from adsbSCOPE yet (plus it's getting late in the evening so traffic is down), but so far it seems that the collinear does not perform as well as the Franklin, using the same (not so good for 1090 MHz) RG58 cable.

However, after I replaced the RG58 with Aircell 7 I could up the RTL-SDR gain from 26 to 30 because the cable is so much better, without saturating the receiver. Perhaps the gain can be cranked up even more, experimentation will tell.

Update 17 January 2016

Yes, the gain can be cranked up more before saturating the receiver. It's currently at 48. This morning I got ~760 messages/second from about 80 planes. Here are some snapshots of dump1090 and VirtualRadar (running under Mono in openSUSE):

dump1090 collinear lna4all flightawarefilter aircell 20160117

And here's the situation in adsbSCOPE, after running for approximately two hours on a Sunday morning:

adsbscope franklin lna4all flightawarefilter aircell 20160117

This is definitely a big improvement over the adsbSCOPE snapshot above!

© Palebluedot