Increasing ADS-B Reach with dump1090

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.

Existing Systems

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

export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig

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 to the dump1090 instance running under Windows, that would be

nc 30002 | nc 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 47806 | nc 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.

My Setup

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.

ADSB Network Diagram

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).

ADSB circuits near airport YSSY

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!

About lui_gough

I'm a bit of a nut for electronics, computing, photography, radio, satellite and other technical hobbies. Click for more about me!
This entry was posted in Computing, Radio and tagged , , . Bookmark the permalink.

16 Responses to Increasing ADS-B Reach with dump1090

  1. Pingback: Combining Multiple RTL-SDRs for Improved ADS-B Reception -

  2. Liviu says:

    I compiled rtl-sdr in Cygwin instead of using the provided package and dump1090 works with the dongle.

    • Liviu says:

      Sorry, I wanted to say libusb.

      • lui_gough says:

        Dear Liviu,

        Thanks for your comment, that’s great news! Sorry I didn’t have the time to investigate as to why it didn’t work, but I suppose your solution sounds simple enough :). I’ll give that a go when I have some time. I wonder whether it is because the supplied libusb under Cygwin is a bit out-of-date …

        – Gough

  3. Marcio says:


    I have two ADSBPi running at different locations, one locally and another one remotelly. I would like to send data from the remote ADSBPi to the local ADSBPi using netcat, but I didn’t manage to make it work.

    Here what’s I have done in the remote machine.

    nc 30002 | nc 30001

    Thanks for your help.

    • lui_gough says:

      Dear Marcio,

      First of all, both RPis should be connected to the same network and you need to know the IP address of both Pis (i.e. via ifconfig). It is most stable if they are given static IPs which will not change, as opposed to DHCP IPs which may change depending on which other machines are on the network – you can change this behaviour by editing /etc/network/interfaces

      Then, you will need to execute (on the local Pi):
      nc (remote IP) 30002 | nc (local IP) 30001

      The local IP you use can just be the localhost IP (as you want to forward to “yourself”) For example:
      nc 30002 | nc 30001

      If you want to see it working as well, you could get a bit fancy and do this:
      nc (remote IP) 30002 | tee /dev/tty | nc (local IP) 30001

      This will copy all of the AVR packets from the remote dump1090 instance to the local dump1090 instance *and* let you see the packets in the running console window (so you can see whether it’s working or not).

      This assumes that both are running dump1090 – and the local Pi will output the combined data on Port 30002.

      – Gough

  4. s4mdol says:

    nice works…just wonder..are you suing pp to plot the track/path?(as on photo above)

  5. lui_gough says:


    All plots were made using adsbScope and external screen capture software.

    – Gough

  6. Roger says:

    Hi Gough
    Just for your Information: Both the server and the client side of ADSB Hub (ADSB-Concentrator Server) are free. So you are able to build your own (private) server without the need of sharing your data with other users if you don’t want to. Although the software was meant as a possibility to globally share data, you can make this also for your own. Other users are already doing this also. The server side needs a Windows “Server” (XP is ok too) and a connection to a NTP Server to synchronize the time. If you are interrested, feel free to send me a mail.
    Regards, Roger

    • lui_gough says:

      Dear Roger,

      Thanks very much for the comment – sorry, I was not aware that the ADSB Hub server was available for free. That would make it much easier for many people to run their own (say if they are concerned about data misuse, would prefer their own set-up for reliability reasons, etc).

      That being said, having alternatives is also a valuable thing. Thanks very much for letting me know, I’m sure many people reading this might be interested in the future (although, right now, I’m a bit busy with a lot of things on my plate to play with it). Natively running on Windows is a bonus for many as well as it makes it much more accessible.

      – Gough

  7. Claudinei Walker says:

    Hi Mr. Gough,

    In my project I’m using two receivers made with Raspberry Pi. One of them is running in other city (Rio de Janeiro) far from here something about 400 Km. The local Raspberry Pi (São Paulo) it’s running as a hub. Supose that these two receivers detect the same aircraft, what exactly the DUMP1090 does with the data that comes from these two receivers? Consider just the more new data? Calculate an average position (time and space)? What is the strategy for handle the same data that comes from different receivers? Thank you very much!

    Claudinei Walker.
    São Paulo – Brazil.

    • lui_gough says:

      Dear Claudinei,

      As far as I can tell, dump1090 doesn’t do any intelligent combining and merely combines complete messages when they arrive. This is why I observed the “back and forth” jumping of aircraft, especially when receiving the data from remote locations, as the other receiver’s data has to travel through the internet, and undergo VPN/encryption which results in almost 200ms of delay.

      You might need to investigate some more intelligent combining solutions if you want to ensure that the latest data is used (which makes the most sense anyway). This will require keeping a list of aircraft in memory and the latest few packets for each aircraft to filter out the later-arriving duplicates. I’m not sure how adsbhub handles this – but it seems to be another solution to combining ADSB data that I haven’t tried myself.

      – Gough

  8. Brian says:

    Can you tell how to get netcat running from one Rpi to another – that is, in a init.d script, so that it will start automatically on the “slave”, if it is rebooted?

  9. Extraman says:

    How do you do those accumulated data graphs? I would like to do them also! Thanks for your ideas I’m running 2 stations in the same spot, giving me a way greater coverage.

  10. Stefan says:

    The old adsbhub seems to be closed. The domain is forwarded to planefinder. I found a new one – , looks promissing and gives free access to aggregated feed.

Error: Comment is Missing!