Alimentar varias redes ADS-B a la vez con Docker y Ultrafeeder

Primero PiAware, luego fr24feed, después el script para adsb.fi y otro para adsb.lol: quien deja crecer su receptor durante años acaba teniendo un sistema lleno de servicios, archivos de configuración y dependencias. La comunidad sdr-enthusiasts sigue otro camino: un único contenedor Docker llamado Ultrafeeder se encarga de la decodificación, el mapa, las estadísticas y todos los feeds comunitarios, y cada red adicional llega como un contenedor propio, bien separado. Esta guía te muestra cómo alimentar varias redes ADS-B a la vez con Ultrafeeder, qué archivos necesitas y cómo no perder la visión de conjunto.

La respuesta corta

Alimentas varias redes a la vez instalando Docker en un ordenador con Linux y creando un docker-compose.yml con el contenedor Ultrafeeder como central. Ultrafeeder lee tu SDR, decodifica las señales con readsb y envía los datos a todas las redes comunitarias que añadas en la variable ULTRAFEEDER_CONFIG. Los servicios comerciales como FlightAware o Flightradar24 los acoplas como contenedores adicionales que obtienen sus datos de la central mediante BEASTHOST=ultrafeeder. Las coordenadas, la altura y las claves están reunidas en un archivo .env.

El principio es el mismo que con los scripts individuales de Alimentar ADS-B Exchange y las redes comunitarias: un decodificador genera un flujo de datos y varios feeders lo toman. Solo que con Docker cada pieza funciona en su propia cápsula.

¿Por qué Docker para un receptor ADS-B?

En su guía, sdr-enthusiasts justifica su enfoque con varios puntos que los spotters con un zoo de feeders en crecimiento notan al instante:

• Aislamiento: cada contenedor trae su propio software. Las distintas versiones de bibliotecas no se estorban y el sistema anfitrión se mantiene limpio.
• Ampliación sencilla: una red nueva significa un contenedor más o dos líneas de configuración, sin el temor de que un script de instalación sobrescriba algo.
• Configuración centralizada: en lugar de mantener archivos en /etc/default/ y en diversas carpetas de programas, todo está en el archivo Compose y en el archivo .env.
• Hardware compartido: el ordenador puede sostener además otros servicios. Eso ahorra un dispositivo más y electricidad.

El precio: deberías conocer algunos conceptos básicos de Docker o estar dispuesto a aprenderlos. Quien solo quiera alimentar una red y ya tenga una Pi en marcha suele llegar antes con los paquetes clásicos. Un resumen de todas las variantes lo da Comparativa de programas de feeder ADS-B.

Qué lleva dentro Ultrafeeder

Ultrafeeder no es un programa nuevo, sino un paquete cuidadosamente montado de herramientas de código abierto contrastadas:

Componente	Función
readsb	Decodifica las señales del SDR y distribuye los datos por puertos de red
tar1090	Interfaz de mapa en el navegador, con reproducción, trazas de las últimas 24 horas y mapa de calor
graphs1090	Gráficos de tasa de mensajes, alcance, intensidad de señal y carga del sistema
mlat-client	Una instancia por cada servidor MLAT añadido
MLAT-Hub	Reúne posiciones MLAT calculadas de varias fuentes
Autogain	Regula la ganancia del RTL-SDR; se recomienda la variante integrada de readsb

Si ya conoces readsb y tar1090, te orientarás al instante: las interfaces son las mismas que en Instalar readsb y tar1090. Lo único nuevo es que todo funciona en un contenedor y se controla con variables de entorno.

Preparación: hardware y sistema anfitrión

En hardware necesitas lo habitual: un ordenador, un SDR y una antena de 1090 MHz. Qué SDR es adecuado lo aclara la comparativa de SDR para ADS-B, y la antena la construyes según Construir una antena de 1090 MHz. El ordenador no tiene por qué ser una Raspberry Pi; la guía de sdr-enthusiasts se dirige a sistemas basados en Debian como Raspberry Pi OS, Ubuntu o DietPi. Posibles alternativas a la Pi las describe Recibir ADS-B sin Raspberry Pi.

Para el sistema anfitrión, el proyecto ofrece un script de instalación que configura Docker y el plugin Compose, ajusta las reglas udev para los RTL-SDR y bloquea los controladores de kernel preinstalados para estos SDR, de modo que los contenedores puedan acceder al SDR:

bash <(curl -s https://raw.githubusercontent.com/sdr-enthusiasts/docker-install/main/docker-install.sh)

Como siempre con los scripts de internet: léelo antes. El propio proyecto recomienda precisamente eso.

Renombrar el SDR

Casi todos los RTL-SDR salen de fábrica con el mismo número de serie. Para que el contenedor encuentre el SDR correcto (a más tardar cuando se añada un segundo para radio aeronáutica o UAT), asignas un número de serie único. La recomendación es 1090 para el SDR de ADS-B. Para ello conectas solo ese SDR y escribes el número con rtl_eeprom desde la imagen de Ultrafeeder:

docker run --rm -it --device /dev/bus/usb --entrypoint rtl_eeprom ghcr.io/sdr-enthusiasts/docker-adsb-ultrafeeder -s 1090

Tras confirmar, desconectas el SDR y lo vuelves a conectar. Según la guía, no basta con reiniciar el ordenador.

Carpeta del proyecto y archivo .env

La guía lo guarda todo en /opt/adsb. Allí están el archivo Compose y un archivo .env oculto con tus datos maestros:

sudo mkdir -p -m 777 /opt/adsb
cd /opt/adsb
nano .env

En el .env van, entre otros, estos valores:

FEEDER_LAT=48.1234567
FEEDER_LONG=11.1234567
FEEDER_ALT_M=520
FEEDER_TZ=Europe/Berlin
FEEDER_NAME=meine-station
ADSB_SDR_SERIAL=1090
ADSB_SDR_PPM=
ULTRAFEEDER_UUID=

Las cifras son marcadores: introduce tus propios valores. FEEDER_NAME se transmitirá más tarde a las redes como nombre MLAT; elígelo de modo que puedas vivir con que aparezca públicamente. Una UUID la generas con:

cat /proc/sys/kernel/random/uuid

Importante para la privacidad: la guía advierte de no usar la misma UUID en todas las redes, porque entonces tu estación sería reconocible a través de los servicios. Por eso genera una UUID propia para cada red y guárdala con nombres descriptivos como ADSBFI_UUID o ADSBLOL_UUID en el .env.

El docker-compose.yml con Ultrafeeder

Ahora llega el corazón. Un ejemplo abreviado, basado en la guía de sdr-enthusiasts, con dos redes comunitarias:

services:
  ultrafeeder:
    image: ghcr.io/sdr-enthusiasts/docker-adsb-ultrafeeder
    container_name: ultrafeeder
    hostname: ultrafeeder
    restart: unless-stopped
    device_cgroup_rules:
      - "c 189:* rwm"
    ports:
      - 8080:80
    environment:
      - LOGLEVEL=error
      - TZ=${FEEDER_TZ}
      - READSB_DEVICE_TYPE=rtlsdr
      - READSB_RTLSDR_DEVICE=${ADSB_SDR_SERIAL}
      - READSB_RTLSDR_PPM=${ADSB_SDR_PPM}
      - READSB_GAIN=auto
      - READSB_LAT=${FEEDER_LAT}
      - READSB_LON=${FEEDER_LONG}
      - READSB_ALT=${FEEDER_ALT_M}m
      - UUID=${ULTRAFEEDER_UUID}
      - MLAT_USER=${FEEDER_NAME}
      - ULTRAFEEDER_CONFIG=
          adsb,feed.adsb.fi,30004,beast_reduce_plus_out,uuid=${ADSBFI_UUID};
          mlat,feed.adsb.fi,31090,uuid=${ADSBFI_UUID};
          adsb,in.adsb.lol,30004,beast_reduce_plus_out,uuid=${ADSBLOL_UUID};
          mlat,in.adsb.lol,31090,uuid=${ADSBLOL_UUID}
    volumes:
      - /opt/adsb/ultrafeeder/globe_history:/var/globe_history
      - /opt/adsb/ultrafeeder/graphs1090:/var/lib/collectd
      - /proc/diskstats:/proc/diskstats:ro
      - /dev/bus/usb:/dev/bus/usb:rw
    tmpfs:
      - /run:exec,size=256M

Los valores en ${...} los lee Docker Compose automáticamente del .env de la misma carpeta. La entrada tmpfs guarda los datos volátiles en la memoria RAM y cuida así la tarjeta SD. Las rutas bajo volumes hacen que el historial del mapa y las estadísticas sobrevivan a un reinicio del contenedor. La plantilla completa y actualizada, con todas las variables opcionales, la encuentras en la guía y en el repositorio de GitHub del proyecto: en caso de duda, usa su versión.

Cómo leer ULTRAFEEDER_CONFIG

Cada entrada empieza con un tipo:

• adsb,<host>,<puerto>,<protocolo> envía tus datos ADS-B a un servidor u obtiene datos de una fuente. Para la mayoría de las redes más recientes, el proyecto recomienda el protocolo beast_reduce_plus_out, un formato Beast aligerado.
• mlat,<host>,<puerto> arranca una instancia propia de mlat-client para ese servidor.
• mlathub,<host>,<puerto>,<protocolo> recibe resultados MLAT de otros feeders y los reúne.

Opcionalmente añades uuid=.... Si falta, el contenedor usa la variable general UUID. Las entradas se separan con punto y coma, y dentro de una entrada no puede haber ni puntos y coma ni comas adicionales en los valores.

Red	Datos (host, puerto)	MLAT (host, puerto)
adsb.fi	feed.adsb.fi, 30004	feed.adsb.fi, 31090
adsb.lol	in.adsb.lol, 30004	in.adsb.lol, 31090
airplanes.live	feed.airplanes.live, 30004	feed.airplanes.live, 31090
Planespotters	feed.planespotters.net, 30004	mlat.planespotters.net, 31090
ADS-B Exchange	feed1.adsbexchange.com, 30004	feed.adsbexchange.com, 31090

Las direcciones proceden del README del proyecto Ultrafeeder, a octubre de 2026. Allí figuran más redes, algunas regionales. Como los nombres de host pueden cambiar, contrástalos con la lista actual antes de introducirlos. Qué mapa muestra qué lo compara Comparativa de rastreadores comunitarios sin filtros, y los antecedentes de ADS-B Exchange los da ADS-B Exchange explicado.

Arrancar y comprobar

Se arranca en la carpeta del proyecto con:

docker compose up -d

Al cabo de uno o dos minutos abres en el navegador http://<ip-de-tu-ordenador>:8080/. Allí aparece el mapa tar1090 con lo que recibes. Complementos útiles son /graphs1090/ para las estadísticas y los parámetros ?pTracks para las trazas de las últimas 24 horas, ?heatmap para un mapa de calor y ?replay para la reproducción. Qué revelan los gráficos sobre tu antena lo explica Medir el rendimiento de recepción con graphs1090.

Redes comerciales como contenedores propios

FlightAware, Flightradar24 y otros servicios comerciales exigen sus propios programas de feeder con claves. También para eso ofrece sdr-enthusiasts imágenes ya hechas. El patrón es siempre el mismo: el contenedor recibe BEASTHOST=ultrafeeder, obtiene por esa vía el flujo de datos de la central y se identifica ante el servicio con tu clave del .env.

Servicio	Imagen	Variable de clave	Interfaz local en el ejemplo
FlightAware	ghcr.io/sdr-enthusiasts/docker-piaware	FEEDER_ID	Puerto 8081 (SkyAware)
Flightradar24	ghcr.io/sdr-enthusiasts/docker-flightradar24	FR24KEY	Puerto 8754
AirNav Radar	ghcr.io/sdr-enthusiasts/docker-airnavradar	SHARING_KEY	–
Plane Finder	ghcr.io/sdr-enthusiasts/docker-planefinder	SHARECODE	Puerto 30053

La guía tiene además instrucciones para OpenSky Network, ADSBHub, Plane.watch, RadarVirtuel y otras redes. Un ejemplo para FlightAware se ve así:

  piaware:
    image: ghcr.io/sdr-enthusiasts/docker-piaware:latest
    container_name: piaware
    restart: unless-stopped
    ports:
      - 8081:8080
    environment:
      - BEASTHOST=ultrafeeder
      - MLAT_RESULTS_BEASTHOST=ultrafeeder
      - MLAT_RESULTS_BEASTPORT=31004
      - TZ=${FEEDER_TZ}
      - FEEDER_ID=${PIAWARE_FEEDER_ID}
    tmpfs:
      - /run:exec,size=64M
      - /var/log

Las dos líneas MLAT_RESULTS devuelven al MLAT-Hub de Ultrafeeder las posiciones MLAT calculadas por FlightAware, de modo que aparecen también en tu mapa local.

Reutilizar las claves o generar otras nuevas

Aquí está el tropiezo más importante de la migración: quien ya hace de feeder reutiliza sus claves anteriores. Si no, el servicio crea una estación nueva, y las estadísticas y las contraprestaciones de feeder quedan en la antigua. Las guías indican los comandos para instalaciones existentes:

• FlightAware: piaware-config -show feeder-id en el sistema antiguo. Los feeders nuevos pueden registrarse una vez con un contenedor temporal y asignarse después a una cuenta en flightaware.com. Procura que la posición y la altura en FlightAware coincidan con tu .env, o MLAT no funcionará. Más sobre FlightAware en sí está en Instalar y configurar PiAware.
• Flightradar24: la Sharing Key está en el antiguo /etc/fr24feed.ini. Los feeders nuevos ejecutan el diálogo de alta en un contenedor temporal. Los antecedentes los da Configurar fr24feed.
• AirNav Radar: rbfeeder --showkey --no-start o echar un vistazo a /etc/rbfeeder.ini muestra la clave antigua. Sin clave, el contenedor genera una nueva en el primer arranque y la imprime en el registro. Más sobre el servicio en sí está en Usar AirNav RadarBox.
• Plane Finder: el Share Code lo encuentras en la cuenta de planefinder.net, en tus receptores. Un resumen del servicio lo da Plane Finder de un vistazo.

Los feeders antiguos del sistema anfitrión los apagas antes de que los contenedores tomen el relevo; si no, se identifican dos programas con la misma clave. Qué suscripciones y ventajas te dan los servicios por hacer de feeder lo compara Qué reciben los feeders a cambio.

MLAT con varias redes

Cada línea mlat de ULTRAFEEDER_CONFIG arranca un mlat-client propio. Tu estación participa así en la multilateración de cada red añadida, y cada red calcula con las estaciones que participan en ella. Cuantas más redes alimentas, mayor es la probabilidad de que en alguna haya suficientes vecinos a tu alcance. Justamente los aviones militares sin informe de posición propio solo aparecen entonces; cómo trabaja el procedimiento está en MLAT y multilateración.

Los requisitos son los mismos que en cualquier otra instalación: coordenadas exactas, altura de antena correcta y una recepción estable. La ventaja de Docker: estos valores están una sola vez en el .env y valen automáticamente para todas las redes. Ya no hay erratas en archivos de configuración sueltos que dejen MLAT inutilizado en una red pero no en otra.

Funcionamiento: registros, actualizaciones, salud

En el día a día te bastan unos pocos comandos, que ejecutas en la carpeta /opt/adsb:

Tarea	Comando
Seguir todos los registros en directo	docker compose logs -f
Registro de un contenedor	docker logs -f ultrafeeder
Estado y salud	docker ps
Aplicar cambios en .env o Compose	docker compose up -d
Actualizar todas las imágenes	docker compose pull, después docker compose up -d

Los contenedores de sdr-enthusiasts traen comprobaciones de salud. En la columna STATUS de docker ps aparece entonces healthy, unhealthy o health: starting. Si un contenedor muestra unhealthy de forma permanente, su registro suele darte el motivo: a menudo una clave incorrecta, un SDR no encontrado o una errata en ULTRAFEEDER_CONFIG.

Síntoma	Causa probable	Solución
Mapa vacío, el registro no detecta ningún dispositivo	Número de serie incorrecto o SDR ocupado por otro programa	Comprobar el número de serie, detener el decodificador antiguo en el anfitrión
Una red no recibe datos	Errata o punto y coma que falta en ULTRAFEEDER_CONFIG	Contrastar la entrada con la lista del proyecto, docker compose up -d
Contenedor de FlightAware unhealthy	Falta el ID de feeder o la ubicación en FlightAware difiere	Revisar el ID en .env, igualar la posición en la cuenta
Estación duplicada en un servicio	Se usó una clave nueva en lugar de la antigua	Introducir la clave antigua en .env, recrear el contenedor

Para usuarios avanzados, la guía describe además actualizaciones automáticas, el reinicio automático de contenedores no saludables y análisis con Grafana. Para empezar no necesitas nada de eso.

Para quién compensa el cambio

Para la práctica del spotter, un receptor bien alimentado aporta una ventaja muy tangible: tu región queda cubierta con más densidad en varios mapas, a menudo justo donde haces spotting, por ejemplo en la colina de observación del aeropuerto de Múnich (Besucherhügel) con vistas al aeropuerto de Múnich, o en la colina de spotters de Teveren (Spotterhügel), donde está estacionada la flota AWACS de la OTAN. A ello se suman herramientas con las que luego compruebas qué pasó realmente por allí; cómo se hace lo muestra Contrastar avistamientos con registros ADS-B. Si la recepción y la divulgación de los datos están permitidas en tu país lo aclara Recibir datos ADS-B: la situación legal.

Conclusión

Con el Ultrafeeder de sdr-enthusiasts, un popurrí de feeders crecido a lo largo del tiempo se convierte en un sistema ordenado: un contenedor para decodificador, mapa, estadísticas y todas las redes comunitarias, más un contenedor ligero por cada servicio comercial. El mayor cuidado merecen, como siempre, los datos maestros: coordenadas, altura, claves y UUID separadas. Con el .env hecho, cada red adicional es cuestión de dos líneas y un docker compose up -d.