Just this week, I managed to pick up two Raspberry Pi Model B boards and Multicomp clear cases from element14. I already had something in mind for one of the two RPis – as an ADS-B server.
If you aren’t familiar with ADS-B, it’s all about tracking aircraft. I’ve managed to get it working quite successfully with laptops and desktops under Windows using the RTL2832U TV tuner dongles and ADSB# and RTL1090.
My idea is to use the board as a remote receiver – the board, along with its Wi-Fi dongle and TV dongle and antenna would be placed remotely – powered by a battery – with me sitting at a distance away in the comfortable shade, watching the aircraft received by the ADSBpi. In the future, I could even expand to multiple ADSBpi’s, with the data aggregated together to ensure better coverage and mitigate building shadows etc.
The Software of Choice
As the Raspberry Pi runs Linux, ADSB# and RTL1090 aren’t really an option. But this isn’t a problem because there’s an ADSB decoder for Linux as well. The rtl-sdr package at Osmocom has an inbuilt ADSB decoder – it’s great for a test, but it’s just not very sophisticated.
Instead, we’ll be using the fabulous dump1090 code by Salvatore Sanfilippo (antirez) available here. In many respects, dump1090 is a superior decoder to the others, as it has additional message repairing abilities (–aggressive option fixes even two bit errors) as well as additional networking capabilities (including acting as a hub for several ADSB receivers and preparing a rudimentary web-page display similar to what you get from Virtual Radar Server).
Aside from that, its requirements are extremely light as you will see. It has no requirement for GNU Radio to be installed (it’s very large and most blocks require much CPU computation).
Preparing the Pi
I suppose you could call this section buterching the Pi. What I’ve done here isn’t advisable for most of the regular users.
Well, first of all, I had an accident – a fairly common one. Dropping a pair of pliers onto the board managed to dislodge the power input filtering capacitor, so I “fixed” that with a much bigger Panasonic 1200uF Low ESR capacitor soldered right between the 5v and GND pins on the header. Since I was going to dedicate the Pi for ADSB work, I didn’t see the loss of the header as being significant.
At this point, some of you will scream “but the Pi works fine without the capacitor – I did that to mine and it’s fine”. Yes, it might work, but I’d prefer to take no chances. In fact, from the outset, I wanted to up the size of the capacitor. When you want to run these devices off noisy switch-mode battery packs like these, a large capacitor is in your best interests. It’s also in your best interests if you are going to be using USB peripherals that consume a lot of power and involve RF.
Seeing as I would be using a lot of current from the USB ports, I felt it best to nullify any voltage drop we would get over the polyfuse by removing it altogether. Again, many people will find this a silly move – i.e. what if you have an accident? But I’d rather this work rather than be unstable. I’ve also bridged both USB port’s Vcc and GND lines together and soldered a spare polyester greencap over the pins to provide some local power filtering for the USB ports. It may not mitigate the plug-in in-rush current voltage drop, but it will compensate for my use of a Wi-Fi dongle which will transmit intermittently and put noise on the 5v line.
Further butchering the Pi involves removal of all the status LEDs. I’ve taped over it with electrical tape. I really don’t need them (much) and I’d rather prefer not to have them consuming power constantly. My idea is to run this portably in the field – so conserving power would be a great thing, no matter how small.
Setting it up
I went with the standard Raspbian setup on an old 2Gb Sandisk Blue SDSC card. I expanded the partition, fixed the locale and system time, and opted not to overclock the Raspberry Pi to save on energy. I also opted not to start X desktop on boot-up, after all, we really don’t need to waste CPU cycles when nobody’s going to be plugged into it directly. I made sure SSH was enabled – I won’t have a keyboard or mouse attached to it most of the time.
It’s a bit of a tight squeeze initially, as the image eats up almost all of the 2Gb card, but removing scratch, python, squeak, dillo, netsurf-gtk and other bundled stuff made a respectable amount of room for me to continue.
I used my Asus Nexus 7 charger and cable for the initial setup, and plugged in an old Netgear WG111v3 wireless adapter to get me online. This is a Realtek RTL8187L based adapter – and it’s not really a good choice.
Whatever you do, you should probably look up the chipset online first and decide whether it’s supported well enough under Raspbian. The RTL8187L has a few quirks which I will get into later – but aside from that, it’s a power hog. It gets really hot – wasting a lot of energy. Modern Wi-Fi dongles have gotten a lot better, I’ve got a few on the way, with external RP-SMA connectors to attach even better antennas.
After I connected it to the AP and got it online – the first step was to get some prerequisites installed. Running sudo apt-get install git pkg-config make build-essential cmake isc-dhcp-server libusb-1.0 rpi-update should be enough to get most of the stuff we’d need.
The next step was to follow the instructions (the cmake ones) at rtl-sdr to get the rtl-sdr library made. Then, similarly, I git cloned dump1090 and ran make on that as well. So far, so good – the TV dongle support should be done. This would be enough to use the Raspberry Pi interactively as an ADSB receiver provided you were sitting at the console.
Just to make sure we have the latest in kernels, I ran sudo rpi-update as well and let that finish up.
I wanted it to be a server over Wi-Fi. The initial thought was to use hostapd to create a SoftAP, much like how ladyada does in her guide to making a Raspberry Pi into a Wi-Fi router. Unfortunately, because of the chipset and the way the Kernel drivers are working, hostapd doesn’t seem to want to play well with my card, so we have to go “old school” and live with Ad-Hoc Wi-Fi mode with WEP encryption. That’s okay – I’m only using WEP to keep the casual guys at bay.
Now it was time to get the DHCP server set-up. I followed the ladyada instructions above (she’s awesome!) with the exception that I wanted my network to be unique. Why? Well I didn’t want it to clash with any commonly used home networking subnets so I don’t have routing problems when I connect to multiple networks.
I settled on 10.20.30.0/24 as the network address setup with the Raspberry Pi set as 10.20.30.1 static by editing /etc/network/interfaces, and the DHCP allocating 10.20.30.100-10.20.30.254 to clients, and having 10.20.30.255 as broadcast. The DHCP server is only really a convenience – it just merely saves my connecting laptops from needing to have their IP address manually set.
So far, so good. Now the next thing is to set the Wi-Fi card to be Ad-Hoc with encryption. Normally this can be achieved by using stanzas such as wireless-mode Ad-Hoc in /etc/network/interfaces but that didn’t work with the RTL8187L. In fact, it seems to be a documented issue since even manually issuing ifconfig wlan0 down followed by iwconfig wlan0 mode Ad-Hoc results in a strange error stating that the interface is busy!
To get around that, I decided to do the configuration in a start-up script. I added a line in /etc/rc.local which invokes a script I put in /home/pi/autolaunch.sh. Of course, you need to chmod +x that before you can execute it. This way, I can change the start-up options much more simply by editing that file.
Then, I found that isc-dhcp-server doesn’t start up reliably because the interfaces sometimes get reconfigured while the service is trying to start up. So I added a stop and start to the autolaunch.sh as well.
Finally, we have to add the dump1090 program to the autostart.sh, so we can actually get aircraft going. I chose to run dump1090 in interactive mode, so the screen is updated less often – but it really doesn’t matter. What’s more impressive is running –aggressive which improves decoding performance markedly resulting in even better coverage with the stock antenna trimmed down to the right length.
Unfortunately, I haven’t really taken care of shut-down at the moment. It’s really a “connect via SSH and issue shutdown manually” rather than push a button, but that’s fine by me!
Getting it Going
Well, as expected, after the steps were done and a few tweaks were made – the thing just works ™! You can always count on Linux to be like that. I actually quite like Linux now and I can’t imagine not having at least one Linux machine around.
It shows up as an ad-hoc network, it connects just fine – and when I SSH in, I find that dump1090 in aggressive isn’t even eating up 30% of the CPU! Wow!
With a regular Windows machine, we can fire up adsbscope and connect it to 10.20.30.1 port 30002 in AVR mode and it will start plotting away! Normally, I have little luck with flights even getting close to Richmond Airport, but with dump1090, I get another few kilometers further than that. It’s great!
This was done just a few minutes ago – a rather quiet night, and there’s still quite a few aircraft on the screen. Lovely.
When I hook it up with my battery pack, I can get about two hours from it. I estimate that this would be much longer if I opted for a more modern Wi-Fi adapter. As it stands, the tuner and the Wi-Fi dongle get extremely hot – so I’d say we’d be drawing about 1.5A continuously all up. With a 5Ah * 3.6v pack = 18Wh, we’d expect at most, 2.4 hours from the battery pack, so it’s pretty much spot on. The voltage output from the battery pack falls as the battery nears empty, so the Wi-Fi range actually drops (surprisingly).
So, imagine putting this into a water-proof lunchbox and sticking it up in a tree or outside the house where there’s less electrical noise. It would make for a much better plane-plotting experience! I just need to lower the energy consumption, improve the Wi-Fi antenna gain, and get a larger battery pack and I might be able to go for a day. The best part is that it isn’t even that expensive – if it gets damaged or lost, I won’t be too sad at all!
So there we are, a mini remote ADS-B receiver made with a Raspberry Pi. I’m sure I’m not the first, but it impresses me greatly just how little CPU power is required to decode ADS-B signals!
Don’t want to use the Pi? It works on the Samsung ARM Chromebook too!
Interestingly, dump1090 also builds and runs just fine on my Samsung ARM Chromebook running Chrubuntu – this makes it an ideal “walk-around” solution as the ARM Chromebook runs for a day easily, and you can even load the Google Maps display of dump1090 via the Wi-Fi on the Chromebook. Maybe if I wasn’t so attached to the Chromebook, I would have used that instead of the Pi. Hmm.
Or you can build it for any other Linux target …