Deploy "ultrafeeder"
The "ultrafeeder" container is the heart of our "adsb" application. It receives 1090MHz ADS-B ES signals from your SDR, and demodulates ADS-B messages, making them available for all other containers.
It also provides a website with a map based on tar1090, station statistics (graphs1090), mlat-client, and an mlat-hub to aggregate MLAT results.
In your favorite text editor, create a file named docker-compose.yml in your application directory (/opt/adsb) if you've been following along verbatim.
In the file above, you will find several parameters that have values denoted as ${xxxx}. These values are read from a file in the same directory named .env that we created earlier. Alternatively, you can simply replace ${xxxx} with the value you want to use, for example READSB_RTLSDR_DEVICE=${ADSB_SDR_SERIAL} --> READSB_RTLSDR_DEVICE=0000001090.
The docker-compose.yml file above will:
Create a few mapped docker volumes to store historic message values and autogain values (
/var/globe_history), statistics for the graphs (/var/lib/collectd), and make the disk statistics (/proc/diskstats) and USB devices (`/dev') available to the container.Create a service named
ultrafeederthat will run theghcr.io/sdr-enthusiasts/docker-adsb-ultrafeedercontainer.We're mapping TCP port
8080through to the container so we can access the web interface.The variable
READSB_RTLSDR_DEVICEtellsreadsbto look for an RTL-SDR device with the serial of1090(that we re-serialized in an earlier step).We're passing several environment variables through, including our timezone, latitude and longitude from the
.envfile (denoted by${VARIABLE}).
We're using
tmpfsfor volumes that have regular I/O. Any files stored in atmpfsmount are temporarily stored outside the container's writable layer. This helps to reduce:The size of the container, by not writing changes to the underlying container; and
SD Card or SSD wear
You can find an expanded example of the docker-compose.yml file that you can download and edit here if you want to see other options, but the sample above is a good start.
Feeding directly from Ultrafeeder
There are several aggregators, both non-profit and commercial, that can directly be sent data from ultrafeeder without the need for an additional feeder container. We have added them in the example docker-compose.yml file above. Here is a partial list of these aggregators. All of them use the beast_reduce_plus format for feeding ADS-B data, and mlat-client for feeding MLAT:
Name | (C)ommercial/ (N)on-profit | Description | Feed details |
ADSB.fi | N | Run by volunteers that used to be related to adsbexchange | adsb: |
airplanes.live | N | Run by volunteers that used to be related to adsbexchange | adsb: |
ADSB.lol | N | Run by a private individual located in the Netherlands | adsb: |
Planespotters | N | planespotters.net | adsb: |
The Air Traffic | N | Run by a private individual | adsb: |
HPRadar | N | Run by a private individual in Vietnam | adsb: |
RadarPlane | N | Run by a few volunteers in Canada and Portugal | adsb: |
Fly Italy ADSB | N | Run by a few ADSB enthusiasts from Italy | adsb: |
AV Delphi | C | Swiss aircraft data company | adsb: |
ADSB Exchange | C | Large aggregator owned by JetNet | adsb: |
Het Luchtruim | N | Run by a private individual in the Netherlands. Please only feed if you are in the Netherlands or close to its borders | adsb: |
Using the MLAT results
A working MLAT configuration is already provided in the example above. See https://github.com/sdr-enthusiasts/docker-adsb-ultrafeeder/blob/main/README.md#configuring-the-built-in-mlat-hub for more details on how to configure more advanced features.
Deploying ultrafeeder
ultrafeederOnce the docker-compose.yml file is created, issue the command docker compose up -d to bring up the environment.
You should see the following output:
We can view the logs for the environment with the command docker compose logs, or continually "tail" them with docker compose logs -f. At this stage, the logs will be fairly extensive and unexciting and look like this:
We can see our container running with the command docker ps:
We can see the adsb_default network with the command docker network ls:
Ultrafeeder Web Pages
If configured and started using the example above, the container will make a website available at port 8080 of your host machine. Here are a few web pages that are generated (replace my_host_ip with the name or IP address of your host machine):
http://my_host_ip:8080/:tar1090map and table of all aircraft receivedhttp://my_host_ip:8080/graphs1090/: page with graphs and operations statistics of your stationhttp://my_host_ip:8080?pTracks: showing all aircraft tracks received in the last 24 hourshttp://my_host_ip:8080?heatmap&realheat: showing a heatmap of all aircrafts of the last 24 hourshttp://my_host_ip:8080?replay: showing a timelapse replay of the past few days
Viewing Live Data in Text Format
To see the data being received and decoded by our new container, run the command docker exec -it ultrafeeder viewadsb. This should display a real-time departure-lounge-style screen showing all the aircraft being tracked, for example:
Press CTRL-C to escape this screen.
You should also be able to point your web browser to http://docker.host.ip.addr:8080/ to view the web interface (change docker.host.ip.addr to the IP address or hostname of your docker host). You should see a map showing your currently tracked aircraft, and a link to the "Performance Graphs".
UUID security
The example files above use the same UUID for all feeders. Doing so makes it possible that your information from one site could be tracked on another. An alternative approach is to generate a unique UUID for each website, load those into a variable in .env, and append the UUID to the row in the ULTRAFEEDER_CONFIG section. For example:
Preparing and setting up ultrafeeder with Prometheus and Grafana
ultrafeeder with Prometheus and GrafanaSee readme-grafana.MD at the container's Github repository web page.
Minimalist setup
If you want to use ultrafeeder only as a SDR decoder but without any mapping or stats/graph websites, without MLAT connections or MLAT-hub, etc., for example to minimize CPU and RAM needs on a low CPU/memory single board computer, then do the following:
in the
ULTRAFEEDER_CONFIGparameter, remove any entry that starts withmlatormlathub. This will prevent anymlat-clients ormlathubinstances to be launched. If you want to connect themlat-client(s) to external MLAT servers but you don't want to run the overhead of a MLATHUB, you can leave any entries starting withmlatin theULTRAFEEDER_CONFIGparameter, and setMLATHUB_DISABLE=trueSet the parameter
TAR1090_DISABLE=true. This will prevent thenginxwebserver and any websites from being launchedMake sure not to use the
dhcr.io/sdr-enthusiasts/docker-adsb-ultrafeeder:telegraflabel as Telegraf adds a LOT of resource use to the container
Troubleshooting
It is possible that you won't see any planes, either with the docker command above or when pointing your web browser at the readsb container. This can have a number of root causes - a common one being that active radio transmissions in other frequency bands that are reasonably "close" to the ADS-B band are completely overwhelming your SDR at the default starting gain of 49.6. It may be necessary to lower the starting point for the autogain script to at least allow the detection of some planes in order for the script to work. So if even after a few minutes you don't see any planes at all (and no ADS-B messages in the "Performance Graphs"), you may want to try to force a lower starting gain value into the autogain algorithm. To do this, please do the following. You may have to try different values instead of the value of 34 suggested here:
Set the
READSB_AUTOGAIN_INITIAL_GAINvariable in theultrafeedersection of your docker-compose file:
Then reset the autogain process with this command and recreate the container to apply the new
READSB_AUTOGAIN_INITIAL_GAINvalue :
Advanced
If you want to look at more options and examples for the ultrafeeder container, you can find the respository here.
Last updated