Receiving ACARS Signals

 

Last month I talked a little bit about the secret world of aviation communication that involved radio signals coming from the little screen that you typically find in the middle of the cockpit of commercial aircraft. 

Now that I learned a bit about what comes out of that box, it was only natural that I should try to listen in on the transmissions that are coming from the aircraft flying nearby.  

As I also mentioned last month, I had a few Software Defined Radio (SDR) dongles sitting around that I really wanted to find a use for.

For those who may not be familiar with them, a Software Defined Radio (SDR) is a radio communication system where the components that you would have traditionally equated to physical electronic circuits and interfaces  (like mixers, filters, amplifiers, modulators/demodulators, detectors, dials, switches, etc.) are instead implemented by software on a computer. 

The big thing is that traditional radios are usually built for a specific purpose with fixed hardware tuned for specific frequencies and modulation types - which is why for example, you can't listen to cell phone conversation through your bedroom clock radio. SDRs on the other hand, digitize the signal as early as possible (usually right after the antenna), and then do all the signal processing through software.

As a result, your typical SDR looks like a very small brick that plugs into the side of your computer

Software Defined Radio

The beauty of this arrangement is that this really opens up what you can listen to over the airwaves, your only restriction is purely based on the software that you are running on your computer. 

A while back I "inherited" a Chromebook computer. While I have nothing personally against the Chrome operating system in of itself, I found that the amount of SDR tools for Chrome a bit lacking. 

Since the Chromebook was fairly new and had some pretty powerful specs, I was wondering about perhaps installing an operating system that had a bit more of a software selection available. Since installing a version of windows looked very much like a non-starter, it wasn't until I came across the  MrChromebox.tech website where I found out that I could install Linux on my Chromebook with relatively little effort. Walking through how I did the install will probably be covered in a future post, but for now, I successfully installed a copy of MX Linux on the Chromebook and I was now ready for setting up the radio,  

Once I had my computer all set up and ready to roll, my next area of focus was to figure out what sort of software I want to use to pull in the ACARS transmissions. 

The beauty of  Linux is that there is a large library of open source software out there, a lot of which is supported by a very active community of enthusiasts. 

So it wasn't much a surprise to find a decent number of applications out there that could work with my SDR to snoop on aircraft. 

With all the choices available, I had to winnow down the list to one that had the following criteria that I was looking for:

• Can run as a command line script (the idea here is that I could schedule my Chromebook to automatically start scanning as soon as it's booted up). 
• Easily customizable to scan for certain ACARS message labels (this way I can only pull in the messages that I am only interested in) 
• Can export the results of the scan out to a text file, which I can use to feed in another application for further processing   

After reviewing the options, I settled on ACARSDEC which was written by Thierry Leconte and seems to have a fairly robust support community behind it. 

This application looks to be very powerful, with the ability to monitor and report on multiple SDR's at once (a bit overkill for me, but good to know that I have lots of room for future expansion), and of course more importantly, it ticked all the boxes on what I was looking for, 

The bulk of the information out there for installing ACARSDEC seems to be primarily tailored for installation on a Raspberry Pi. That would certainly make sense since I would fully expect this to be the main platform for doing this sort of scanning, however, since I had a bit of a different set up so I found that the published instructions on installing ACARSDEC weren't working very well on my MX Live installation. 

After some playing around, I ended up with a process that worked for my particular set-up.  For my particular case I used RTL_SDR as the background SDR tool (ACARSDEC can also support Airspy and SDRPlay too) 

To install ACARSDEC on my Chromebook, I opened up a terminal session and entered the following commands:

git clone GitHub - TLeconte/acarsdec 

cd arsdec

mkdir build

cd build

cmake .. -Drtl=ON

make

sudo make install

With that done, I plugged in my SDR dongle into the Chromebook and did a quick test of the dongle by executing the RTL_TEST function at the terminal command line. Once I got the message back that the dongle was on line and receiving, I was ready to listen to airplanes.  

The next step was to craft the command that I needed to execute in order to gather the specific messages that I wanted to capture.

To do this I needed to find what the most active VHF frequencies are in my area. Luckily I am fairly close to a few airport, with the closest major one being Pearson airport near Toronto, so I should have a healthy amount of traffic to listen too. 

To determine what frequencies to use, I plugged in the known ACARS frequencies (which are pretty easy to find online) into a radio scanner that had a nice feature of counting the number of transmissions that happen on a frequency. After running the scanner for 24 hours I got a very good sense what ACARS frequencies were the most active.

To do this I had to run the ACARSDEC command at the terminal window in MX Linux. 

In a broad term - ACARSDEC is activated using this command structure:

acarsdec  [-o lv] [-t time] [-A] [-b filter ] [-e] [-n|N|j ipaddr:port] [-i stationid] [-l logfile [-H|-D]] -r rtldevicenumber  f1 [f2] [... fN] | -s f1 [f2] [... fN]

Granted this looks pretty cryptic, but these are the mainly used to define the options you want to use so that that does give you a bit of an idea that is within the application. 

For my initial test, I wanted to focus on what I could actually hear on the frequencies that I've identified from my scanner as the most active. I wanted to store what was picked up in a Daily Log file in a JSON file format. 

Basically I need to set the appropriate parameter value for:

• Setting my output to the JSON format (-o)
• I also don't really care about empty messages (-e)  
• I want to output the data to a file called Daily.log
• I also want to create a new log file daily (-D) 
• I also need to define the where to find my SDR to scan (-r)
• Once I know what particular messages I wanted to gather, I can define them with a filter list (-b) 
• And I can also list the frequencies that I've found the most activity to scan

With that I entered the following command to start monitoring:

acarsdec -o 4 -e -l Daily.log -D -r 0 130.450 131.550 131.725 130.025 131.125

Since I wanted to get all of the messages at the moment, I didn't define any filters. 

After executing the command, ACARSDEC started to monitor away with no issues and I was able to collect a significant amount of aircraft data. 

Sample Output

There was one small quirk that I did uncover which usually manifested itself after the application had been running a while. Every once in a while I found that the application stopped recognizing the SDR and errored out the process. 

I wasn't able to really get to the bottom of the problem, however I found that by adding the ACASDEC command as part of the start up processes when the Chromebook reboots along with a scheduled task on the Chromebook to have it reboot every hour seemed to be a pretty good workaround. 

Now that I have establish a way to monitor and log all the activity in my area, the next step is to collect some data for a while and take a look at what kind of interesting stuff could I use for my next phase of the project.