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.
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.
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.
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. You can set up WiFi using the Hotspot feature,
or you can set things up before inserting the SD card into your board. This process is described below.
If you are using a Raspbian based feeder image (that's the images
named
adsb-im-raspberrypi64-pi-2-3-4-5-v2.1.0.img.xz
), you can setup your
WiFi credentials with the Pi Imager as described on the
Howto page.
If you are using a DietPi based image
adsb-im--dietpi-...
, 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.
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.
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 alternativelygrep 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.