Hello, my name is Alan and together with Fabian we are going to talk about how to set up a VHF
receiver to start collecting air traffic control voice data.
Our presentation is divided into two parts. I will talk about OpenSky Network,
about air traffic control and about the ADCO2 project. After what I will hand over to Fabian
who will show you how to set up the receiver and share some tips and tricks how to improve
signal reception quality. OpenSky Network. Our mission is to improve the security,
reliability and efficiency of the airspace usage by sharing ATC related data to public.
So far we only share air surveillance data but as you can see things are about to change and
we broaden our scope also to voice communication taking place between the air traffic controller
and the pilot. The way we collect the data is that we have a multitude of sensors operated by
volunteers and connected to internet and the receivers then feed the data to OpenSky and
OpenSky then shares this data to entities wishing to do interesting and useful stuff
with this data. A few facts about our network. We have around 3 000 registered receivers from which
around 1 000 is online and with those 1 000 receivers we get the coverage shown on this
figure here. As you can see we have quite good coverage in Europe and in US but also in some
smaller regions like Japan or in western coast of Australia.
So now moving on to the air traffic control and a few words why it's needed.
So pilots are facing pretty much a formidable task. They need to take a
poorly maneuverable fast-moving aircraft from point A to point B without causing an accident.
So you can imagine that the help would be needed. And here is the place where air traffic
controller comes to play. Air traffic controller has a pretty good overview about
the space surrounding any given aircraft and they also have good understanding about the aircraft,
about its restrictions and current conditions. So they can advise pilots how to maneuver through
the airspace the safest and most efficient way possible. So the tasks... there are three main
tasks for the air traffic controller. They have to make sure that the aircraft do not collide
with each other and also do not collide with terrain. They need to provide pilots with
necessary information and also if things go really bad and help is needed, they
do provide alerting services, meaning that they exchange data between...
they exchange information between pilot and rescue units, for example.
So how it's done? The short and easy answer is that via using radio. So if pilot wants to do
something with the aircraft, they will ask air traffic controllers if it's safe to do so.
Then the air traffic controller is looking at all the information available and
gets back to the pilot saying that either it's safe and they can go ahead or it's not safe and
they should do something else altogether.
The frequencies used to communicate lie between 108 and 137 megahertz.
It's often referred to as earbands.
And by saying it's most commonly used, I mean there are other frequencies also
that are used in some instances. For example, in oceanic areas, lower frequencies which have
better propagation features or satellite communication also is used often in those areas.
But as VHF communication provides the highest quality at the moment, it's preferred
and used wherever possible. And that's why it's the most interesting also to listen to.
So as I said, the communication between the pilot and the air traffic controller is verbal,
meaning that if later one said it cannot be returned to later on, but you probably can
come up with several scenarios where one would like to return to what was said. For example,
pilot wants to double check the instructions gotten from the pilot. At current
point of time, the pilot should, to be able to do that, the pilot should
write these introductions down. But as pilots while flying
are rather busy, they just don't have the mental capacity to do so.
That's why some sort of automation would be much appreciated.
But for building that sort of an automated system, transcription system,
large amounts of data would be required. And that's why HATCO2 project was brought to life.
It's a EU-funded project with several different partners who together
intend to develop a platform that allows to collect, organize, and pre-process
air control voice communication data. For that, two separate systems will be built.
First, collecting voice recordings and storing them and making it available to public.
And another one taking care of automatic transcriptions and also storing them so
these transcriptions then can be later used to whichever reason needed. And lastly,
the legal aspects of making that sort of recordings and sharing them with other
parties is also looked at within this project.
It's not inherently lawful to make the recordings in all the countries in the world.
And that's why it's really important to shed some light into this matter as well.
So that's it from my part. Thank you for listening and I will now give word to Fabian
who will show you how the receiver should be set up. Thanks and enjoy!
Hi all, my name is Fabian and in the second part I will take you through a tutorial of
how to set up a Raspberry Pi as an air traffic control receiver. We will first go through a
setup of the Raspberry Pi using SSH. Once we can access the Raspberry Pi, we're going to install
RTL-SDR Airband on it, which is an open source software that we can use to record APC communications.
Additionally, we will install some audio utilities to encode the raw output into FLAC audio format.
After installing the software, I will show you how to configure the software based on your location
using a configuration web page. And finally, we will test the setup if it's working. At the end,
I will give you some hints on how to position your antenna and wrap up with some links and an output.
So first, before we dive into it, let's look at the components that we are using for this setup.
As a general purpose, low-cost computer, we're using a Raspberry Pi. It doesn't really matter
which version, even a version 1 should work. Although if you want to use multiple downloads
and listen to a lot of frequencies, a higher version Raspberry Pi might be recommendable.
Then for the Raspberry Pi, we need the power supply and the LAN cable for the initial setup.
The LAN cable you only need if you want to follow along this headless SSH setup from scratch.
If you already have a running Raspberry Pi or setting up with monitor and keyboard,
you can also use a wireless LAN. You also need a microSD card which serves as a Raspberry Pi disk.
For the APC reception, we need a software-defined radio USB dongle. In our case, we're using the
RTL-SDR dongle. The link to it is provided on the last page of this presentation.
And then we need an antenna to connect to the dongle. There are dongle sets that you can buy
including a general-purpose antenna. That's a good start. If you're setting up a Raspberry Pi
from scratch, you can follow along this step. If you're not familiar with terminals SSH and how to
find out the IP of your Raspberry Pi, it might be easier to follow the Noobs setup guide with mouse
and keyboard from the official Raspberry Pi page. On a PC or laptop that has an SD card reader,
install a Raspberry Pi OS to the microSD card. We're using Imgur that is available from the
Raspberry Pi download section. So first, we choose the operating system as Raspberry Pi OS 32 bits
and the SD card that we want to install it. And then press write. After the SD card is finished,
we insert it into the Raspberry Pi. Connect the Raspberry Pi to the LAN network using the cable.
Add the SDR USB stick with antenna attached to it and power up the Raspberry Pi. Give it a few
seconds. Now we need to find out what the IP of our Raspberry Pi on our network is.
You can normally see this somewhere on your router's configuration home page like shown here.
If you can't find it out for some reason, you can always resort to attaching a monitor and keyboard
and mouse to the Raspberry Pi and finishing the setup in that way. The initial login to the
Raspberry Pi should work with username pi and password raspberry.
Next, we're going to change the default password, configure the time zone,
and optionally configure wireless LAN. So to do this, let's start raspi-config.
Then select change user password and enter a new password twice.
Next, let's select four localization options. Change the time zone and select the
continent and country you're in. Then let's select localization options again
and change the VLAN country to your country.
If you want to configure wireless LAN, then you can do this under network options.
Once installed, the configuration file for the software needs to be modified to record the desired
frequencies and produce an output. The full set of configuration options you can find on the wiki
page with the provided link. After the software is installed, the configuration file for the software
needs to be modified. To make the configuration easier, we have a simple page that generates
a configuration file for you in five steps. The first step is to specify your device,
the type, give it some name, and you can leave the bandwidth as is for most cases.
The second step is to specify your location, either by address, by longitude, latitude,
or if your device supports it, you can use the current location button.
Once you have specified your location, you can search airports that are close by.
So in our case, we're choosing the Zurich airport,
and this will provide you with a set of frequencies which are used in this airport.
So you can select the frequencies which you want to record,
but there is a restriction that the specified bandwidth of your device that you specified on top
needs to fit all the frequencies in it. So if you have a bandwidth of 2.4
megahertz, the frequencies can be more than 2.4 apart.
So if we're selecting all the frequencies here and assigning them all to one device,
we'll end up with an error message saying that we've exhausted the bandwidth.
So instead of 2.4, we are now at 13. So we deselect the frequencies that don't fit in
to our bandwidth, and the error message should disappear.
And based on these options, a configuration file should be generated.
So we're copying this file or downloading it, and then we have to transfer it to our Raspberry Pi.
To copy the configuration into our RTL-Airband.conf file, I'm using the Nano Editor.
So first I delete all of the existing example configuration,
and then I'm pasting in the generated configuration file.
After that, we're exiting and saving the file.
Next, let's test if our setup is working correctly by looking at the signal
and the output that is produced. To test if the software is working, we can start it
in the foreground mode. It's also useful to see if the noise level estimation and squelch
are working fine. The two numbers indicate the estimated noise level and the signal level.
And the star appears besides the two numbers if the recording kicks in.
So for instance, if you always see a star, meaning it's recording all the time, you might
need to adjust the gain setting. More information can be found in the troubleshooting section
on the wiki page. Regarding output, there is an output airband folder in the home directory
where the raw files and the metadata text file is stored.
And then once it is encoded to FLAC, it will be visible in the encode subfolder in that directory.
Configuration options that are generated by the config page are listed here.
Multi-channel mode was chosen so that we're sure not to miss any transmissions
in the channels that we're interested in. The other option would be frequency scanning.
Then we chose raw output format so we could encode it to FLAC.
Other options are mp3, icecast, or pulse audio. So you can also set up an icecast server to have
a streaming version of the channels to listen to at home in parallel. The goal of the project
in later stages is to provide the feeder software part to send the audio to OpenSky and reach the
audio with annotations and potentially other data. The gain setting is set to a default level,
but it might need to be adapted. Especially if you have a good antenna with some
amplification, then the gain setting might have to be lowered, else you will have
recording noise all the time. So for the setup of the antenna, in general, there should be no
obstacles between the sender and the antenna. So in the ATC case, the senders are the airplanes
and the airport tower. These examples are taken from the ADS-B receiver kit on the OpenSky network
homepage. So only show airplanes and not the airport, but the same principles apply.
On these pictures, you can see non-ideal setups with obstacles or a narrow angle.
Finally, to give a short outlook, we will be providing some sort of feeder soon to be able
to process the audio recordings on the server side and make it available to feeders through an API.
Here is a collection of links that we used in this presentation. First, the AirBand GitHub repo
and their wiki page, then the config page that helps you put together a configuration file,
a link to the Raspberry Pi where you can find things like installation instruction,
the RTL-SDR dongle we used in this setup, a link to the ADCO2 project page,
and finally a link to the OpenSky network homepage where you can also find things like
how to build an ADS-B receiver. I hope this tutorial was easy to follow along
and that you're able to make your own ADS-B receiver with it
and happy to answer questions that you might have right now.