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 192.168.178.187.

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 '192.168.178.187 (192.168.178.187)' 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)? yesWarning: Permanently added '192.168.178.187' (ECDSA) to the list of known hosts.Debian GNU/Linux 7

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.

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.

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.

As root, type: passwd debian.

Enter the new password (twice).

Check that the password change did work before continuing with the next step.

Remove the line default username:password is [debian:temppwd] from /etc/issue.net.

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.

cd /etc/ssh

rm ssh_host_*

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:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!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 is7a:fa:29:cf:9d:c9:3d:54:1c:33:d1:5c:83:91:33:cb.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:24You 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:

Edit /etc/ssh/sshd_config:

Change PermitRootLogin yes to PermitRootLogin no.

Change PermitEmptyPasswords yes to PermitEmptyPasswords no.

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.

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.

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:

Info: This tool will continuously read from the device, and report ifsamples 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 libgnuradio-osmosdr-0.1.5git.so.0.0.0: 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.

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

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 Planefinder.net 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.

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):

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

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