FlightAware Discussions

Combining multiple receivers into one map - Combine1090

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 https://github.com/wiedehopf/combine1090/blob/master/install.sh

2 Likes

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

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

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:

Screenshot 1 of 2

FEED FROM MY 2 RPi’s COMBINED

CLICK ON SCREENSHOT TO SEE LARGER SIZE

.

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

2 Likes

What’s the limit? Combining 10? 100?

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

dump1090-fa is very well performance optimized:

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.

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

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"

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

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.

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?

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)