ADSB.im logo

ADSB.im

Simple to use ADSB Feeder Images
(not just) for common Single Board Computers

FAQ

It's simple, no data of yours is stored for more than 60 seconds. The full details are of course in our Privacy Policy
Many Arm based Single Board Computers (SBCs) and USB Software Define Radios (SDRs). A (hopefully) current list can be found on our Supported Hardware page. Updates are always welcome.
NOTE: you need a decent power supply. The vast majority of user issues can be traced back to using a bad power supply.
That used to be a bit painful but has gotten a lot better lately. With current versions of the feeder image, 512MB is no longer a huge problem. I still recommend 1GB or more, but you can absolutely run a feeder with 512MB and feed several aggregators.
The bigger issue with both the Pi 3 and and the Pi Zero 2 is that the hardware seems to be somewhat less reliable than the Pi 4 - we get more reports of random crashes or other strange issues. But if this is what you have, use a current image (I no longer prefer the DietPi images - the regular (Raspbian based) image works just as well) and give it a go.
If you plan to feed many of the account based aggregators, it might still be worth looking at a two stage setup where the Raspberry Pi just drives the SDR and the actuall communication with the aggregators is done from a Stage 2 system.
There are many ways to interpret this question. I'll assume you want to know what's a good setup to run. And surprisingly, that's a complicated questions. It depends on a lot of factors.
Do you just want to run a simple feeder that feeds some / many / most / all of the aggregators?
The best bet right now might be a Raspberry Pi 4 with 1G or 2G of memory. Those are once again reasonably easy to get, not too expensive, and more than capable enough to run all this.
I have a smaller / cheaper SBC - will that also work?
The Raspberry Pi 3 is known to have a bunch of problems that cause occasional MLAT hiccups. Similarly, the Pi Zero 2 does work, but it's not great. The Libre Computing Le Potato and the Orange Pi Zero 3 seem to be good slightly cheaper choices. For all of the boards that are have less than 1G of RAM or significantly slower CPUs than the Raspberry Pi 4, a two stage setup might be the best option. A (hopefully) current list of supported hardware can be found on our Supported Hardware page.
What about x86?
64bit Thin Clients (often available for very little money on eBay) are a great choice. Anything more powerful will work as well, but might be a bit of a waste (just like running this on a Raspberry Pi 5 or an Orange Pi 5 is definitely overkill). Stage 2 instances work great in x86_64 VMs (that's kind of the sweet spot for them, really), but running the feeder itself (i.e. the system with the SDR attached) in a VM creates problems with MLAT because of USB passthrough challenges.
The first thing to check is your power supply.
No, this will not work reliably with just a USB charger. Or a USB cable from a powered hub. Or whatever. Yes, that other guy on Discord said... The reality is that the vast majority of issues when running this image on a single board computer can be traced back to bad power. So before you ask for help, please ask yourself "am I using a decent power supply?". At least a 5V/2.5A power supply for an RPi3-class SBC, 5V/4A or better for anything more powerful than that.
Ideally this should work out of the box. But in practice something often goes wrong. Make sure you followed the instructions. Especially focus on the part about having a good power supply and a good SD-card. A lot of problems are caused by those.
If this doesn't work, I really recommend simply starting again. Download the image, use the Pi Imager or a similar bit-accurate program to write the image to the SD-card. Make sure you don't skip the verify step. Then turn off the SBC, insert the SD-card and turn it back on again. Be patient - wait at least several minutes, longer, if it is an "install-on-boot" image, marked as "iob" in the image name. Now check again at adsb-feeder.local. If this doesn't work, try connecting to it via our redirector service at my.adsb.im.
If none of this solves the problem, ask on the SDR-Enthusiast Discord in the #adsb-dot-im channel.
A common question in the context of Troubleshooting is "How do I log in to the feeder?".
There is no default user/password. Instead on the System->Management page you can ask the feeder to create a random root password for you. Use that to log in as root, or set an ssh key on the same page and then use an ssh client to log into the root account.
We provide an OVA for each release, also simply a compressed virtual disk image, as well as a version prepared for (relatively) easy installation with ProxMox. Please note that when opening the OVA in VMware (Fusion/Workstation/whatever) you will get an error on the first attempt, but will be able to succesfully import it if you click 'Retry'. Make sure you pass your SDR through to the VM - this works differently in each hypervisor, so please look at your specific hypervisor software for instructions. Look for an option to make host USB devices available to the VM. There are some noticeable issues with mlat when running the Feeder Image in a VM. This is a known issue with USB passthrough into VMs. Some hints from Matthias Wirt on the topic are in this ADS-B Wiki page.
If you are running on ProxMox, please follow the instructions in the ProxMox section of the README.
WiFi is fully supported on Raspberry Pi boards, some other DietPi based images like the ones for OrangePi boards also work. We strongly recommend setting up WiFi using the Hotspot feature.
The ADS-B Feeder is designed to be run in a local network, behind a firewall. There are many parts of this image that would be completely unsafe to have on the internet (like for example being able to install an ssh key), but even with those enabled, having this system directly exposed to potentially hostile traffic was never a design goal. Please don't do it.
You can transfer the Sharing/API/Feeder Key/ID to ADSB.im during the setup. Just note them down prior to switching your current feeder off. Currently suported (with hints how to get existing keys - these commands need to be run on your existing feeder):
  • FlightAware: piaware-config -show feeder-id
  • FlightRadar24: cat /etc/fr24feed.ini | grep fr24key
  • RadarBox: rbfeeder --showkey --no-start or alternatively grep key= /etc/rbfeeder.ini
  • Plane.Watch: log into your Plane.Watch account, go to "Feeders", and click on the little search icon next to the feeder name. The resulting page will list your API key.
  • PlaneFinder: log into your PlaneFinder account and go to "Your Receivers". Your share code will be listed next to your existing receiver.
  • ADSBHub: log into your ADSBHub account and go to "Settings", click on the name of the station and then copy the "Station dynamic IP update ckey".
  • OpenSky Network: log into your OpenSky Network account. The serial number for your receiver will be shown.
  • RadarVirtuel: your feeder key was emailed to you when you signed up.
  • 1090MHz UK: your sharing key was emailed to you when you signed up.
First, if you haven't already done so, set up a Zerotier account and create a network. Lots of documentation how to do this can be found on their documentation website
When you create the network, it will be assigned a 16 character hex string. Enter that string on the expert page of the adsb.im ADS-B Feeder. After a few moments you should see the new network member show up on the Network Settings panel on the Zerotier website. There you accept the feeder into your network and give it a name. Also note down the IP address that it is assigned in the managed IP column.
Now set up Zerotier on the device from which you want to be able to access you feeder. Go through that same process of adding it to your network.
Once that is done, you can access your feeder from that other device (cell phone, laptop, whatever) by using the IP address you noted down earlier.
This is actually a surprisingly complex question. The ADS-B Feeder Image provided here (or installed as an 'app' in DietPi or on a different Linux OS) is Docker based. And it runs a Python/Flask app to provide the web user interface. This by definition creates overhead. It will use more memory than an optimized minimal installation of the necessary software directly on the SBC OS. Given that I have tried to be careful in how I set things up, the difference isn't very big, but it's there, and especially on a low memory device (e.g., a 512MB RPi Zero 2 W or RPi 3 A+) that difference can be significant. On the flip side, the moment you consider submitting your data to more than one aggregator, the equation changes. This is where having a setup like this one really helps to keep things simple. The other situation where the ADS-B Feeder Image has a significant edge over installation directly on an SBC is for anyone who isn't super comfortable with the command line, who doesn't want to spend a lot of time in a text editor or entering commands in a terminal window, and who is looking for an easy to use user interface. The ADS-B Feeder Image is primarily designed to be easy, to appeal to people who aren't super comfortable running a Linux system. Interestingly enough, quite a few very experienced folks still decide to use this image simply because of the UI and the simplicity - but I understand if you feel differently and don't need the helping hand. In summary: yes, there is additional overhead, but in most situations it's academic and doesn't really make an difference. If you have an SBC with a gigabyte or more, it's likely not relevant. But if you aren't a fan of the Linux command line, this may still be a very powerful option to consider.