Combining multiple receivers into one map - Combine1090

FlightAware ADS-B Flight Tracking
1

This topic has come up a number of times and i have decided to throw a bit of scripting together that should make it a lot easier than before.

You install it on one of your Raspberry Pi receivers and it will serve a separate map where all the feeds you specify in the configuration file are combined.
The other receivers need to be accessible via network.

If you try it let me know if the instructions are sufficient.

And if you don’t like executing random install scripts, you can just use all the commands individually after hopefully understanding what they do combine1090/install.sh at master · wiedehopf/combine1090 · GitHub

9 Likes
2

Congratulations, you made it into a project! I remember you helping me get that functionality a while back.

3

Small one :wink:

It’s much simpler now than the scripts and stuff i went over with you.
Basically you just put IP addresses in the configuration file and access the map at
http://pi/combine1090
(with pi being the address of the Raspberry Pi you installed it on)

Also it starts its own copy of dump1090-fa so that MLAT is not affected.
Just for viewing not for feeding obviously.
(I mean you could modify it to feed from sectorized antennas i suppose but you would lose MLAT)

2 Likes
4

now i see 3 different feeds on my VRS (2 rpi + 1 modesmixer )
it will be nice if the map show different colors for the different streams
and a nice legend at the corner (for Windoze users). :grinning:

5

Screenshot 1 of 2

FEED FROM MY 2 RPi’s COMBINED

CLICK ON SCREENSHOT TO SEE LARGER SIZE

combine-success
combine-success1280×1024 628 KB

.

Screenshot 2 of 2

Feed from my 2 RPi’s in Canada combined with @wiedehopf feed from Deutshland (Germany) :slight_smile:

CLICK ON SCREENSHOT TO SEE LARGER SIZE

combine-success-2
combine-success-21280×1024 540 KB

4 Likes
6

What’s the limit? Combining 10? 100?

7

The bottleneck is most likely the map displaying everything. (But that seems to cope ok as well)

dump1090-fa is very well performance optimized:

Screenshot%20from%202019-01-30%2019-37-24
Screenshot%20from%202019-01-30%2019-37-241366×768 790 KB

In the screenshot i’ve combined my own receiver 96 times into the map you see.
dump1090-fa is using about 30 percent of one core to do all the stuff it does.

Now network traffic wise, 15 kByte/s is what my beast feed approximately uses.
So normally not an issue either.

8

Interesting about the dump1090-fa being so good. It’s freaking to see over 100k messages per sec there…

9

Well actually it’s optimized a little too well when using default settings. If the message rate is low it can take up to a second for dump1090-fa to send the message via the network to piaware or the other feeders.
Normally that’s not a problem: when you have 100 messages/s or more, it will be delayed much shorter.

But reducing that 1 second network flush interval in the default options to something like 0.1 or 0.2 seconds seems like a good idea nonetheless. (@obj or do i have that ro-interval wrong?)

Also the default configuration is kinda confusing because of the duplicate beast out port:

RECEIVER_OPTIONS="--device-index 0 --gain -10 --ppm 0 --net-bo-port 30005"
DECODER_OPTIONS="--max-range 360"
NET_OPTIONS="--net --net-heartbeat 60 --net-ro-size 1000 --net-ro-interval 1 --net-ri-port 0 --net-ro-port 30002 --net-sbs-port 30003 --net-bi-port 30004,30104 --net-bo-port 30005"
JSON_OPTIONS="--json-location-accuracy 1"

This seems like a better default.

RECEIVER_OPTIONS="--device-index 0 --gain -10 --ppm 0 --net-bo-port 30005"
DECODER_OPTIONS="--max-range 360"
NET_OPTIONS="--net --net-heartbeat 60 --net-ro-size 1000 --net-ro-interval 0.2 --net-ri-port 0 --net-ro-port 30002 --net-sbs-port 30003 --net-bi-port 30004,30104"
JSON_OPTIONS="--json-location-accuracy 1"
10

They did that to save bandwidth, by accumulating signals. Sending empty ethernet frames is not so nice to bandwidth.

11

That frame is normally only sent locally from dump1090-fa to piaware and other feeders listening.
So in the typical application it doesn’t matter if there are an extra 5 packets per second.
Only very few people are using beast protocol via the internet. And even then you could still change it if it’s that important.

12

I don’t know then. If the dongle is remote, that Pi it can send the received data to the remote Pi with a cell connection and never get the MLAT back, thus saving bandwidth?

13

That is one application where you would want to set it back up to one second so it doesn’t use packet overhead when there is literally no air traffic around.
(But even there the impact is very small)

14

Would it be possible to have this combine script referencing to the alternative tar1090 instead having this as the default map?

Or is it possible to combine two stations in tar1090 directly?

15

Look at the tar1090 github page, you can make additional instances taking data from different directories like /run/combine1090

16

Thanks will give it a try

EDIT: Checked the TAR page, is this also a possible solution for combining data from two different network attached devices? Not sure about the directory thing…

17

This is actually changed as you suggested in 3.8 (and the duplicated port thing got fixed too)

18

tar1090 is not for combining data.

combine1090 to combine the data.
Then do a tar1090 interface that use the /run/combine1090 data.

19

ah, now i got it

Thanks

20

After setting up my second device (Raspberry 4B with Buster) now successfully, i was also able to get both combined.
Good work, @wiedehopf on your scripts.

image
image1120×466 331 KB