WEBVTT 00:07.400 --> 00:19.740 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. 00:20.820 --> 00:24.300 Our presentation is divided into two parts. 00:24.300 --> 00:33.260 I will talk about OpenSky Network, about air traffic control and about the ADCO2 project. 00:33.640 --> 00:47.780 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. 00:48.620 --> 00:50.340 OpenSky Network. 00:50.340 --> 01:01.520 Our mission is to improve the security, reliability and efficiency of the airspace usage by sharing ATC related data to public. 01:02.240 --> 01:21.640 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. 01:21.640 --> 01:53.140 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. 01:53.180 --> 01:56.560 A few facts about our network. 01:56.560 --> 02:12.900 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. 02:12.900 --> 02:28.620 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. 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:43.160 So pilots are facing pretty much a formidable task. 02:43.160 --> 02:56.780 They need to take a poorly maneuverable fast-moving aircraft from point A to point B without causing an accident. 02:58.060 --> 03:03.820 So you can imagine that the help would be needed. 03:04.020 --> 03:10.200 And here is the place where air traffic controller comes to play. 03:10.200 --> 03:33.460 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. 03:33.460 --> 03:48.900 So they can advise pilots how to maneuver through the airspace the safest and most efficient way possible. 03:49.680 --> 03:58.220 So the tasks... there are three main tasks for the air traffic controller. 03:58.220 --> 04:07.140 They have to make sure that the aircraft do not collide with each other and also do not collide with terrain. 04:07.260 --> 04:29.200 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... 04:29.820 --> 04:35.320 they exchange information between pilot and rescue units, for example. 04:37.240 --> 04:39.900 So how it's done? 04:39.960 --> 04:46.360 The short and easy answer is that via using radio. 04:46.400 --> 04:59.700 So if pilot wants to do something with the aircraft, they will ask air traffic controllers if it's safe to do so. 04:59.920 --> 05:20.260 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. 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:58.180 And by saying it's most commonly used, I mean there are other frequencies also that are used in some instances. 05:58.180 --> 06:13.380 For example, in oceanic areas, lower frequencies which have better propagation features or satellite communication also is used often in those areas. 06:13.500 --> 06:27.880 But as VHF communication provides the highest quality at the moment, it's preferred and used wherever possible. 06:27.880 --> 06:33.460 And that's why it's the most interesting also to listen to. 06:34.440 --> 07:07.560 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. 07:07.560 --> 07:19.100 For example, pilot wants to double check the instructions gotten from the pilot. 07:19.280 --> 07:31.500 At current point of time, the pilot should, to be able to do that, the pilot should write these introductions down. 07:31.600 --> 07:43.180 But as pilots while flying 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:09.340 But for building that sort of an automated system, transcription system, large amounts of data would be required. 08:09.340 --> 08:15.220 And that's why HATCO2 project was brought to life. 08:15.220 --> 08:36.820 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. 08:36.820 --> 08:42.380 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 --> 09:09.490 And another one taking care of automatic transcriptions and also storing them so these transcriptions then can be later used to whichever reason needed. 09:09.810 --> 09:25.650 And lastly, the legal aspects of making that sort of recordings and sharing them with other 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:52.970 So that's it from my part. 09:52.990 --> 10:03.950 Thank you for listening and I will now give word to Fabian who will show you how the receiver should be set up. 10:03.950 --> 10:06.530 Thanks and enjoy! 10:12.210 --> 10:21.410 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. 10:21.710 --> 10:27.310 We will first go through a setup of the Raspberry Pi using SSH. 10:27.310 --> 10:39.170 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. 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:55.650 After installing the software, I will show you how to configure the software based on your location using a configuration web page. 10:56.210 --> 10:59.730 And finally, we will test the setup if it's working. 11:00.130 --> 11:06.390 At the end, 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:20.760 As a general purpose, low-cost computer, we're using a Raspberry Pi. 11:20.980 --> 11:25.260 It doesn't really matter which version, even a version 1 should work. 11:25.380 --> 11:32.390 Although if you want to use multiple downloads 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:55.900 If you already have a running Raspberry Pi or setting up with monitor and keyboard, you can also use a wireless LAN. 11:56.040 --> 12:00.840 You also need a microSD card which serves as a Raspberry Pi disk. 12:00.900 --> 12:05.980 For the APC reception, we need a software-defined radio USB dongle. 12:05.980 --> 12:09.800 In our case, we're using the RTL-SDR dongle. 12:10.300 --> 12:14.820 The link to it is provided on the last page of this presentation. 12:16.100 --> 12:19.140 And then we need an antenna to connect to the dongle. 12:19.140 --> 12:23.360 There are dongle sets that you can buy including a general-purpose antenna. 12:23.360 --> 12:24.940 That's a good start. 12:25.300 --> 12:30.020 If you're setting up a Raspberry Pi from scratch, you can follow along this step. 12:30.020 --> 12:44.100 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. 12:45.140 --> 12:52.180 On a PC or laptop that has an SD card reader, install a Raspberry Pi OS to the microSD card. 12:52.180 --> 12:57.740 We're using Imgur that is available from the Raspberry Pi download section. 12:59.100 --> 13:09.080 So first, we choose the operating system as Raspberry Pi OS 32 bits and the SD card that we want to install it. 13:09.080 --> 13:10.820 And then press write. 13:15.890 --> 13:20.810 After the SD card is finished, we insert it into the Raspberry Pi. 13:20.970 --> 13:24.870 Connect the Raspberry Pi to the LAN network using the cable. 13:25.070 --> 13:31.450 Add the SDR USB stick with antenna attached to it and power up the Raspberry Pi. 13:31.710 --> 13:33.710 Give it a few seconds. 13:34.170 --> 13:39.730 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:56.510 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. 13:57.390 --> 14:05.100 The initial login to the Raspberry Pi should work with username pi and password raspberry. 14:06.830 --> 14:13.730 Next, we're going to change the default password, configure the time zone, and optionally configure wireless LAN. 14:13.730 --> 14:16.620 So to do this, let's start raspi-config. 14:17.030 --> 14:21.350 Then select change user password and 14:24.730 --> 14:27.230 enter a new password twice. 14:34.170 --> 14:39.030 Next, let's select four localization options. 14:39.610 --> 14:47.630 Change the time zone and select the continent and country you're in. 14:50.840 --> 14:59.460 Then let's select localization options again 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:25.710 Once installed, the configuration file for the software needs to be modified to record the desired frequencies and produce an output. 15:25.710 --> 15:32.250 The full set of configuration options you can find on the wiki page with the provided link. 15:35.940 --> 15:41.860 After the software is installed, the configuration file for the software needs to be modified. 15:41.940 --> 15:49.600 To make the configuration easier, we have a simple page that generates a configuration file for you in five steps. 15:49.900 --> 16:00.400 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. 16:00.800 --> 16:13.740 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. 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 --> 17:02.430 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. 17:02.430 --> 17:12.730 So if you have a bandwidth of 2.4 megahertz, the frequencies can be more than 2.4 apart. 17:13.670 --> 17:27.370 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. 17:27.870 --> 17:31.710 So instead of 2.4, we are now at 13. 17:33.650 --> 17:42.370 So we deselect the frequencies that don't fit in 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:36.530 So first I delete all of the existing example configuration, 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 --> 19:01.470 Next, let's test if our setup is working correctly by looking at the signal and the output that is produced. 19:04.220 --> 19:09.920 To test if the software is working, we can start it in the foreground mode. 19:09.920 --> 19:15.120 It's also useful to see if the noise level estimation and squelch are working fine. 19:15.420 --> 19:20.250 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:38.210 So for instance, if you always see a star, meaning it's recording all the time, you might need to adjust the gain setting. 19:38.590 --> 19:44.030 More information can be found in the troubleshooting section on the wiki page. 19:44.890 --> 19:54.650 Regarding output, there is an output airband folder in the home directory 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:31.280 Multi-channel mode was chosen so that we're sure not to miss any transmissions in the channels that we're interested in. 20:31.280 --> 20:33.800 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:45.520 Other options are mp3, icecast, or pulse audio. 20:45.740 --> 20:53.080 So you can also set up an icecast server to have a streaming version of the channels to listen to at home in parallel. 20:53.520 --> 21:04.380 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. 21:05.460 --> 21:10.380 The gain setting is set to a default level, but it might need to be adapted. 21:10.540 --> 21:22.360 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. 21:27.110 --> 21:34.450 So for the setup of the antenna, in general, there should be no obstacles between the sender and the antenna. 21:34.450 --> 21:40.030 So in the ATC case, the senders are the airplanes and the airport tower. 21:41.010 --> 21:47.190 These examples are taken from the ADS-B receiver kit on the OpenSky network homepage. 21:47.210 --> 21:52.390 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:11.170 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. 22:12.190 --> 22:16.990 Here is a collection of links that we used in this presentation. 22:16.990 --> 22:40.270 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, 22:40.270 --> 22:47.650 and finally a link to the OpenSky network homepage where you can also find things like how to build an ADS-B receiver. 22:48.330 --> 22:59.770 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.