I think it’s fairly clear from my last project of ADSBpi, my main interest is to improve the reach of my ADS-B reception and plotting. Unfortunately, most of my monitoring areas are compromises due to building construction, shadowing and sub-optimal antennas. As ADS-B transmissions are packetized, it should be a simple matter of combining the transmissions together in a sensible method to essentially improve the reach of your virtual-radar display.
It’s definitely not a new idea to combine the data from multiple receivers to give yourself a wider ranging display. At the moment, many of the services, such as ADSBHub often require you to share your data publically to reap the benefits of being able to combine the data.
I really didn’t want that. One of the main reasons is that the ADS-B data can be misused, or used commercially and I’d rather not have the data I worked hard to collect end up in other people’s hands.
dump1090 to the Rescue
Aside from being a superior ADS-B decoder, dump1090 also offers a very tantalizing possibility of running as an ADS-B hub itself. While it is generally used in Linux, most of the plane plotting software normally runs in Windows – e.g. adsbScope. While you can try to use Wine or run virtual machines to get around this, I decided it would be interesting to see if we could get around it another way.
That’s where Cygwin comes in. It’s a not-so-true-to-Linux, Linux-like environment that runs under Windows. Many people don’t like it because they have to make special changes to accommodate building under Win32 – and it’s not like I’ve seen much mentioned about rtl-sdr and dump1090 being specially made for building under Cygwin.
The first step is to install Cygwin, making sure to also install libusb packages above the default selection (which is pretty much enough). Then it’s time to git clone the rtl-sdr and dump1090 repositories.
Following the rtl-sdr cmake build instructions work just fine – but not the line sudo ldconfig as Cygwin has no ldconfig! But that’s okay.
Then, if you just go to dump1090 and try to build it, you will run into trouble as pkg-config cannot find the rtl-sdr library! In order to fix this, you need to run
Then you will find that the build succeeds.
dump1090 Problems under Win32
It would be very quickly noted that running ./dump1090 will yield a segmentation fault, so running this superior decoder under Windows with a RTL2832u dongle attached is a no-go. Sorry. I didn’t investigate any further as to why this is the case.
But the good part is that running it as an ADS-B Hub works just fine. It’s as simple as invoking it with
./dump1090 --interactive --net-only
and then it’s time to funnel the data in.
dump1090 as an ADS-B Hub
The way dump1090 works as an ADS-B Hub is to (by default) accept data on port 30001 and broadcast data on 30002.
So, in order to funnel the data from other dump1090 instances, we can use netcat –
nc <source ip> <source port> | nc <localhost> <destination port>
So, for example, if I’m funneling from my ADSBpi at 10.20.30.1 to the dump1090 instance running under Windows, that would be
nc 10.20.30.1 30002 | nc 127.0.0.1 30001
Simple yeah? You can even funnel a running ADSB# instance on the same machine into dump1090 to combine it with another receiver – e.g.
nc 127.0.0.1 47806 | nc 127.0.0.1 30001
I think by now, it is clear what the potential for this is. You can be running any ADS-B receiver software which outputs AVR format, and combine it all for one plane plotting software – e.g. adsbScope, Virtual Radar Server etc.
In order to get the most coverage as I can sensibly get, I leveraged my ADSBpi, my main desktop and another machine I have access to which is geographically much closer to the airport via VPN.
Of course, in theory, the possibilities are endless.
The result was quite impressive though – for once, I have detail on ground level movements.
And now I have much better detail on the approach circuit and take-off circuits (that’s about 10 hours accumulated data).
The range itself is not the best I’ve seen, but it’s better than any one of the set-ups on their own in their current positions – so the hub definitely works.
Advantages and Caveats
The advantages of using dump1090 as your ADS-B hub are numerous:
- You can improve your coverage by adding together the packet streams from multiple receivers.
- It can accept any AVR formatted stream from any other program. With the right switches, BEAST binary mode may be possible too.
- It can accept an arbitrary number of input data streams and serve an arbitrary number of clients. I haven’t tested the limits!
- Your ADS-B plotting software can remain connected to the dump1090 instance while you disconnect or reconfigure your data sources – and if you have numerous data sources, some may continue to operate while you take one offline and add it again later.
It wouldn’t be a complete post if I didn’t mention some of the caveats. So far, from my usage of this system, there are a few –
- The addition of more receivers to the pool creates a higher chance of the occasional false decode (i.e. plane which is unrealistically far away) slipping through into your plots which can ruin your maximum range assays and make for some strange results. This can be seen as the thick red north-west lines in the plot above.
- The addition of multiple streams especially running different software will cause the track in your plotting program to jitter forwards and backwards as each receiver has a slightly different delay, and the network interconnection by TCP (and retransmits, and other latencies) will add up and cause this phenomenon. This is visible also as wavy or furry lines that jump back and forth in complicated manners.
So, unfortunately, it’s not a perfect solution. It could (in theory) be improved by examining packets within a certain time frame (20 seconds?) and discarding duplicates received later, or by attempting to synchronize streams. In the case of Mode A/C Multilateration, a high resolution free running timer is used in each receiver which is compared with other synchronized receivers who receive the same packets to determine the signal’s time of arrival at known locations to be able to determine the plane’s position. In theory, if multilateration time stamping was in use, then it would be possible to synchronize decoded streams, although I suppose this would come at increased CPU load and network traffic costs.
So, in my case, building it under Cygwin has helped me eliminate the need for a virtual machine, stuffing around in Wine or dedicating another machine just for ADS-B hub purposes, while improving my coverage. Thanks very much Salvatore Sanfilippo!