ADS-B Basics
Automatic dependent surveillance-broadcast (ADS-B) is a cooperative surveillance technology for tracking aircraft. --Wikipedia
This is one of the ways in which the airplanes report their basic flight parameters (identification, current position, altitude, speed, etc) to the Air Traffic Control. All of this happens over radio broadcasts (completely public) at 1090MHz - at lest this is the frequency we are interested in. The full Wikipedia article is quite interesting and contains more information.
Why bother?
If you have ever seen the flightradar24 website before, you have possibly thought (I know I did) about how cool would it be to do it yourself - own one of those virtual radars and maybe even feed the data into flightradar24 to improve their coverage (and get premium account for free)? If you like this idea, you will like the results your own radar station will produce - in general it would be something like this
All of that is easy to build and the cost is really minimal, using either a PC or a Raspberry Pi as I describe in this post.
Design
- Raspberry Pi - From my point of view, the key benefit of Raspberry Pi is how little power it consumes. Mine never made it above 2W, so that would be something like ~£0.20/month in electricity.
- SDR Receiver - When Software Defined Radios started showing up I wanted to buy one but the prices were out of my reach back then. Right now it turned out you can get a cheap (but also fairly basic) SDR for about £8. There is several main lines of those receivers (different chipsets, different capabilities - see here for comparison) but I found the two below to be the most common:
- R820T - covers from 24MHz to 1766MHz (this is the one I use)
- E4000 - covers from 52MHz to 2200Mhz with gap 1100-1250MHz
- Raspbian - minimal version, actually custom install instead of ready made image I could download. One of the reasons was that I had a spare 2GB SD card and these days stock Raspbian comes as 4GB image.
General configuration
My Raspbian build runs only ntpd, sshd and dhcp client on the ethernet port - all other services are turned off.
The key tool we need is called dump1090 and can be found on GitHub. The installation is really straightforward, thanks to an excellent blog post by David GM8ARV. There is actually several versions of dump1090 - original application created by Salvatore 'antirez' Sanfilippo and an extended one released by MalcolmRobb. There are differences under the hood as well as in the user interface. First of all, Malcolm's version includes improvements in decoding and processing functions. The difference became apparent when I switched from 'antirez' to 'MalcolmRobb' code base - the amount of airplanes picked up almost doubled, more planes had their flight numbers attached to them, etc. Another immediately visible change is the web interface - airplane icons replaced triangles and a panel was added to show the table with flights currently in range of our station (as seen in the screenshot above). Both versions can also show interactive table with the live data they receive - here's how it looks on my screen.
The second element of the configuration is the feed to Flightradar24.com - this is again described on their website. The description covers Windows version only, which I had problems with because the USB dongle didn't want to register almost anything, however this page mentions there's a Linux version available for both x86 and ARM architectures.
Feeding to Flightradar24 requires registration as a data source to obtain a sharing key. Unfortunately I didn't find (yet) how to register using the Linux client or the website, so for the registration I used Windows version of the software and waited till it picked up two planes and activated my account.
UPDATE: According to tweet by Flightradar24.com, at the time I'm writing this the sharing key can be obtained by either running their Windows client or sending an email to support@fr24.com.
Once everything is installed it is time for a little automation. The Raspbian image I created has both versions of dump1090 installed in /opt and the currently used (MalcolmRobb) is symlinked as /opt/dump1090, so I can switch versions without any problems. The Flightradar24 feed agent is saved as /opt/fr24feed_arm-le_233.
Both applications are started at system boot time, but that happens via inittab instead of regular runlevel and dependency based boot process. I decided to use inittab because the image is built for a particular purpose - almost like an embedded system. Of course I will not let the applications runs as root, because dump1090 implements it's own http server and fr24feed agent is closed source - both will run as an unprivileged user.
Inittab runs (only once, no restarts) a start script for dump1090 which executes the app as user adsb and redirects the interactive output (flights table) to tty1. Yes, the getty process is still there but I left it running to sort out device permissions (dirty hack - user adsb is added to the tty group to write to tty, if getty was not running device would be owned by root:root). In case the USB dongle is not connected, the app will of course die and will be restarted every 10 seconds. Additionally I moved the web interface from the default port 8080 to more usual 80.
Identical approach was taken with Flightradar24 feed agent, however this one tries to connect to the server (that is dump1090) on port 30003/tcp and if that fails it will keep trying. The main difference is that the agent requires a sharing key to run. I decided to save it in a file located on the /boot partition because it's formatted as vfat and can be accessed from any Windows/Linux/Mac machine, making it easy to add the key. Of course if the file with the key does not exist, the feed agent will not be started. Once the agent starts, its output is sent to tty2 for debugging purpose, so the first usable local terminal is tty3 :-)
Putting it all together takes no more than 20-30 minutes if you have all the parts. I encourage you to try and build it yourself (follow the articles I have linked in this post). However if you feel it's too much work, you can try to use my Raspbian image, but keep in mind that you get it as-is, without any support, warranty or promises - you have been warned.
... and if you don't have the parts to build it, you can always see theairplanes in my area (busy airspace during the day; sorry - no longer exposed to the Internet), that is if my receiver is currently on-line.
Enjoy!
The key tool we need is called dump1090 and can be found on GitHub. The installation is really straightforward, thanks to an excellent blog post by David GM8ARV. There is actually several versions of dump1090 - original application created by Salvatore 'antirez' Sanfilippo and an extended one released by MalcolmRobb. There are differences under the hood as well as in the user interface. First of all, Malcolm's version includes improvements in decoding and processing functions. The difference became apparent when I switched from 'antirez' to 'MalcolmRobb' code base - the amount of airplanes picked up almost doubled, more planes had their flight numbers attached to them, etc. Another immediately visible change is the web interface - airplane icons replaced triangles and a panel was added to show the table with flights currently in range of our station (as seen in the screenshot above). Both versions can also show interactive table with the live data they receive - here's how it looks on my screen.
The second element of the configuration is the feed to Flightradar24.com - this is again described on their website. The description covers Windows version only, which I had problems with because the USB dongle didn't want to register almost anything, however this page mentions there's a Linux version available for both x86 and ARM architectures.
Feeding to Flightradar24 requires registration as a data source to obtain a sharing key. Unfortunately I didn't find (yet) how to register using the Linux client or the website, so for the registration I used Windows version of the software and waited till it picked up two planes and activated my account.
UPDATE: According to tweet by Flightradar24.com, at the time I'm writing this the sharing key can be obtained by either running their Windows client or sending an email to support@fr24.com.
Hello, ADS-B Pi
Once everything is installed it is time for a little automation. The Raspbian image I created has both versions of dump1090 installed in /opt and the currently used (MalcolmRobb) is symlinked as /opt/dump1090, so I can switch versions without any problems. The Flightradar24 feed agent is saved as /opt/fr24feed_arm-le_233.
Both applications are started at system boot time, but that happens via inittab instead of regular runlevel and dependency based boot process. I decided to use inittab because the image is built for a particular purpose - almost like an embedded system. Of course I will not let the applications runs as root, because dump1090 implements it's own http server and fr24feed agent is closed source - both will run as an unprivileged user.
Inittab runs (only once, no restarts) a start script for dump1090 which executes the app as user adsb and redirects the interactive output (flights table) to tty1. Yes, the getty process is still there but I left it running to sort out device permissions (dirty hack - user adsb is added to the tty group to write to tty, if getty was not running device would be owned by root:root). In case the USB dongle is not connected, the app will of course die and will be restarted every 10 seconds. Additionally I moved the web interface from the default port 8080 to more usual 80.
Identical approach was taken with Flightradar24 feed agent, however this one tries to connect to the server (that is dump1090) on port 30003/tcp and if that fails it will keep trying. The main difference is that the agent requires a sharing key to run. I decided to save it in a file located on the /boot partition because it's formatted as vfat and can be accessed from any Windows/Linux/Mac machine, making it easy to add the key. Of course if the file with the key does not exist, the feed agent will not be started. Once the agent starts, its output is sent to tty2 for debugging purpose, so the first usable local terminal is tty3 :-)
Summary
Putting it all together takes no more than 20-30 minutes if you have all the parts. I encourage you to try and build it yourself (follow the articles I have linked in this post). However if you feel it's too much work, you can try to use my Raspbian image, but keep in mind that you get it as-is, without any support, warranty or promises - you have been warned.
- Download 20131014-ADS-B-Pi.img.bz2 (SHA1: 94fcb743f2ce02f01197d105f59f4409674eb27f) and decompress it - it is a bzip2 compressed 2GB dd image
- Write the image to your SD card
- If you have Flightradar24 sharing key, you can save it in /boot/fr24feed.key - there's actually a /boot/fr24feed.key-disabled file with some instructions as well
- Connect rtl-sdr dongle, place antenna in a good location, boot up Raspberry Pi
- Change passwords for both users - default ones are (login/password) root/adsb and adsb/adsb
- If all worked ok you should see flights table on tty1, feed upload status on tty2, have a web server running on 80/tcp to watch your airspace and ssh server to manage the it all remotely.
I have to say I am a bit surprised by how little RAM it uses with everything running, but this can only be a good thing :-)
... and if you don't have the parts to build it, you can always see the
Enjoy!
No comments:
Post a Comment