Apart from the one you mentioned (breaking your working setup), which is possible but unlikely and the additional overhead of feeding to another aggregator, which is pretty minimal really and probably not an issue unless you are connecting to the internet on a metered connection such as a mobile, there’s really no downside to it.
But why stop with ADSB-X? There’s plenty of other sites who I’m pretty sure would love to have your data.
RadarBox, Planefinder, FlightRadar24 are other candidates that spring to mind and they all have configuration or installation information on their websites.
The only one that can cause an issue is FR24, but if you follow @ABCD567’s instructions on here or on their forum you’ll be fine.
If you are concerned about recovering after some sort of error, it might be a good idea to make an image of your card on a PC before making any changes. That way you can flash it back if disaster befalls you.
Due to using the same package name mlat-client and rbfeeder installing the same package which did weird stuff … we’ve moved to using python virtualenv, so it’s decoupled from the rest of system in regards to the mlat-client package.
After installing rbfeeder on buster, I could install mlat-client by command sudo apt install mlat-client which is actually provided by RadarBox24 repository.
I then ran bash script to install adsbx-feed & adsbx-mlat, and it waited for long time, installing lot of packages in background. I understand it installed mlat-client again over the mlat-client installed earlier from RB24 repositories, but not sure as all was done in background with commands running with argument --quiet
For RB24 feeder, it is python3.5 (stretch) or 3.7 (buster).
This is default from /etc/rbfeeder.ini:
Above works on stretch, but fails on buster. This works on buster
mlat_cmd=/usr/bin/python3.7 /usr/bin/mlat-client --results beast,listen,30007
Note: “–results beast,listen,30007” is for diverting RB24 mlat feed-back to port 30007 to keep it segregated from FA mlat feedback in SkyView map, and display it in VRS.
You also have the option of running alternative feeders on a completely separate RasPi, which is what I do. I’ve been feeding for a while and have collected various versions of the Raspberry Pi. But I like to keep my Piaware SD card install clean. So I run Piaware on a RasPi 3B+ that’s connected to my dongle and I run other feeders on a RasPi 2B V1.1 that I just had in a drawer. That version may be 5 years old but just running feeders doesn’t even make it break a sweat. I run PlaneFinder, modeSmixer2, ADSBX, and OpenSky all on that second Raspberry Pi and just point them at the proper ports on the RasPi running Piaware. If all you want is to feed the other sites the easiest thing to do is just set the data source of each feeder to the IP of your Piaware RasPi, set the input type to Beast, and connect to port 30005. That’s the port that dump1090-fa provides Beast formatted data on. It’s a very small amount of data to send over a network, especially if everything is wired with Ethernet. So that’s another option. If you were interested I could go into the configuration of each feeder, since they are all setup somewhat differently.
If you are going to do this - feed multiple sites from the same system - do yourself a BIG favour: Make a temporary image of the SD card after each successful feed addition. After all the feeds are up and running, make another image of the SD card, and this one becomes permanent.
If your card goes bad, recovering will be a ‘walk in the park’, and you are going to remember me with affection.
No it doesn’t overwrite any mlat-client if you use the current install script.
There used to be some issue with rbfeeder using the same package name … and the package from them being modified heavily while using the generic name …
Well it’s always automatically just pushed MLAT results into 30004 on localhost.
If you want a listen port, it used to and still is available as basesation on 31003.
Not sure for how long.
Maybe just install the current feed script?