FlightAware Discussions

Any benefit to running two Piawares from the same loc?

So I got my new Pi and set it up on Plane Finder to check it out. It was a fun exercise, since they don’t make it as easy as Piaware. I also got some practice installing dump1090-mutability. But I don’t think I’ll stick with Plane Finder. I may try out FlightRadar24 for the heck of it.

Anyway, if I install Piaware on the new Pi and run it as a second feed, would there be any benefit? I could locate the antenna in another part of the property that might get a different perspective of the sky. Just thinking right now.

Happy New Year!

Could you do that, because having 2 RPi on the same LAN and using 1 ISP address?

You can either run two feeders (which would show up as two sites I believe), or you can combine the output from two dump1090s and send it to one feeder.

I do the second option (combining the output) for the two antennas I run, which are on opposite sides of the building to get a combined 360-degree view.

Combining the output basically consists of using netcat to feed from port 30005 on one dump1090 to port 30004 on the other:



#!/bin/sh

while :
do
  nc -d localhost 30005 | nc -q1 rpi.lxi 30004
  sleep 15
done


1 Like

Thank you. I’ll give that a try. I don’t suppose so, but will there be any issues if I’m running Piaware on one Pi and Piaware-mutability on the other?

In that config you would only be running one piaware. Two dump1090s with a link between them, one piaware talking to the receiving-side dump1090:

cue terrible ascii art:



.\|/                                                                \|/
. |                                                                  |
. |           +---PI #1----|             |---PI #2----------------+  |
. +--[rtlsdr]--[dump1090]----->netcat----->[dump1090]---[piaware] |  |
.             +------------|             |---- | -----------------+  |
.                                              |                     |
.                                            [rtlsdr]----------------+


But I can’t see piaware / piaware-mutability interfering at all if they’re on separate Pis, fwiw.

1 Like

I know nothing about netcat. I guess I’ll have to learn. :laughing: First order of business will be to get Piaware-mutability set up.

It’s like “cat” but works over a network connection, basically :slight_smile:



$ nc -d localhost 30005 | nc -q1 rpi.lxi 30004


First half of the pipeline (“nc -d …”) connects to localhost:30005 and reads from it, writing the results to the second half of the pipeline.
Second half of the pipeline (“nc -q1 …”) connects to rpi.lxi:30004, reads from the first half of the pipeline, and writes whatever it gets to the connection.

So what you end up with is data being read from localhost:30005, then written to rpi.lxi:30004

FWIW, I run the regular Pi #1 feed w/ groundplane on the roof. It also feeds planeplotter. #2 set up for testing acrarsdeco2 & dump1090-mutability is in the same room w/ 6 seg co-co inside. Both feed FA separately, albeit #2 sees less traffic ‘for some reason’. :slight_smile: I did notice that #2 even ran with the acars groundplane antenna (inside) when I forgot to switch - even less traffic. Quelle un surprise :wink: Pi #2 has been known to ‘wander’ on the map. Has stayed in place last few days, so maybe FA unwrinkled that feature.

Thank you. I understand now, having looked again (with fresh eyes) at your ASCII art and your explanation of the ‘nc’ syntax. Do I run that script from cron? If so, how often?

Oh, and how does ‘nc -q1 rpi.lxi 30004’ know where to send the data? Don’t I have to put the host name or IP address of pi #2 (from your drawing) somewhere?

Sorry to bother you with all these questions. I know you have more important stuff to do. :blush:

I start the script (backgrounded) from /etc/rc.local. If the connection is lost or fails then the netcat pipeline will exit, then the enclosing while loop tries to reconnect after 15 secs.

Oh, and how does ‘nc -q1 rpi.lxi 30004’ know where to send the data? Don’t I have to put the host name or IP address of pi #2 (from your drawing) somewhere?

“rpi.lxi” is the hostname of the target Pi, put your own hostname or IP address there.

Perfect. Thanks!

Just curious, does this have any negative impact on either the Pi or the FA servers? Something like getting the same signal twice and muxing it into one or higher CPU usage?

Haha, that’s one of those “it depends!” questions.

Multiplexing the data feeds together does add some double-handling because messages will get decoded twice. But the majority of the work that dump1090 does is the demodulation from the RF signal, and that’s only run once per antenna regardless. The decoding/tracking cost is a fairly small cost overall.

FlightAware will actually end up doing less work than having two independent piaware feeds, as piaware (well, faup1090 or the FATSV logic in dump1090, actually) aggregates signals together to produce the latest state for each tracked aircraft, then periodically sends that aircraft state to FlightAware. So feeding two dump1090s into one piaware will reduce traffic, because an aircraft visible to both antennas will only be tracked once.

In my case I run a slightly different setup with one dump1090 in --net-only dedicated to doing nothing but multiplexing, precisely so that I can keep an eye on the relative usage. The results look something like this right now:

dump1090 receiver #1: 26% CPU (approx 300 messages/sec)
dump1090 receiver #2: 32% (approx 1000 messages/sec)
dump1090 multiplexer: 2.5% (here’s your double-handling cost)
netstat tunnels: approx 1.2% total
piaware: 2.6%
fr24feed: 2.9%

(+ system overhead that’s slightly trickier to measure)

@obj: I’ve got dump1090-mutability installed on my pi3 (192.168.1.3). It’s sending data to pi2 (192.168.1.2).

Tcpdump output on pi2:


01:58:59.054582 IP **192.168.1.3**.52706 > **192.168.1.2**.30004: Flags [P.], seq 23483:23563, ack 1, win 457, options [nop,nop,TS val 225405 ecr 228564], length 80


Can I assume pi2 is using the data? Is there anything else I need to do on pi2?

Only pi2 is running Piaware. It’s running dump1090. Pi3 is running dump1090-mutability and lighthttpd.

By the way, great work on the packaging and instructions. Everything installed flawlessly.

Pi2


top - 02:08:17 up 51 min,  1 user,  load average: 0.34, 0.47, 0.49


Pi3


top - 02:08:59 up 53 min,  1 user,  load average: 0.55, 0.60, 0.62


I have a question if I would set up a second new Pi with antenna and all, on the same network. Could i run 2 Pi’s? I know it would show up as 2 sites for me, but both would have different MAC address, and both would be on the same ISP address. Would that be ok?

I want to setup a 2nd RPi to i try different dump1090’s and antennas with out messing my main Pi up.

Thanks.

sjacket99,

I have a question if I would set up a second new Pi with antenna and all, on the same network. Could i run 2 Pi’s? I know it would show up as 2 sites for me, but both would have different MAC address, and both would be on the same ISP address. Would that be ok?

I want to setup a 2nd RPi to i try different dump1090’s and antennas with out messing my main Pi up.

Yes, you can run two pis on the same network, each running Piaware. They will operate fully independently, so they will show up as 2 different sites and you will need to claim both.

I use it for the reasons you described - my 2nd pi is an experimental setup that doesn’t disrupt the “production” Piaware feed. Because the minute-by-minute variation in ADSB signals is so great, tuning your setup via A/B testing really requires a parallel setup. Otherwise you will make a tweak and stare at several days of FA stats to determine if there is an improvement or not.

And, should you be adjusting anything other than your antennas, buy an antenna splitter so that both systems can share the same input. For example, my experimental site using bargain basement SDR sticks is currently outperforming my production site using more costly receivers. Go figure!

obj, I do something similar - the multiplexer instance makes it easier to instrument and adjust things! But I’d like to get your thoughts on something…

You feed data from port 30005->30004 (Beast). There is an alternative - port 30002 -> 30001 (Raw). Is there a reason you chose Beast?

I use raw but am not sure my rationale is correct. It’s partly because I don’t understand Beast format and raw is easily viewable ASCII. Also, I believe that raw can enable a complete message decode where a dump1090 receiver misses one message in a sequence (say, lat+lon) that is captured by the other dump1090 receiver.

…but I have no idea about what the Beast format communicates…

I run two Pis as well, one as a PiAware production system and the other for development. As posted in another thread, besides doing comparisons between the two systems, I also use another PiAware system in the area as a control or reference. I picked a station near me with stable and similar daily stats. I use this station as a reference, so I can tell not only differences in performance between my two systems, but also when I do something that changes both. I’m currently running an experiment testing two different SDR modules, running them off the same RF chain. I’m seeing a difference in performance between the two SDR modules, and also confirming through the stats of that reference system that the slightly changed configuration hasn’t negatively affected the overall performance of my PiAware production system.

Oh, netcat on Linux is often called a “swiss army knife.” Some call it a chainsaw – it’s very powerful, and can take a (digital) leg off in nothing flat. nc is a very powerful tool and confirms the rule that a computer does exactly what you tell it to do – no matter how stupid that is. Read up on netcat; one of my favorite tools.

cheers–

bob k6rtm

They are fundamentally the same (they both deal with demodulated, but undecoded, Mode S messages). I picked the beast format because it’s a little more compact, and because it includes a signal strength field, which the AVR/raw formats (at least as generated by dump1090) don’t include.

Ok… Thanks. Ill have to give that a try…