[00:07.400 --> 00:14.140]  Hello, my name is Alan and together with Fabian we are going to talk about how to set up a VHF
[00:14.680 --> 00:19.740]  receiver to start collecting air traffic control voice data.
[00:20.820 --> 00:27.380]  Our presentation is divided into two parts. I will talk about OpenSky Network,
[00:27.380 --> 00:37.040]  about air traffic control and about the ADCO2 project. After what I will hand over to Fabian
[00:37.650 --> 00:45.440]  who will show you how to set up the receiver and share some tips and tricks how to improve
[00:45.440 --> 00:53.900]  signal reception quality. OpenSky Network. Our mission is to improve the security,
[00:53.900 --> 01:01.520]  reliability and efficiency of the airspace usage by sharing ATC related data to public.
[01:02.240 --> 01:09.440]  So far we only share air surveillance data but as you can see things are about to change and
[01:09.440 --> 01:19.420]  we broaden our scope also to voice communication taking place between the air traffic controller
[01:19.780 --> 01:29.640]  and the pilot. The way we collect the data is that we have a multitude of sensors operated by
[01:29.640 --> 01:40.620]  volunteers and connected to internet and the receivers then feed the data to OpenSky and
[01:40.620 --> 01:50.600]  OpenSky then shares this data to entities wishing to do interesting and useful stuff
[01:50.810 --> 02:02.200]  with this data. A few facts about our network. We have around 3 000 registered receivers from which
[02:02.200 --> 02:11.840]  around 1 000 is online and with those 1 000 receivers we get the coverage shown on this
[02:11.840 --> 02:20.820]  figure here. As you can see we have quite good coverage in Europe and in US but also in some
[02:20.820 --> 02:28.620]  smaller regions like Japan or in western coast of Australia.
[02:30.720 --> 02:36.700]  So now moving on to the air traffic control and a few words why it's needed.
[02:37.860 --> 02:44.860]  So pilots are facing pretty much a formidable task. They need to take a
[02:46.520 --> 02:56.780]  poorly maneuverable fast-moving aircraft from point A to point B without causing an accident.
[02:58.060 --> 03:06.620]  So you can imagine that the help would be needed. And here is the place where air traffic
[03:06.620 --> 03:14.680]  controller comes to play. Air traffic controller has a pretty good overview about
[03:16.060 --> 03:28.120]  the space surrounding any given aircraft and they also have good understanding about the aircraft,
[03:28.120 --> 03:41.020]  about its restrictions and current conditions. So they can advise pilots how to maneuver through
[03:41.020 --> 03:54.140]  the airspace the safest and most efficient way possible. So the tasks... there are three main
[03:54.140 --> 04:02.340]  tasks for the air traffic controller. They have to make sure that the aircraft do not collide
[04:02.680 --> 04:11.180]  with each other and also do not collide with terrain. They need to provide pilots with
[04:11.180 --> 04:21.920]  necessary information and also if things go really bad and help is needed, they
[04:22.200 --> 04:29.200]  do provide alerting services, meaning that they exchange data between...
[04:29.820 --> 04:35.320]  they exchange information between pilot and rescue units, for example.
[04:37.240 --> 04:48.440]  So how it's done? The short and easy answer is that via using radio. So if pilot wants to do
[04:48.440 --> 04:59.700]  something with the aircraft, they will ask air traffic controllers if it's safe to do so.
[04:59.920 --> 05:07.720]  Then the air traffic controller is looking at all the information available and
[05:08.460 --> 05:16.480]  gets back to the pilot saying that either it's safe and they can go ahead or it's not safe and
[05:16.480 --> 05:20.260]  they should do something else altogether.
[05:22.380 --> 05:36.680]  The frequencies used to communicate lie between 108 and 137 megahertz.
[05:36.680 --> 05:43.060]  It's often referred to as earbands.
[05:43.640 --> 05:54.920]  And by saying it's most commonly used, I mean there are other frequencies also
[05:55.310 --> 06:03.480]  that are used in some instances. For example, in oceanic areas, lower frequencies which have
[06:03.480 --> 06:13.380]  better propagation features or satellite communication also is used often in those areas.
[06:13.500 --> 06:24.080]  But as VHF communication provides the highest quality at the moment, it's preferred
[06:24.080 --> 06:33.460]  and used wherever possible. And that's why it's the most interesting also to listen to.
[06:34.440 --> 06:49.460]  So as I said, the communication between the pilot and the air traffic controller is verbal,
[06:49.460 --> 07:00.480]  meaning that if later one said it cannot be returned to later on, but you probably can
[07:00.480 --> 07:09.560]  come up with several scenarios where one would like to return to what was said. For example,
[07:09.560 --> 07:20.220]  pilot wants to double check the instructions gotten from the pilot. At current
[07:21.880 --> 07:28.260]  point of time, the pilot should, to be able to do that, the pilot should
[07:28.260 --> 07:35.100]  write these introductions down. But as pilots while flying
[07:36.180 --> 07:43.180]  are rather busy, they just don't have the mental capacity to do so.
[07:43.820 --> 07:51.280]  That's why some sort of automation would be much appreciated.
[07:52.660 --> 08:01.960]  But for building that sort of an automated system, transcription system,
[08:01.960 --> 08:15.220]  large amounts of data would be required. And that's why HATCO2 project was brought to life.
[08:15.220 --> 08:26.380]  It's a EU-funded project with several different partners who together
[08:27.340 --> 08:33.260]  intend to develop a platform that allows to collect, organize, and pre-process
[08:33.260 --> 08:42.380]  air control voice communication data. For that, two separate systems will be built.
[08:42.830 --> 08:52.310]  First, collecting voice recordings and storing them and making it available to public.
[08:52.310 --> 08:59.990]  And another one taking care of automatic transcriptions and also storing them so
[08:59.990 --> 09:11.970]  these transcriptions then can be later used to whichever reason needed. And lastly,
[09:11.970 --> 09:20.990]  the legal aspects of making that sort of recordings and sharing them with other
[09:21.710 --> 09:25.650]  parties is also looked at within this project.
[09:27.310 --> 09:40.790]  It's not inherently lawful to make the recordings in all the countries in the world.
[09:41.110 --> 09:48.990]  And that's why it's really important to shed some light into this matter as well.
[09:50.090 --> 09:58.270]  So that's it from my part. Thank you for listening and I will now give word to Fabian
[09:58.270 --> 10:06.530]  who will show you how the receiver should be set up. Thanks and enjoy!
[10:12.210 --> 10:17.190]  Hi all, my name is Fabian and in the second part I will take you through a tutorial of
[10:17.190 --> 10:23.590]  how to set up a Raspberry Pi as an air traffic control receiver. We will first go through a
[10:23.590 --> 10:30.770]  setup of the Raspberry Pi using SSH. Once we can access the Raspberry Pi, we're going to install
[10:30.770 --> 10:39.170]  RTL-SDR Airband on it, which is an open source software that we can use to record APC communications.
[10:40.030 --> 10:46.890]  Additionally, we will install some audio utilities to encode the raw output into FLAC audio format.
[10:47.190 --> 10:52.490]  After installing the software, I will show you how to configure the software based on your location
[10:52.490 --> 11:00.750]  using a configuration web page. And finally, we will test the setup if it's working. At the end,
[11:00.750 --> 11:06.390]  I will give you some hints on how to position your antenna and wrap up with some links and an output.
[11:09.220 --> 11:15.480]  So first, before we dive into it, let's look at the components that we are using for this setup.
[11:15.720 --> 11:22.100]  As a general purpose, low-cost computer, we're using a Raspberry Pi. It doesn't really matter
[11:22.100 --> 11:27.500]  which version, even a version 1 should work. Although if you want to use multiple downloads
[11:27.500 --> 11:32.390]  and listen to a lot of frequencies, a higher version Raspberry Pi might be recommendable.
[11:34.040 --> 11:40.060]  Then for the Raspberry Pi, we need the power supply and the LAN cable for the initial setup.
[11:40.240 --> 11:47.180]  The LAN cable you only need if you want to follow along this headless SSH setup from scratch.
[11:47.180 --> 11:53.000]  If you already have a running Raspberry Pi or setting up with monitor and keyboard,
[11:53.000 --> 12:00.840]  you can also use a wireless LAN. You also need a microSD card which serves as a Raspberry Pi disk.
[12:00.900 --> 12:07.560]  For the APC reception, we need a software-defined radio USB dongle. In our case, we're using the
[12:07.560 --> 12:14.820]  RTL-SDR dongle. The link to it is provided on the last page of this presentation.
[12:16.100 --> 12:21.060]  And then we need an antenna to connect to the dongle. There are dongle sets that you can buy
[12:21.060 --> 12:27.340]  including a general-purpose antenna. That's a good start. If you're setting up a Raspberry Pi
[12:27.340 --> 12:33.340]  from scratch, you can follow along this step. If you're not familiar with terminals SSH and how to
[12:33.340 --> 12:40.760]  find out the IP of your Raspberry Pi, it might be easier to follow the Noobs setup guide with mouse
[12:40.760 --> 12:48.640]  and keyboard from the official Raspberry Pi page. On a PC or laptop that has an SD card reader,
[12:48.640 --> 12:55.220]  install a Raspberry Pi OS to the microSD card. We're using Imgur that is available from the
[12:55.220 --> 13:05.220]  Raspberry Pi download section. So first, we choose the operating system as Raspberry Pi OS 32 bits
[13:05.940 --> 13:18.230]  and the SD card that we want to install it. And then press write. After the SD card is finished,
[13:18.230 --> 13:24.870]  we insert it into the Raspberry Pi. Connect the Raspberry Pi to the LAN network using the cable.
[13:25.070 --> 13:32.510]  Add the SDR USB stick with antenna attached to it and power up the Raspberry Pi. Give it a few
[13:32.510 --> 13:39.730]  seconds. Now we need to find out what the IP of our Raspberry Pi on our network is.
[13:39.790 --> 13:45.550]  You can normally see this somewhere on your router's configuration home page like shown here.
[13:46.230 --> 13:51.770]  If you can't find it out for some reason, you can always resort to attaching a monitor and keyboard
[13:51.770 --> 13:59.070]  and mouse to the Raspberry Pi and finishing the setup in that way. The initial login to the
[13:59.070 --> 14:05.100]  Raspberry Pi should work with username pi and password raspberry.
[14:06.830 --> 14:11.210]  Next, we're going to change the default password, configure the time zone,
[14:11.210 --> 14:16.620]  and optionally configure wireless LAN. So to do this, let's start raspi-config.
[14:17.030 --> 14:27.230]  Then select change user password and enter a new password twice.
[14:34.170 --> 14:43.710]  Next, let's select four localization options. Change the time zone and select the
[14:44.630 --> 14:54.360]  continent and country you're in. Then let's select localization options again
[14:54.780 --> 14:59.460]  and change the VLAN country to your country.
[15:06.060 --> 15:11.100]  If you want to configure wireless LAN, then you can do this under network options.
[15:17.430 --> 15:23.310]  Once installed, the configuration file for the software needs to be modified to record the desired
[15:23.310 --> 15:29.950]  frequencies and produce an output. The full set of configuration options you can find on the wiki
[15:29.950 --> 15:39.860]  page with the provided link. After the software is installed, the configuration file for the software
[15:39.860 --> 15:46.200]  needs to be modified. To make the configuration easier, we have a simple page that generates
[15:46.700 --> 15:53.760]  a configuration file for you in five steps. The first step is to specify your device,
[15:53.760 --> 16:00.400]  the type, give it some name, and you can leave the bandwidth as is for most cases.
[16:00.800 --> 16:08.540]  The second step is to specify your location, either by address, by longitude, latitude,
[16:08.540 --> 16:13.740]  or if your device supports it, you can use the current location button.
[16:21.930 --> 16:28.930]  Once you have specified your location, you can search airports that are close by.
[16:29.850 --> 16:34.210]  So in our case, we're choosing the Zurich airport,
[16:37.870 --> 16:44.250]  and this will provide you with a set of frequencies which are used in this airport.
[16:44.750 --> 16:50.490]  So you can select the frequencies which you want to record,
[16:50.490 --> 16:58.090]  but there is a restriction that the specified bandwidth of your device that you specified on top
[16:58.690 --> 17:05.590]  needs to fit all the frequencies in it. So if you have a bandwidth of 2.4
[17:07.450 --> 17:12.730]  megahertz, the frequencies can be more than 2.4 apart.
[17:13.670 --> 17:21.270]  So if we're selecting all the frequencies here and assigning them all to one device,
[17:21.270 --> 17:27.370]  we'll end up with an error message saying that we've exhausted the bandwidth.
[17:27.870 --> 17:37.310]  So instead of 2.4, we are now at 13. So we deselect the frequencies that don't fit in
[17:37.310 --> 17:42.370]  to our bandwidth, and the error message should disappear.
[17:53.380 --> 17:58.240]  And based on these options, a configuration file should be generated.
[18:05.560 --> 18:14.760]  So we're copying this file or downloading it, and then we have to transfer it to our Raspberry Pi.
[18:17.790 --> 18:26.670]  To copy the configuration into our RTL-Airband.conf file, I'm using the Nano Editor.
[18:26.670 --> 18:31.250]  So first I delete all of the existing example configuration,
[18:31.650 --> 18:36.530]  and then I'm pasting in the generated configuration file.
[18:42.720 --> 18:46.840]  After that, we're exiting and saving the file.
[18:53.550 --> 18:58.590]  Next, let's test if our setup is working correctly by looking at the signal
[18:59.020 --> 19:07.800]  and the output that is produced. To test if the software is working, we can start it
[19:07.800 --> 19:13.500]  in the foreground mode. It's also useful to see if the noise level estimation and squelch
[19:13.500 --> 19:20.250]  are working fine. The two numbers indicate the estimated noise level and the signal level.
[19:23.350 --> 19:29.010]  And the star appears besides the two numbers if the recording kicks in.
[19:30.330 --> 19:36.030]  So for instance, if you always see a star, meaning it's recording all the time, you might
[19:36.030 --> 19:42.050]  need to adjust the gain setting. More information can be found in the troubleshooting section
[19:42.050 --> 19:49.490]  on the wiki page. Regarding output, there is an output airband folder in the home directory
[19:49.490 --> 19:54.650]  where the raw files and the metadata text file is stored.
[19:56.250 --> 20:04.330]  And then once it is encoded to FLAC, it will be visible in the encode subfolder in that directory.
[20:18.320 --> 20:22.540]  Configuration options that are generated by the config page are listed here.
[20:23.440 --> 20:28.220]  Multi-channel mode was chosen so that we're sure not to miss any transmissions
[20:28.220 --> 20:33.800]  in the channels that we're interested in. The other option would be frequency scanning.
[20:34.740 --> 20:40.140]  Then we chose raw output format so we could encode it to FLAC.
[20:40.620 --> 20:48.920]  Other options are mp3, icecast, or pulse audio. So you can also set up an icecast server to have
[20:49.060 --> 20:54.860]  a streaming version of the channels to listen to at home in parallel. The goal of the project
[20:54.860 --> 21:00.980]  in later stages is to provide the feeder software part to send the audio to OpenSky and reach the
[21:00.980 --> 21:08.180]  audio with annotations and potentially other data. The gain setting is set to a default level,
[21:08.180 --> 21:13.320]  but it might need to be adapted. Especially if you have a good antenna with some
[21:15.220 --> 21:19.320]  amplification, then the gain setting might have to be lowered, else you will have
[21:19.320 --> 21:31.770]  recording noise all the time. So for the setup of the antenna, in general, there should be no
[21:31.770 --> 21:37.950]  obstacles between the sender and the antenna. So in the ATC case, the senders are the airplanes
[21:37.950 --> 21:45.690]  and the airport tower. These examples are taken from the ADS-B receiver kit on the OpenSky network
[21:45.690 --> 21:52.390]  homepage. So only show airplanes and not the airport, but the same principles apply.
[21:52.770 --> 21:58.390]  On these pictures, you can see non-ideal setups with obstacles or a narrow angle.
[21:58.590 --> 22:04.850]  Finally, to give a short outlook, we will be providing some sort of feeder soon to be able
[22:04.850 --> 22:11.170]  to process the audio recordings on the server side and make it available to feeders through an API.
[22:12.190 --> 22:19.570]  Here is a collection of links that we used in this presentation. First, the AirBand GitHub repo
[22:19.570 --> 22:26.930]  and their wiki page, then the config page that helps you put together a configuration file,
[22:27.130 --> 22:32.690]  a link to the Raspberry Pi where you can find things like installation instruction,
[22:32.690 --> 22:40.270]  the RTL-SDR dongle we used in this setup, a link to the ADCO2 project page,
[22:40.270 --> 22:44.870]  and finally a link to the OpenSky network homepage where you can also find things like
[22:44.870 --> 22:51.170]  how to build an ADS-B receiver. I hope this tutorial was easy to follow along
[22:51.170 --> 22:55.270]  and that you're able to make your own ADS-B receiver with it
[22:56.050 --> 22:59.770]  and happy to answer questions that you might have right now.