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
ultrafeeder
that will run theghcr.io/sdr-enthusiasts/docker-adsb-ultrafeeder
container.We're mapping TCP port
8080
through to the container so we can access the web interface.The variable
READSB_RTLSDR_DEVICE
tellsreadsb
to 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
.env
file (denoted by${VARIABLE}
).
We're using
tmpfs
for volumes that have regular I/O. Any files stored in atmpfs
mount 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:
When feeding AdsbExchange, Ultrafeeder will send statistics to adsbexchange.com by default. See the description of the ADSBX_STATS
parameter on how to disable this.
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
ultrafeeder
Once 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/
:tar1090
map 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 aircraft in the last 24 hourshttp://my_host_ip:8080?replay
: showing a time-lapse 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_CONFIG
parameter, remove any entry that starts withmlat
ormlathub
. This will prevent anymlat-client
s ormlathub
instances 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 withmlat
in theULTRAFEEDER_CONFIG
parameter, and setMLATHUB_DISABLE=true
Set the parameter
TAR1090_DISABLE=true
. This will prevent thenginx
web server and any websites from being launchedMake sure not to use the
dhcr.io/sdr-enthusiasts/docker-adsb-ultrafeeder:telegraf
label 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_GAIN
variable in theultrafeeder
section of your docker-compose file:
Then reset the autogain process with this command and recreate the container to apply the new
READSB_AUTOGAIN_INITIAL_GAIN
value :
Advanced
If you want to look at more options and examples for the ultrafeeder
container, you can find the repository here.
Last updated