Feeding other orgs from PiAware

FlightAware ADS-B Flight Tracking
1

As of the time of writing this I am running the PiAware 8.2 SD card image, which is working great. I’m running @akissack’s excellent OpenLayers html replacement front-end.

I’ve considered using this installation to feed other organisations but have been wary of breaking it, and I think FA has the best community and features so I’ve never explored it further. Recently I watched this video of Mick West from Metabunk locating a candidate aircraft for a supposed UFO sighting. To do this he uses FlightAware to obtain the KML files, and uses FR24 to identify the candidate aircraft. It’s a great video, worth a watch.

He mentions that he has that FR24 feature (and presumably the historical FA data) because he runs a feeder. This is actually a service I was asking about earlier this year. FA doesn’t provide this service, at least not for feeders. In another video he mentions Plane Finder and uses that to gather some info.

So I’m taking another look at feeding other sites, in particular FR24 for the above service. However checking this forum and googling around suggests that people are having mixed results with the success of this, partly down to FR24’s install script. It’s not clear, for example, if FR24 now tries to install dump1090 regardless of whether or not dump1090-fa or another variant is already present. That would be annoying.

I’d like to make sure I’m running stuff as natively as possible, so not relying on third-party (non-org) installers, and I also want to be absolutely sure I don’t inadvertently feed MLAT-calculated data, kindly returned to feeders by FA, to any other orgs.

I’ve seen this thread from many years ago and presumably things have changed a bit since then, so perhaps worth a revisit.

So all of the above is to ask for thoughts, feedback, on feeding other orgs in 2023/24, using PiAware as the default setup, in a way which safely ensures MLAT data is protected and not transferred, and using native or minimal changes to PiAware to add each org. I’m imagining the workflow is something akin to getting a working PiAware setup, then a simple script adds Org A, another script adds Org B with no cross-contamination, and so on. So each step cleanly follows the previous step.

And which orgs are considered valuable and worth supporting this way, which have services of value? I’ve not used ADS-B Exchange, nor Plane Finder, and there are probably a load I don’t even know that I don’t know about. It would be nice to use this feeder to support community projects that I may not even know exist or haven’t ever looked at.

There is also a fair amount of info scattered around but much of it is old, some is probably still relevant, some will may be obsolete. Is anyone else running a PiAware site and feeding additional orgs? Any issues or gotchas, or does it all just tick along and work great?

Thanks for your assistance.

2

Most of us are feeding more than one site only. But the majority is not using the Piaware image but an individual installation using Raspberry OS as underlying operating system with the different feeder scripts installed.

It’s no rocket science and gives you a bit more flexibility.
For the question if it’s possible using the original piaware image to install other feeder scripts somebody else will pretty sure reply shortly.

Different sites (without rating by me, just listing, not complete)
ADSB-Exchange
Opensky-Network (currently non-operational)
Planefinder
Radarbox
ADSB fi
ADSBHub
and maybe more…

1 Like
3

Good point, I started with the PiAware image in the beginning as it was simple. I’ve no problem ditching that now and moving to a Pi OS image and installing on that in order to support multiple orgs. As long as none of these scripts mess up the html front-end, which has to stay as it is and being fed data by FA’s software. In otherwords, FA’s software does the decoding and feeding the map as it does now, and the data that the software makes available (minus received MLAT results) is what is used to feed any additional orgs.

This seems to still be current.

2544×1608 239 KB

Thanks for the org list, I’ll google around for each of these to see what is offered, benefits, general vibe.

4

When installing the package versions I always find that the most important step is the installation order.
I always start with the FA package install following this page:

This will ensure dump-1090-fa is installed as a base system and other feeder software will be souricing from that source.

Then I move on to the FR24 installation from this page:

Disabling MLAT for FR24 is a step shown on that page so it’s easy.
It will state it can’t find any dump1090 but that’s a programming error and not the case.
If you tell the setup to ignore that it won’t install dump1090 mutability.

After that I install Graphs1090.

I don’t feed to the others so that’s the set I have to do.
I did feed ADSB-exchange in the past but have stopped that after the takeover and the falling-out into so many different small groups.

2 Likes
5

YES YES YES

(20 characters)

6

Check this post, simple image that allows you to feed multiple aggregators. It now has the option to point to a beast output, so you can install the image on a 2nd Pi and point it to your Piaware.

dirkhh

Oct 28

I’ve been working on this project for a while and by now I think it has matured to the point to really make it easier for beginners who want to feed ADS-B data to FlightAware and many other aggregators.
The ADS-B Feeder Image can be used on a Raspberry Pi (and quite a few other Single Board Computers) as a complete, self contained image. If you are already running DietPi on a system, it can be installed as an app using dietpi-software, and for people who have a different Linux system that’s reasonably recent, it can even be installed using a script so it runs as an app there.

I posted a short video showing how easy the initial setup is, a lot more details (including much more on the initial install process) can be found in the adsb.im howto and of course the adsb.im FAQ .

All of this is open source, free to use (and modify), and actively maintained.

1 Like
7

What also works is installing readsb instead of dump1090-fa
I prefer this over dump1090

8

What also work are decoders ModeSDeco2 or dump1090-mutability, though I personally like dump1090-fa.

2 Likes
9

Both are meanwhile outdated.

Doesn’t mean they aren’t working any longer, but i prefer more recent solutions

1 Like
10

And that indicates that this hobby can cater to everybody’s liking in the way they set up their systems.

2 Likes
11

ModeSDeco has been abandoned by it’s developer @sergsero since about last 2 years, and it does not works on Bookworm and Ubuntu22.

The dump1090-mutability (EB_VER) is being maintained by Debian, and can be installed on Debian & Raspberry Pi OS (Buster, Bullseye, & Bookworm), as well as on Ubuntu (18, 20, 22) by following command:

sudo apt install dump1090-mutability

In fact the Flightradar24 till today are using dump1090-mutability EB_VER as integral part of their SD Card image “Pi24”.

The Debian’s EB_VER is actually DEB_VER which, due to some bug in their code, appears on top-right of aircraft table with the D missing, as EB_VER. It is actually a snapshot of dump1090-mutability ver 1.15~dev.

12

I just installed FR24 on my Flight Aware receiver about two weeks ago (running 9.1). FR24 has a specific set of instructions for adding your feeder if you’re already running a feeder. This is what I used to set up mine.

The two work perfectly side-by-side on my Pi3B+. I’m planning on adding a third feeder site, but I’ll have to watch my CPU stats after that to see if I can add any more.

You should have no issues feeding multiple sites from a single receiver.

13

(1) FLIGHT RADAR 24 FEEDER

(1.1) FR24 Installation Script:

sudo bash -c "$(wget -O - http://repo.feed.flightradar24.com/install_fr24_rpi.sh)"

"Do NOT try the Claim page. It is messy. Easiest and sure way is to issue following command:

sudo fr24feed --signup

It will ask you your email, latitude longitude altitude. At the end it will offer "auto config **yes**/no" . Say yes to it and you are done with signup & configration.

(1.2) FR24 Config Web Page:

IP-OF-PI:8754

(1.3) FR24 Config File:

sudo nano /etc/fr24feed.ini  


receiver="avr-tcp"
host="127.0.0.1:30002"
fr24key="xxxxxxxxxxxxxxxx"

logmode="0"
logpath="/var/log/fr24feed"
bs=no
raw=no
mlat="yes"
mlat-without-gps="yes"

(2) RADAR BOX 24 FEEDER

(2.1) RB24 Installation Script:

sudo bash -c "$(wget -O - http://apt.rb24.com/inst_rbfeeder.sh)"

(2.2) RB24 Config File:

sudo nano /etc/rbfeeder.ini  


[client]
network_mode=true
log_file=/var/log/rbfeeder.log

key=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  

sn=EXTRPIxxxxxx

lat=xx.xxxx
lon=yy.yyyy
alt=zzz

[network]
mode=beast
external_port=30005
external_host=127.0.0.1

[mlat]
autostart_mlat=true
#mlat_cmd=/usr/bin/python3.9 /usr/bin/mlat-client

[dump978]
#dump978_enabled=true

(3) PLANEFINDER FEEDER

(3.1) Planefinder Installation Command:

wget http://client.planefinder.net/pfclient_5.0.161_armhf.deb

sudo dpkg -i pfclient_5.0.161_armhf.deb

(3.2) Planefinder Config Web Page:

IP-OF-PI:30053

(3.3) Planefinder Config File:

sudo nano /etc/pfclient-config.json

It is a very long line. Scroll right to see it in full. Your sharecode will be last item on right side of this line

{"tcp_address":"127.0.0.1","tcp_port":"30005","select_timeout":"10","data_upload_interval":"10","connection_type":"1","aircraft_timeout":"30","data_format":"1","latitude":"xx.xxxx","longitude":"yy.yyyy","sharecode":"zzzzzzzzzzzz"}

For convenience, in my installs I break it down in one item per line as given below (it works ok in this format as well).

{
"tcp_address":"127.0.0.1",
"tcp_port":"30005",
"select_timeout":"10",
"data_upload_interval":"10",
"connection_type":"1",
"aircraft_timeout":"30",
"data_format":"1",
"latitude":"xx.xxxx",
"longitude":"yy.yyyy",
"sharecode":"zzzzzzzzzzzzzz"
}

 

14

Thanks for the feedback and links. I did a test this evening. I already have a FR24 account (if I didn’t I would have created one as the first step). I next installed the FR24 feeder image on a spare SD card in order to acquire a sharing key (analagous to a FA feeder-id) and confirm the account upgrade to Business.

It was messy as it required an undocumented (mentioned in a stray forum post) apt update + upgrade, and then it was behaving. It also didn’t ask for my email address, so it wasn’t obvious how to link it to my account, but it turned out that claiming the feeder while logged in had taken care of that, although it took 30+ minutes to acknowledge it, making me go in circles for a while wondering what I was missing.

I didn’t realise it doesn’t install a local map and instead just activates account features which grants the main web site map access to those features (though this works in my favour in the full use case since I will already have the PiAware/OL6 local map). I wasn’t very impressed. Overall, the FA PiAware experience is streets ahead of it in every respect, a cleaner and more polished user experience, and way better stats and coverage feedback.

I played with the FR24 features such as the 3D view and historical playback. They are very good and useful. Some of their aviation mapping, integrated right there on the map, is useful, but PiAware could be made to do this by acquiring access to the relevant map tiles, if that is possible (the FA site itself has the same class of sectionals available).

Anyway with all the FR24 variables in place I re-imaged the SD card as a fresh PiAware instance running on my test feeder-id, upgraded the html front-end to the OpenLayers6 replacement (ref opening post) and installed graphs1090. It was a functional copy of my live site. I also imaged the card in that state as a fallback, as I’m sure I will break things during this experimentation.

I then installed the FR24feed script mentioned by @tomvdhorst, @fhmiii and @abcd567. That installed very smoothly, asked for my account email address and my sharing key. It asked if I wanted to share data for MLAT and I said no, since they request you choose no if sharing with other sites, right there on that page and elsewhere. It appears this is because in this use case the data quality is affected and causes problems with their number crunching. It also detected an existing dump1090, ie dump1090-fa, and asked if I wish to use it, to which I said yes. It automatically configured the receiver as avr-tcp.

The end result was very clean. A fr24feed service running, taking a feed from port 30002 and feeding that to my FR24 account, which showed the same aircraft on their web map, minus any MLAT aircraft, when filtered by feeder.

So far so good. This is exactly what I was looking for. The PiAware instance being dominant, no change to dump1090-fa, local mapping and MLAT reception being untouched, and a minimal amount of scripting installing and feeding FR24 with my own decoded data and making it happy enough to support a Business account, much as it might be used to feed a VRS instance.

Since this is working I will replicate it on the live site shortly. My fr24feed.ini file for reference, all automatically created by that install script:

receiver="avr-tcp"
fr24key="xxxxxxxxxxxxxxxx"
host="127.0.0.1:30002"
bs="no"
raw="no"
logmode="1"
logpath="/var/log/fr24feed"
mlat="no"
mlat-without-gps="no"

So there we go. FlightAware is the best overall experience by far and continues to be my baseline of choice. FR24 has some useful additional features and their Business account is now straightforward to get up and running.

I will look at the other sites and determine if they are offering additional useful services, or if I just want to support them as community projects which can use volunteer input. Happy to help there.

@kmm0000 thanks very much for the link to that utility. I will try that out too and see how it does.

@abcd567 thanks for those other site install summaries. I’ll tie those into the sites I look at and experiment on the test setup. Note that the mlat settings in the fr24feed should be “no” officially (in this PiAware add-on use case), although perhaps setting to “yes” doesn’t necessarily cause a problem.

15

Be aware that fr24feed will check for and install updates automatically without user intervention. If you are cool with that, fine. I was not, especially when it also tried to jam mutability on my system (failed due to required path not exisiting)

My compromise was to manually install their .deb package on a seperate computer and configure it to consume Beast over the network on port 30005. Then to the best of my ability I nuked everything I found to be unnecessary in their install - cron job, directory with a bunch of shell scripts, several lines in their systemd service, their repo from my apt sources. No harm done, the fr24feed service still works.

Wiedehopf has a script that does something similar. I did not use it, but pass it along as FYI.

1 Like
16

Thanks for that, could have been an annoying gotcha. It looks like the later version of the fr24feed utility is better behaved, since it asked if it should use the existing dump1090 (dump1090-fa) and then has done so (symlink in /usr/lib/fr24/dump1090 -> /usr/bin/dump1090-fa). Their dump1090 installer never got called.

However to be sure, I’ve found /etc/cron.d/fr24feed_updater and commented out the entry so it doesn’t run automatically. I can run it myself periodically.

17

It runs regardless when you flag the type as ‘dvbt’
When people just do the ol next next next or change it after installing, poof. You got 2 decoders.

Just last week they’ve decided to kill off anything less than 1.0.30. So if you disabled the updater.sh previously, or had the current image which still is a build less than 1.0.30 they broke a heap of the astute feeders with it off, or using the image. foot/pistol/shoot.

1 Like
18

Oh my mistake, I forgot to mention following:

"Do NOT try the Claim page. It is messy. Easiest and sure way is to issue following command:

sudo fr24feed --signup

It will ask you your email, latitude longitude altitude. At the end it will offer "auto config *yes* / no" . Say yes to it and you are done.

I will now edit my post and add this comment.

 

19

Kind of matches the SD card image experience, where it simply didn’t feed until a sudo apt update + upgrade was performed and a reboot, after which it started working. I got the impression the server side had been updated and no longer worked with that card image out of the box. Someone else having the same problem on their forum revealed the need to update it.

It wasn’t your mistake, I was describing the hassle in using their SD card image to claim and obtain the initial key/ID needed to integrate with PiAware later on. The PiAware integration was very smooth and didn’t need any flags or anything else. The hassle in using their image was entirely down to the image being out of date for their own servers.

1 Like
20

(1) FR24 can be blocked from updating automatically by deleting their updater script

sudo rm /usr/lib/fr24/fr24feed_updater.sh

Screenshot_20231220_105500_Termux
Screenshot_20231220_105500_Termux1050×293 93.6 KB

(2) FR24 can be blocked from attempting to install dump1090-mutability by (a) deleting dump1090 installer script (b) deleting a line in their service file as follows:

Step (a)

sudo rm /usr/lib/fr24/install_dump1090.sh

Step (b)

sudo nano /etc/systemd/system/fr24feed.service

In above file, delete following line

ExecStartPre=-/usr/lib/fr24/install_dump1090.sh

Save file

REBOOT Pi

 

Screenshot_20231220_105411_Termux
Screenshot_20231220_105411_Termux1080×743 123 KB