Couple several piaware installations, how?

FlightAware ADS-B Flight Tracking
1

I use piaware to feed its json-data into a database to be able to run some calculations.

Friends of mine, some ten kilometers away, will get their own piaware installations and their own FlightAware account.

How can I use their installations to “enrich” my data? Since it’s mainly about military flights it’s only Mode-S and needs the mlat calculation. It’s important that I do not only see their data on the map but in the json data, too.

Is it that simple:
their-piaware port 30005 → my-piaware port 30004

Or do they have to start a 2nd fa-mlat-client that feeds my port 30104?

2

No.

If you only care about MLAT results you can make their piaware connect to your dump1090 as well.

This graphic is not perfect but maybe it helps you:
(https://flightaware.com/adsb/piaware/about)

30104 of your dump1090-fa is just a universal input port.

You can check this post how to use socat:
(High rise antenna? - #46 by wiedehopf)
(In that example the input port was changed to 29999, the data is being forwarded from the computer pi to localhost)

You can connect to the port 30005 to get non-MLAT results from dump1090 and 30105 to get MLAT results from piaware.

I suppose instead of using socat you could also configure piaware to feed MLAT data somewhere else:

sudo piaware-config mlat-results-format           "beast,connect,localhost:30104 beast,listen,30105"

That is the default you can add

beast,connect,othercomputer:30104

to forward the MLAT results.

othercomputer could be your dyndns address.
Then you only need to forward 30104 from your router to your pi where you want the mlat results.

I guess that still counts as personal use? (Check FA policy on mlat results please)

Good luck.

3

Thanks. So my friend’s pi’s Port 30105 should connect to my pi’s 30104.

I wanted to be sure not to produce any logical loops or disturb MLAT calculations.

4

dump1090-fa will not forward the MLAT positions to your piaware or other feeder no matter which piaware the mlat results come from.

if you were to forward non MLAT data your MLAT would cease to work because dump1090 passes it on and the clocks / positions don’t fit and MLAT stops working.

If you want to forward non-MLAT data as well you will need to run another dump1090-fa instance in net-only mode that does not feed piaware and is just for local purposes.

Also dump1090-fa does not establish connections as it acts as server so you need something like socat to connect the two ports.

5

So I am thinking about a net-only dump1090-fa instance as a “display server” that gets fed from my and my friend’s piaware.

An x86 version would be fine, so I could run it on my Debian. Maybe I have to build it from source.

6

That will work.

Or you can run a second dump1090-fa on the same pi that’s no problem.

Just set all the ports in the config file to 0 except 30104 to 29999 for example.
Then you feed all the data there.
Also use --net-only in the parameters.

Then you will need a second config file of course and copy the service file

/lib/systemd/system/dump1090-fa.service

to

/lib/systemd/system/dumpnet.service

for example.

My second service file looks like this:

# dump1090-fa service for systemd                                                                                                      

[Unit]
Description=dump1090 --net-only
Documentation=https://flightaware.com/adsb/piaware/
Wants=network.target
After=network.target

[Service]
EnvironmentFile=/etc/default/dumpnet
EnvironmentFile=-/var/cache/piaware/location.env
User=dump1090
RuntimeDirectory=dumpnet
RuntimeDirectoryMode=0755
ExecStart=/usr/bin/dump1090-fa \
 $RECEIVER_OPTIONS $DECODER_OPTIONS $NET_OPTIONS $JSON_OPTIONS $PIAWARE_DUMP1090_LOCATION_OPTIONS \
 --write-json /run/dumpnet --quiet
Type=simple
Restart=on-failure
RestartSec=30
Nice=-5

[Install]
WantedBy=default.target

I think i changed the runtime directory and the Environment file.

If you want the service to start automatically you need to run:

sudo systemctl enable dumpnet

That’s how my config file looks

RECEIVER_OPTIONS=""
DECODER_OPTIONS="--stats-range --stats-every 86400 --fix --lat 50 --lon 10 --max-range 220"
NET_OPTIONS="--net --net-only --net-ro-size 256 --net-ro-interval 0.05 --net-heartbeat 60 --net-ri-port 0 --net-ro-port 0 --net-sbs-port 0 --net-bi-port 29999 --net-bo-port 0"

Good luck with the network stuff i hope you have some experience :stuck_out_tongue_winking_eye:

7

Thanks a lot. At the moment I try to build piaware on a x86 VM (Debian 9).

EDIT:
Works like a charm.
Now I think I will only start dump1090-fa and configure as you suggested.
Networking is not a problem for me since I am experienced with virtual networks, OpenVPN-tunnel in OpenVPN-tunnel and several routing tables per machine.

8

Hm… I don’t need piaware-builder, I need dump1090-fa and I am now lost to find the correct dump1090. There are zillions …

9
10

Ha! Works. Now I am gonna feed it from my Raspi. Thanks.

11

On your Debian 9 x86 on VM, did you install dump1090-fa with or without bladeRF?

Couple of months ago, I tried to install it on VM with Debian 9.5 amd64, and could not build it due to bladeRF package for my architecture/distro not available at that time.

Finally Oliver Jowett @obj guided me that if I am not using bladeRF hardware, I can built it by setting flag BLADERF=no

Please see this post for details:

12

Debian9 has the needed packages:
||/ Name Version Architektur Beschreibung
++±==============================-====================-====================-==================================================================
ii libbladerf-dev:amd64 0.2016.06-1+b2 amd64 nuand bladeRF software-defined radio device (header files)
ii libbladerf1:amd64 0.2016.06-1+b2 amd64 nuand bladeRF software-defined radio device

13

Good to know that bladeRF problem is over now. It existed couple of months ago when I tried to install dump1090-fa on Debian 9.5 amd64.