 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 that, I will hand over to Fabian, who will show you how to set up the receiver and share some tips and tricks on how to improve signal reception quality. OpenSky Network, our mission is to improve the security, reliability and efficiency of the airspace usage by sharing ADC-related data to the 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 the US, but also in some smaller regions like Japan or in the 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 the rain. 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, either they exchange information between pilot and rescue units for example. So how it's done? The short and easy answer is that why are using radio? So if pilot wants to do something with the aircraft, they will ask air traffic controllers, is it 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 between 108 and 137 MHz is often referred to as airpans. 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 in later, once 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, a pilot wants to double check the instructions gotten from the pilot. At the current point of time, the pilot should 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 a automated system transcription system. Large amounts of data would be required. And that's why Adco2 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 preprocess 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 a 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 headless setup of the Raspberry Pi using SSH. Once we can access the Raspberry Pi, we're going to install RTL-SDR air band on it, which is an open source software that we can use to record ATC 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 are 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 ATC reception, we need a software-defined radio USB dongle. In our case, we're using the RTLSDR 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 PCR laptop that has an SD card reader, install the Raspberry Pi OS to the microSD card. We're using imager 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 right. 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 STR 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 homepage like shown here. If you can 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 are going to change the default password, configure the time zone and optionally configure wireless LAN. So to do this, let's start Raspberry 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 can use the current location button. Once you have specified your location, you can search airports that are closed by. So in our case we're choosing the Zurich airport and these 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 you're like selecting all the frequencies here and assigning it, assigning them all to one device will end up with an error message saying that we've exhausted the bandwidth. Instead of 2.4 we are now at 13. So we deselect the frequencies that don't fit in to our bandwidth. And 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 con 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. 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 number 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 flag, 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 flag. 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 open sky 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'll 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 ADSB receiver kit on the OpenSky network home page. 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 AirBend 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 the setup. A link to the AdCo2 project page. And finally a link to the OpenSky network home page where you can also find things like how to build an ADSB receiver. I hope this tutorial was easy to follow along and that you're able to make your own ATC receiver with it. And happy to answer questions that you might have right now.