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 for some reason you don't, you probably want to check 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
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:
No comments:
Post a Comment