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's a bit painful. Yes, you can get this to work, ideally with the DietPi based image - which of course makes setting up WiFi a bit more challenging. Additionally, I'd suggest getting it work reliably just with some (or all) of the 'semi anonymous' aggregators (so the first dozen or so in the list that are all served by the same container on the feeder). And only adding FlightAware, FlightRadar, Radarbox, and the other aggregators below them one by one once you are happy that this still isn't overwhelming your little SBC. Generally SBCs with 1GB (or more) of memory create better results with this setup.
But really, the better solution here is a two stage setup.
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.
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.
WiFi is fully supported on Raspberry Pi boards, some other DietPi based images like the ones for OrangePi boards also work. If you are using a Raspbian based feeder image (that's the images named adsb-feeder-raspberrypi64...), you can setup your WiFi credentials with the Pi Imager as described on the Howto page.
If you are using the DietPi based image adsb-feeder-raspberrypi-dietpi-64... (which is highly recommended if you happen to have a Raspberry Pi Zero 2 W or a Pi 3 Model A+, both with only 512MB of RAM), things are unfortunatenly a little harder. Do NOT make any configuration settings in Pi Imager and instead write an unmodified image to the µSD.
Next mount the SD-card on your computer and edit two files (the exact location depends on your operating system - a drive letter on Windows, /Volumes/ADSB-FEEDER on macOS):
  • dietpi.txt set AUTO_SETUP_NET_WIFI_ENABLED=1 and AUTO_SETUP_NET_WIFI_COUNTRY_CODE= to your correct two letter country code (e.g. US for the USA or DE for Germany).
  • dietpi-wifi.txt set aWIFI_SSID[0]= to your SSID and aWIFI_KEY[0]= to the WPA key of your WiFi network.
Make sure both files are written back to the SD card, unmount it, plug it into your board and boot your SBC.
If should now automatically connect to your network.
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.
There's a bug in v0.17.1 that stayed undetected until v0.17.4 - as a result v0.17.1, v0.17.2, and v0.17.3 won't upgrade from the web UI. The workaround is fairly simple (and a one-time thing):
  • on the expert page set an ssh key for the root account.
  • ssh as root into the feeder using that key
  • run mkdir -p /opt/adsb-feeder-update && /opt/adsb/feeder-update stable
Once that completes, you are back to normal and future updates once again will work from the web UI.
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.