HackRF and ADS-B and COVID-19 in pictures

HackRF and ADS-B and COVID-19 in pictures

Given the current COVID-19 situation, I thought I'd take a look at what else was in the air. With not much to do these days, it was a good reason to pull out my ADS-B aerial and see about getting my HackRF One device to play with VirtualRadar. Some pictures from VirtualRadar are in the second half of this post, the first half talks about setting things up.

In my blog post from 2016 I described my experience getting ADS-B going with an rtl device. If you're reading this, you probably already know what ADS-B is, but if you want a refresher then check out my earlier post.

Setting Things Up

HackRF isn't supported by the dump1090 or the rlt_adsb applications for Linux, so I spent quite a bit of time trying to work out how to get some "1090" software to work with VirtualRadar. I tried gr-air-modes but it was a total disaster trying to "make" even under Debian 10 (Buster) due to a pyqt4 dependency and I almost gave up the whole idea.

In the end I found a fork of dump1090 that installed and worked with little drama. The configuration of VirtualRadar is slightly different from that in my rtl post.

Here's the dump1090 fork install steps - it wasn't quite as straightforward as the doc suggested.

This bit went fine:

$ sudo apt-get install librtlsdr0 librtlsdr-dev libhackrf-dev libairspy-dev libsoxr-dev  
$ chmod 755 Downloads/SDRplay_RSP_API-Linux-2.13.1.run  
$ ./Downloads/SDRplay_RSP_API-Linux-2.13.1.run  
$ sudo ldconfig  
$ cd personal/git/  
$ git clone https://github.com/itemir/dump1090_sdrplus.git

This bit did not go so fine:

$ cd dump1090_sdrplus/  
$ make  
.../usr/bin/ld: dump1090.o: in function `readerThreadEntryPoint':  
home/xxx/personal/git/dump1090_sdrplus/dump1090.c:852: undefined reference to `rtlsdr_read_async'  
usr/bin/ld: dump1090.o: in function `main':  
home/xxx/personal/git/dump1090_sdrplus/dump1090.c:3172: undefined reference to `rtlsdr_close'  
collect2: error: ld returned 1 exit status  
make: \*\*\* \[Makefile:12: dump1090\] Fehler 1  

(Fehler is German for “failure”)

This turns out to be a known issue requiring (on Debian) an edit of /usr/lib/x86_64-linux-gnu/pkgconfig/librtlsdr.pc :

prefix=/usr  
exec_prefix=\${prefix}  
libdir=\${exec_prefix}/lib  
includedir=\${prefix}/include  

Then I could build:

$ make  
cc -g -o dump1090 dump1090.o anet.o  -lrtlsdr -lhackrf -lairspy -lsoxr -lpthread -lm -lmirsdrapi-rsp  

Starting dump1090, it first looked for rtlsdr and then for a HackRF:

$ ./dump1090  
No supported RTLSDR devices found.  
Unable to initialize RSP  
HackRF successfully initialized (AMP Enable: 0, LNA Gain: 32, VGA Gain: 48).  

Interactive mode fairly quickly showed promising results:

$ ./dump1090 --interactive  

...  
  
Hex    Flight   Altitude  Speed   Lat       Lon       Track  Messages Seen  .  
--------------------------------------------------------------------------------  
3e6bd1 DKGAJ    3900      0       0.000     0.000     0     8         0 sec  

Here I tell the application that I have a HackRF and that I want it to stream the results over the network, binding to port 8081 instead of the default 8080 for the web display because VirtualRadar will fail to start when it also tries to bind to port 8080.

$ ./dump1090 --dev-hackrf --net --net-http-port 8081  
HackRF successfully initialized (AMP Enable: 0, LNA Gain: 32, VGA Gain: 48).  
*8d471f59ea3e9858011c08f4aa9d;  
CRC: f4aa9d (ok)  
Single bit error fixed, bit 82  
DF 17: ADS-B message.  
  Capability     : 5 (Level 2+3+4 (DF0,4,5,11,20,21,24,code7 - is on airborne))  
  ICAO Address   : 471f59  
  Extended Squitter  Type: 29  
  Extended Squitter  Sub : 2  
  Extended Squitter  Name: Unknown  
    Unrecognized ME type: 29 subtype: 2  

This dump1090 version seems to have VirtualRadar directly in mind because the default ports it uses to stream data was what VirtualRadar expects by default.

$ netstat -pano \| grep dump  
tcp        0      0 0.0.0.0:**8081**            0.0.0.0:\*               LISTEN      17413/./dump1090     aus (0.00/0/0)  
tcp        0      0 0.0.0.0:**30001**           0.0.0.0:\*               LISTEN      17413/./dump1090     aus (0.00/0/0)  
tcp        0      0 0.0.0.0:**30002**           0.0.0.0:\*               LISTEN      17413/./dump1090     aus (0.00/0/0)  
tcp        0      0 0.0.0.0:**30003**           0.0.0.0:\*               LISTEN      17413/./dump1090     aus (0.00/0/0)  

VirtualRadar is configured according to the following screenshot, most of this is defaults:

Note that if you use google as the map provider then you need to setup API access and you probably don't want to do that, so use Leaflet.

And we're away.

There Must Be Something in the Air

Over a few hours I did see activity but the sky wasn't exactly alive wih commercial traffic. I should also add that I face west and it's quite possible that my position captures very little of the Munich airport traffic.

Overwhelmingly most of the planes I saw today were private. Obviously registered around near where I live (Munich, Germany) with the curious exception of this fellow out of the US:

Tel-Aviv

It's hard to say how many airlines were running cargo, but this Egyptian one obviously was:

Someone in Munich was having a bad day, here's a rescue helicopter:

Qatar

Saudi

China

Libya - Not sure if the flight path is accurately recorded: