25.759 estrellas, 3.991 dólares de PCB desnudo y un «alcance de 20 km» que en realidad es un límite de temporización: auditoría del radar AERIS-10 de código abierto

Hay un repositorio en GitHub llamado PLFM_RADAR con 25.759 estrellas, 5.886 forks y un párrafo de presentación que sería asombroso incluso si solo la mitad fuese cierta: un radar de barrido electrónico en banda de 10,5 GHz con modulación LFM de pulso, publicado con esquemáticos, Gerbers, listas de materiales, Verilog de FPGA y una interfaz gráfica en Python. Dos versiones: una «Nexus» de 3 km y una «Extended» de 20 km. En abril, la prensa lo recogió con el titular «radar DIY de código abierto que cuesta un 95% menos que alternativas comerciales de 250.000 dólares».

Ahí empieza el problema, porque el repositorio es un documento muy distinto del marketing. Y, en conjunto, uno mucho más interesante: 225 MB de hardware abierto donde se ve a un ingeniero en solitario, una cadena de contribuciones asistida por IA y un grupo de desconocidos en el rastreador de incidencias intentando converger al mismo tiempo hacia un radar en banda X construible.

Esta auditoría se basa en el repositorio en el commit 749bd0f8 (17 de junio de 2026), su sitio de documentación de ingeniería, cuatro hojas de cálculo de BOM/CPL analizadas celda a celda, los parámetros de su propio generador de co-simulación, su propio código de diagrama de antena reejecutado en local, doce incidencias con sus hilos de comentarios, la página de Hackaday del autor y el sitio web de su empresa. Donde hago un cálculo, muestro las entradas, porque la tesis de este artículo es precisamente que las entradas que faltan son la historia.

Qué contiene realmente el repositorio

GitHub etiqueta el lenguaje principal del repositorio como PLSQL. En el árbol hay cero archivos .sql. No es un escándalo —es el detector de lenguajes de GitHub adivinando a partir de extensiones que no reconoce— pero resume bastante bien lo bien que el envase se corresponde con el contenido.

De esa tabla hay dos datos que importan más que el resto. El primero: el 35% de un repositorio de 225 MB son PDF de fabricantes redistribuidos —Analog Devices, Qorvo, Murata, algunos escaneos de 10 MB— dentro de un proyecto de hardware abierto cuya licencia cubre documentación de diseño. El segundo: los bitstreams de FPGA versionados son de otro módulo. Se llaman te0713-te0701-heartbeat-2026-03-21.bit y te0713-te0701-umft601x-dev-2026-03-21.bit —módulos Trenz TE0713, que montan una XC7A200T— mientras el README del propio proyecto dice que la placa de producción lleva una XC7A50T.

Hallazgo 1: la placa no sabe qué FPGA tiene

No es una ambigüedad menor, y sigue sin resolverse en público.

• El README indica «XC7A50T FPGA — Handles RADAR Signal Processing on the upstream FTG256 board».
• El BOM dentro del conjunto de producción indica XC7A50T-2FTG256I en la referencia U42.
• El sitio de documentación de ingeniería afirma, dos veces, que «the current production target remains xc7a200t-2fbg484i» y que «Build 25 is the current production baseline for the XC7A200T target».
• El README de las restricciones no resuelve nada: documenta cuatro objetivos —«placa de producción 50T», «placa de desarrollo premium 200T», dos módulos Trenz— y admite en la cabecera del archivo de 50T que «The README and prior version of this file incorrectly referenced XC7A100TCSG324-1». Tres familias de dispositivos distintas citadas en la documentación del mismo repositorio.

Los dos encapsulados no pueden confundirse físicamente: un FTG256 mide 17 × 17 mm con 256 bolas; un FBG484, 22 × 22 mm con 484 bolas. En la incidencia #186, un revisor externo hizo la aritmética a partir de los archivos de Eagle: el footprint de la placa es de 256 bolas a 1 mm de paso, así que la placa es una placa de 50T «y no existe ninguna versión de 200T de este diseño. El archivo xc7a200t_fbg484.xdc debe de pertenecer a otra cosa». Después compiló el objetivo de 200T por completitud y encontró que «su archivo de restricciones tiene pines sin asignar, lo que encaja con tu conclusión de que nunca ha existido una placa de 200T».

El autor no ha respondido. La incidencia #186 preguntaba, el 22 de agosto, «¿cuál es la FPGA de producción, la 50T o la 200T?». Cinco semanas después la pregunta sigue abierta, y la única actividad del autor en ese periodo es un mensaje del 21 de septiembre titulado «I’m back», disculpándose por el silencio.

¿Por qué importa? Porque decide si puedes construirlo, y hoy por hoy la respuesta es no —véase el punto siguiente.

Hallazgo 2: el firmware documentado no cabe en la placa para la que está documentado

El informe de ingeniería del propio proyecto para su línea base de producción actual, Build 25, declara 9.252 LUT, 12.488 flip-flops, 17 bloques BRAM y 142 slices DSP48E1 al 19,19% de una XC7A200T. Una XC7A50T tiene 120 slices DSP48 y 150 bloques RAMB18 en total.

Un futuro constructor lo comprobó por su cuenta en la incidencia #186: armó «el estado más reciente del código (la línea feat/dual-range-v2 más los arreglos sin fusionar de develop y integration/fft-2048-on-p0)» y ejecutó el propio scripts/50t/build_50t.tcl del repositorio en Vivado 2025.2:

El DRC falla antes de la colocación: 129 DSP48 necesarios frente a 120 disponibles, y 188 equivalentes RAMB18 frente a 150. Era la configuración de 3 km con el interruptor de largo alcance desactivado. Así que una placa fabricada hoy ejecuta el firmware antiguo de 3 km, pero no la arquitectura actual de tres formas de onda.

Su siguiente mensaje encontró la solución práctica: la XC7A100T-2FTG256I usa el mismo encapsulado de 256 bolas y el firmware actual cabe con la temporización cumplida (DSP 54%, block RAM 77%, LUT 38%). Es información realmente útil —llegada de un desconocido, publicada en el rastreador, sin respuesta del autor cinco semanas después— y no aparece en ninguna parte del README.

Hay un segundo problema de capacidad, más silencioso. radar_system_top_50t.v empieza con este comentario:

La XC7A50T-FTG256 solo tiene 69 pines de E/S utilizables, pero radar_system_top declara muchos más bits de puerto (incluido FT601 USB 3.0, salidas de depuración y señales de estado que no tienen conexión física en la placa de 50T).

El README de restricciones confirma la consecuencia: USB 3.0 mediante FT601 es USB_MODE 0, «placa de desarrollo premium 200T»; la placa de producción de 50T usa por defecto USB_MODE 1, un FT2232H sobre USB 2.0, 8 bits a 60 MHz. Es decir, la configuración «de producción» saca los datos por un puente FIFO paralelo, y la ruta USB 3.0 se ejercita en un módulo de desarrollo cuya existencia el propio repositorio no puede confirmar.

Hallazgo 3: el BOM publicado es una conversación con el taller, no una entrega controlada

El README indica al constructor: «Source Components: BOM/CPL files are co-located under /4_Schematics and Boards Layout/4_7_Production Files». Esto es, exhaustivamente, lo que hay en la hoja de cálculo del BOM de la placa principal:

• 103 líneas, 93 números de referencia distintos.
• 29 celdas de observaciones que son mensajes del taller al autor.
• 9 líneas marcadas [DNP不要贴] —no montar, en chino, en el archivo desde el que se supone que compras.
• 14 líneas con anotaciones en chino, incluida [Supplied by customer客供] en los conectores SMA, en los cuatro desfasadores ADAR1000 y en los dieciséis front-ends ADTR1107 (material consignado).
• 7 correcciones de valor o encapsulado marcadas por el taller, todas terminadas en «Please confirm»: MLASU063SCG101JFNA01 figura como «103pF» pero son «100pF»; GRM0335C1H111GA01D figura como «106pF» pero son «110pF»; MLG0603PR11JTD25 figura como «107,3nH» pero son «110nH»; GJM0335C1E330JB01D como «32,8pF» pero son «33pF»; una resistencia como «5Ω» pero son «5,1Ω»; y un cristal cuyo encapsulado es «SMD2520-4P, not CRYSTAL-12MHZ…SMD-2X2.5MM».
• 3 sustituciones sin confirmar: «The part we will supply is GRM033R61A472KA01D OK?» y dos más.
• 2 líneas que dicen «The part we can get here was made in the year of 2022+ OK?»: stock envejecido, ofrecido como opción.
• 1 línea que dice «[Price is changing higher, final price should be subjected to the real price when order!]».
• 1 línea que dice «information on chip will be removed»: el taller ofreciendo borrar las marcas de la XC7A50T. En un proyecto de hardware abierto, es llamativo que eso se haya conservado literalmente en el archivo que se distribuye.
• Y dos valores literales de MPN: Do Not Put y Not a component.

Fíjate en el patrón de las correcciones: 103 pF, 106 pF, 107,3 nH. Son códigos EIA de tres cifras (103 = 10 nF, 106 = 10 µF, 110 = 11 × 10¹) leídos como valores directos. La columna de valores del BOM se ha derivado en parte malinterpretando los números de referencia, que es exactamente el fallo que describió otro revisor en la misma incidencia:

en la placa principal solo 27 líneas del BOM tienen número de referencia dentro del CAD, casi todas los integrados. Todos los números de los pasivos existen solo en las hojas de cálculo.

Y las hojas de cálculo se contradicen entre sí. He contado cinco conjuntos de archivos de producción; la placa de PA incluye BOM.xlsx y BOM_PA.xlsx (una sin números de referencia), la de alimentación tres archivos tipo BOM y la de síntesis de frecuencia dos. Resumen de un revisor: «hay varios archivos tipo BOM por placa y no coinciden entre sí. Al final generé mi propio BOM y mi propio archivo de posicionamiento directamente desde el .brd, porque el archivo de la placa es el único que no puede estar desactualizado respecto a sí mismo».

Esa es la frase más accionable de todo el rastreador.

Por último, los directorios de esquemáticos y de producción fueron borrados y vueltos a subir a través de la interfaz web de GitHub durante mayo y junio de 2026: commits titulados «Add files via upload» alternando con «Delete 4_Schematics and Boards Layout/4_6_Schematics/MainBoard directory» y «Delete …/Gerber_Main_Board directory». Por eso el último commit de un repositorio de hardware dice «Add files via upload», y por eso hoy nadie —incluido el autor— puede afirmar qué conjunto de Gerbers corresponde a qué esquemático. Un incidente anterior, citado en la incidencia #186, es ilustrativo: un paquete publicado «puede quedarse ahí pareciendo actual mientras en realidad son archivos obsoletos de otro proyecto».

Hallazgo 4: el único precio publicado cubre placas desnudas —3.991 dólares

El proyecto no publica nunca un coste de construcción. La única cifra del registro público es la respuesta del propio autor, en la incidencia #150, a un constructor que preguntaba cuánto costaban las placas (MOQ 2 por PCB, solo fabricación, sin componentes):

Queda fuera de ese número: todos los componentes, el montaje y el pick-and-place, el array de guía de onda ranurada rellena de alúmina de 32 × 16 (el repositorio incluye su modelo OpenEMS y los datos de las ranuras, no un presupuesto), el anillo colector, el motor paso a paso, las 16 carcasas de PA, la refrigeración, la envolvente y la XC7A50T en una placa del orden de 1.000 $. Con un MOQ de 2, el primer pedido son unos 7.982 $ antes de un solo componente.

La configuración «N» de 3 km son 1.303 $ de placas desnudas (principal, alimentación y síntesis; sin placas de PA). Frente al «90-95% por debajo de las alternativas comerciales» que el autor usa en su página de Hackaday —donde la referencia es «más de 250.000 $»—, el titular honesto es: puedes empezar a pedir hardware de banda X por cuatro cifras, y el repositorio no te da forma alguna de saber la cifra final.

Hallazgo 5: «20 km» es el límite de rango no ambiguo, no un alcance de detección

Este es el cálculo que más ganas tenía de hacer, y el repositorio lo permite porque su generador de escenas de co-simulación publica la forma de onda:

F_CARRIER      = 10.5e9    CHIRP_BW = 20e6     # 30 MHz -> 10 MHz en FI
FS_ADC         = 400e6     ADC_BITS = 8
T_LONG_CHIRP   = 30e-6     T_LISTEN = 137e-6
CHIRPS_PER_FRAME = 32
MAX_UNAMBIGUOUS_RANGE = C_LIGHT * T_LISTEN / 2   # ~20.55 km

Esa última línea lo explica todo. c × 137 µs ÷ 2 = 20,54 km: el mismo número que la especificación de 20 km del README para la variante Extended. El alcance estrella del producto de gama alta es el rango no ambiguo de la ventana de escucha, una propiedad temporal de la forma de onda, no una afirmación sobre lo que el radar puede ver. Y es un techo duro: ninguna cantidad de potencia transmitida lo mueve.

Lo que el radar puede ver de verdad es una cuestión de balance de enlace, y el repositorio no la responde en ninguna parte (una búsqueda de «link budget» en todo el código devuelve cero archivos). Así que lo he construido con sus propios parámetros, declarando cada suposición:

Resolviendo qué distancia da una SNR de 13 dB después del proceso:

Conviene leer esa tabla con atención, porque es informativa de verdad y no es una refutación. Las dos cifras publicitadas son coherentes entre sí, pero con dos clases de blanco distintas. Los 3 km de la versión N encajan con un dron de 0,01 m²; los 20 km de la versión X encajan con un blanco de 1 m² y coinciden con el techo de la forma de onda. Para el caso de uso que el README nombra primero —«diseñado para investigadores, desarrolladores de drones»— el alcance realista de detección de la configuración X está en torno a 8-11 km, no 20. Ni el repositorio, ni la documentación, ni el marketing indican la RCS, la probabilidad de detección o la tasa de falsa alarma que permitirían al lector saber cuál de las dos cifras le aplica.

Dos consecuencias más de esa misma forma de onda, ambas comprobables: la resolución en distancia es de 7,5 m (c/2B con B = 20 MHz), suficiente para vigilancia de espacio aéreo y gruesa para clasificar blancos pequeños; y los convertidores son de 8 bits en toda la cadena, un AD9708 generando los chirps y un AD9484 de 8 bits y 500 MSPS digitalizándolos. Un ADC de 8 bits tiene una SNR ideal de unos 50 dB. Es una decisión defendible para abaratar costes, y es también la razón de que el balance anterior dependa casi por completo de la ganancia de proceso y no del margen del receptor.

Hallazgo 6: el «barrido electrónico» y lo que dice el propio código de antena

El README promete «Full Electronic Beam Steering — ±45° electronic steering in elevation and azimuth». La página del proyecto en Hackaday del propio autor (39,6 mil visitas, 326 seguidores) dice otra cosa del prototipo:

El prototipo usa los 16 elementos de antena para orientar el haz en elevación y el acimut se realiza con un motor paso a paso; pero el sistema diseñado se puede modificar para controlar electrónicamente tanto elevación como acimut.

Hay una diferencia importante entre «electrónico en ambos ejes» y «electrónico en elevación, mecánico en acimut», y no se reconcilia en ningún otro sitio.

Aparte de eso, la geometría del array en el repositorio tiene una condición de contorno física que conviene conocer antes de encargar una guía de onda de 32 × 16. En 5_Simulations/array_pattern_Kaiser25dB_like.py la separación entre elementos es:

M, N = 16, 32
dy = 14.275831333333334e-3   # 0,5000 lambda a 10,5 GHz
dz = 16.915e-3               # 0,5924 lambda a 10,5 GHz

dz es λg/2 para una guía rellena de alúmina (εr = 9,8 → λg = 33,83 mm), que es lo correcto para excitación de ranuras en fase, y equivale a 0,592 longitudes de onda en espacio libre. He reejecutado el código de factor de array del propio archivo con esos valores:

• Los lóbulos de difracción entran en el espacio visible en el eje de 32 ranuras a un apuntamiento de ±43,5°. Con apuntamiento de 45°, el lóbulo no principal más alto está en −9,7 dB; a 60°, en 0,0 dB, es decir, tan fuerte como el haz principal.
• Los dos ejes están ponderados de forma muy distinta: el eje de 32 elementos usa una ventana de Kaiser β = 1,65 (lóbulo lateral máximo −21,8 dB) y el de 16 elementos es uniforme (np.ones(16), lóbulo lateral máximo −13,3 dB). El archivo se llama Kaiser25dB_like; el mejor caso real medido en ambos planos es −13,3 dB.
• La tabla de ranuras y el código coinciden exactamente (los pesos del CSV igualan np.kaiser(32, 1.65) con diferencia 0,0). Pero todas las ranuras tienen la misma longitud (15,9 mm) y anchura (0,571 mm), mientras que el control de acoplo —el desplazamiento de la ranura— solo varía de 1,8 mm a 2,1 mm, un rango de 1,17×, frente a una taper de amplitud pretendida de 1,81×.

Y el script solo evalúa theta0_deg = 0.0: apuntamiento al cenit. La verificación del barrido es una petición abierta del propio repositorio: la incidencia #147, titulada «Antenna Simulation», pide a alguien externo que revise «el diagrama de radiación 3D… y luego necesitamos integrar el array completo (16 guías de onda) para comprobar las capacidades de apuntamiento del haz», con el autor publicando resultados de OpenEMS en agosto y ofreciendo el código.

En resumen: la afirmación de ±45° está limitada por la física de los lóbulos de difracción a 43,5° en un plano, no está verificada fuera del cenit en el repositorio y está contradicha, para el prototipo, en la propia página del autor.

Hallazgo 7: la licencia no dice lo que el README dice que dice

La sección de licencia del README es inusualmente cuidadosa para el género —hardware bajo CERN-OHL-P, software bajo MIT— y termina así:

The complete CERN-OHL-P license text is in the LICENSE file.

El archivo se llama Licence (ortografía británica, sin extensión). LICENSE devuelve 404. La consecuencia práctica se ve en la propia página del repositorio: GitHub informa la licencia como NOASSERTION, porque su detector no puede emparejar el archivo. Y como la insignia superior del README anuncia «License: MIT» mientras no hay texto MIT en ninguna parte del repositorio, la descripción honesta es: el texto CERN-OHL-P está presente; la cesión MIT que el README promete para todo el código de FPGA, firmware e interfaz gráfica, no. Quien quiera reutilizar el firmware comercialmente tiene la palabra del README y nada más.

Dos puntos relacionados que conviene presupuestar:

• El material de terceros no está cubierto. Se redistribuyen 50 PDF de fabricantes (el 35% del repositorio por tamaño) sin licencia alguna. La definición de «Documentation» de CERN-OHL-P cubre documentación de diseño, no las notas de aplicación de Analog Devices o Qorvo.
• Un componente necesario está restringido a la exportación. La placa de PA de la variante de 20 km se basa en el amplificador GaN Qorvo QPA2962; palabras del propio autor en la incidencia #175: «The QPA2962 is very difficult to buy since it is tagged as exportation restricted. I’m planning to use the QPA1010 on the new design, but I need to go through all the technical documentation». A día de hoy el diseño de PA publicado sigue siendo el de ese componente, y el sustituto es una intención, no un archivo. Si estás fuera de la jurisdicción relevante, la variante estrella de 20 km no es construible a partir del diseño publicado; y eso es un hecho de cadena de suministro, no una crítica al proyecto.

Tampoco hay contenido normativo de ningún tipo: nada sobre autorización de espectro, ciclo de trabajo, límites de potencia o EMC para un transmisor de 160 W a 10,5 GHz. La página de Hackaday dice «Regulatory certification (FCC/CE) in progress»; el repositorio no dice nada. Para un sistema anunciado a desarrolladores de drones —el caso de uso es, literalmente, un radar de seguimiento de blancos—, la ausencia de cualquier orientación sobre dónde puedes radiar legalmente es lo primero que yo arreglaría.

Hallazgo 8: la capa de información alrededor del proyecto es peor que el proyecto

Hay tres artefactos que rodean este repositorio y los tres son más confiados que los archivos que describen.

Un «análisis profundo» generado por IA con nota 90/100. El 6 de mayo de 2026 el README añadió una insignia: Starlog — Deep Dive, enlazando a starlog.is/articles/data-knowledge/nawfalmotii79-plfm-radar. Starlog se presenta como «offsec tools & AI agents. Decoded», afirma rastrear 14.037.760 estrellas y 1.842 artículos, y publica reseñas generadas automáticamente y puntuadas —esta con 90/100, fechada el 7 de mayo de 2026, diciendo que el proyecto tiene «★ 19.5k». Su sección técnica menciona un DAC AD9172 (no está en el BOM; la placa lleva un AD9708AR), ADC AD9208 (la placa lleva un AD9484BCPZ-500), muestreo «hasta 250 MSPS» (el ADC corre a 400 MSPS con decimación de 4), «USB 3.0» (por defecto en producción es FT2232H sobre USB 2.0), un «cancelador de 3 pulsos» (el MTI del repo es de 2 pulsos, H(z) = 1 − z⁻¹) y una interfaz «PyQt5» (el repo distribuye una GUI en Tk y una reescritura en PyQt6). Un sistema de puntuación que otorga 90/100 a esto está puntuando la prosa, no el árbol de archivos. La insignia desapareció después del README, pero la página sigue siendo el primer resultado de búsqueda del proyecto, y es la versión de AERIS-10 que leerá la mayoría.

Una nota de agradecimiento congelada. El README todavía contiene una sección titulada «19,000 stars – Thank you», que explica que «Today, 19,000 engineers on GitHub have starred it». El repositorio tiene 25.759. Es una instantánea de hace seis meses presentada en presente.

Una línea de productos de electrónica de defensa. La sección de contacto del README firma «Nawfal Motii, ABAC INDUSTRY» con la URL de la empresa. ABAC INDUSTRY se describe como desarrolladora de «advanced radar systems, RF warfare solutions, secure communications and embedded technologies designed for modern defense and aerospace operations», desde una dirección en Casablanca, y vende una línea de productos que se solapa con el proyecto abierto incluso en el nombre: AERIS 10N (hasta 3 km), AERIS 10X (hasta 20 km), AERIS 10X CUSTOM («hasta 50 km… arquitectura AESA real en banda X (10,5 GHz), barrido electrónico completo ±45° en acimut y elevación»), más OCULUS F-AESA, sistemas de interferencia (jamming) de RF, analizadores de espectro para SIGINT y drones equipados con jammer, con una pregunta frecuente que se compara con los radares AESA chinos. Una fila de su tabla de productos dice «China AESA — 20+ KM».

Nada de eso es ilegal ni insólito: hardware abierto más un integrador comercial es un modelo de negocio legítimo, y CERN-OHL-P permite explícitamente vender Productos. Pero si colocas el «FIELD PROVEN / DEPLOYED INNOVATION» y el «we deliver a fully characterized system» del sitio junto al repositorio abierto, cuyo propio sitio de documentación declara como fase actual «Pre-Hardware Readiness», cuya guía de puesta en marcha avisa de que las incógnitas de integración «remain partially unproven until first assembly», y cuyo rastreador no puede establecer si alguna placa se ha encendido alguna vez… el contraste es el hallazgo. En agosto, ante la pregunta «¿hasta dónde llegó realmente la fabricación?», la mejor respuesta de alguien que no es el autor fue: «Lo siento, ni idea. A mí también me gustaría saberlo».

El plan de financiación colectiva del autor, en esa misma página de Hackaday, era «una campaña en el tercer trimestre de 2026, con primeras entregas a finales de 2026», con «pedido de la casa: Crowd Supply probablemente igualará los pedidos de los mecenas con su propia compra, duplicando la escala de producción» y «distribución vía Mouser tras la campaña». El tercer trimestre de 2026 terminó esta semana. No hay campaña. El último commit del repositorio fue el 17 de junio.

Lo que el proyecto hace bien

Quiero ser preciso aquí, porque buena parte de esta auditoría suena hostil y esa no es la conclusión correcta.

• Publicar los archivos completos de diseño de hardware es raro. Esquemáticos, Gerbers, posicionamiento, BOM, restricciones, testbenches: para un array en banda X de 10 capas, esto es más de lo que publica casi nadie. El trabajo de simulación de RF es real y está en scripts: wg_alumina_slotted_openems.m es un modelo FDTD de OpenEMS de verdad, con relleno de alúmina (εr 9,8, tanδ 1e-4), una comprobación de la frecuencia de corte TE10 y la derivación del desplazamiento de ranura según un taper de Kaiser. Es el archivo de un ingeniero, no un activo de marketing.
• La cultura de verificación es real. 348 commits, 23/23 suites de regresión de FPGA, 20/20 pruebas de host del MCU, 3/3 co-simulaciones con datos reales y 5.137 comprobaciones bit a bit, una línea base de temporización documentada (WNS +0,132 ns, DRC 0 errores) y una tabla de comparación entre builds. El análisis estático se aplica con 17 conjuntos de reglas de ruff elegidas con comentarios muy claros sobre código generado por LLM («stray print() calls — LLMs leave debug prints», «commented-out code — LLMs leave ‘alternatives’ as comments»).
• La política de IA es la mejor que he visto en este género. Preguntado directamente en la incidencia #106 sobre si se permitían contribuciones con IA, un responsable respondió con cuatro reglas: responsabilidad humana de cada commit, revisión obligatoria, CI completo antes de commitear y prohibición de commitear salida de IA sin leer. Se cumpla o no a la perfección, es la política correcta y está escrita.
• La arquitectura de seguridad está pensada. AGC híbrido entre FPGA/STM32/GUI, calibración de polarización en lazo cerrado canal a canal contra la Idq medida (16 amplificadores de sensado INA241A, 16 controles Vg DAC5578), 8 termistores con un GPIO de control de ventiladores, watchdog IWDG, corte de emergencia del riel de PA y la regla explícita de mantener las rutas de transmisión RF deshabilitadas en el primer encendido. Alguien pensó en qué ocurre cuando 160 W de GaN se comportan mal.
• El autor es sincero en público. «I just took a break and kind of stepped back from the project in order to rest up». «I’m trying to do the things the right way and it takes time». Es más honestidad de la que ofrece la mayoría de proyectos, y es la razón por la que me creo las partes de la documentación que dicen «pre-hardware».

Si estás pensando en construirlo

Según todo lo anterior, este es el orden de operaciones que yo seguiría.

1. No encargues el conjunto de 20 km. El diseño de su PA depende de un amplificador restringido a la exportación y su sustituto no está anunciado. Empieza por la configuración «N» de 3 km: placas principal, de alimentación y de síntesis, 1.303 $ de PCB desnudo con MOQ 2.
2. Resuelve primero la cuestión de la FPGA y cuenta con la XC7A100T-2FTG256I, el reemplazo verificado por la comunidad que encaja en el mismo encapsulado de 256 bolas. Pregúntalo en el rastreador, pero asume que la respuesta no llegará.
3. Genera tu propio BOM desde el .brd y vuelve a derivar cada valor de pasivo desde el número de referencia, no desde la columna de valor. Trata las hojas de cálculo como correspondencia, no como datos. Presupuesta sustituciones: el taller ya ha propuesto tres.
4. Verifica los Gerbers contra el esquemático con una reexportación CAM antes de pagar, porque el conjunto se armó con commits de borrado y resubida y nadie ha confirmado qué conjunto corresponde a qué esquemático.
5. Asume que los convertidores son el factor limitante (DAC y ADC de 8 bits) y planifica explícitamente tu presupuesto de ganancia de proceso: hay 42,8 dB disponibles con un chirp de 30 µs y 20 MHz e integración de 32 pulsos, y vas a necesitar casi todo.
6. Cuenta con una celda de distancia de 7,5 m y un techo de rango no ambiguo de unos 20,5 km; dimensiona tus expectativas por RCS, no por el titular.

Y si tu requisito es un radar funcionando este trimestre en lugar de una formación en hardware de banda X: este repositorio no es eso y, dado que su propia documentación dice «pre-hardware readiness», tampoco pretende serlo.

Preguntas frecuentes

¿AERIS-10 es un proyecto real o una invención? Es real e inusualmente abierto: esquemáticos, Gerbers, BOM, restricciones, testbenches y resultados de RF simulados, con un historial de 348 commits y una línea base de verificación documentada. Los problemas no son de autenticidad sino de completitud: el conjunto de archivos no ha convergido y no se ha publicado ningún dato medido.

¿Alguien ha construido y probado un AERIS-10? Nada en el registro público lo establece. La fase actual del sitio de documentación es «Pre-Hardware Readiness»; la guía de puesta en marcha habla de lo que está «unproven until first assembly»; en mayo el autor decía que las placas llegaban en días; en julio prometía subir los nuevos diseños «en 10 días»; en agosto quienes querían comprar preguntaron qué se había fabricado realmente y no recibieron respuesta suya. La única respuesta directa del rastreador, del colaborador con más experiencia: «Mis prototipos tardarán unas semanas más».

¿De dónde sale la cifra de 20 km? De la forma de onda: con una ventana de escucha de 137 µs, c × 137 µs / 2 = 20,54 km, el rango máximo no ambiguo. Es un techo de temporización y —para un blanco de 1 m² con los 42,8 dB completos de ganancia de proceso— también es aproximadamente alcanzable. Para un dron de 0,01 m² el mismo balance da unos 9 km.

¿Por qué dicen terceros que el firmware no cabe? Porque la línea base documentada (Build 25, 142 DSP48E1) y la FPGA de la placa (XC7A50T, 120 DSP48) pertenecen a configuraciones distintas, una de las cuales al parecer nunca existió como hardware. El fallo notificado es 129 DSP48 necesarios frente a 120 disponibles antes de la colocación, en la configuración de 3 km.

¿Puedo vender un producto basado en este diseño? CERN-OHL-P permite expresamente fabricar y vender; solo exige conservar los avisos y publicar las modificaciones del diseño bajo la misma licencia si distribuyes los archivos de diseño. Pero el texto de la licencia MIT prometida para el firmware no está en el repositorio: consigue esa cesión por escrito antes de depender de ella.

¿Qué debería leer antes que nada? La incidencia #186. Son cuatro preguntas de un futuro constructor, respondidas con detalle por otros dos ingenieros y nunca por el autor, y contiene más verdad de ingeniería sobre este proyecto que el README, el sitio de documentación y toda la cobertura de prensa juntos.

Cierre

AERIS-10 es el intento de un ingeniero en solitario de publicar un array en banda X, y que 25.759 personas le hayan dado una estrella dice mucho sobre cuánto desea el mundo que eso exista, no sobre si funciona. Los documentos del propio repositorio son la versión honesta: una FPGA que puede o no ser la 50T, un firmware que no cabe en ella, un BOM que se lee como un hilo de correo con el taller, «Pre-Hardware Readiness» como fase actual y unas cifras de alcance que resultan ser un límite de temporización y una suposición sobre la clase de blanco que nadie escribió en ninguna parte.

Frente a eso, lo que es real tiene valor de verdad: 894 archivos de trabajo de diseño, un modelo OpenEMS que puedes ejecutar, una disciplina de verificación que la mayoría del hardware abierto no alcanza y 42,8 dB de ganancia de proceso disponibles con un chirp de 30 µs si estás dispuesto a llevar tú la contabilidad. Los 20 km de la etiqueta son el techo de la forma de onda. Que eso decepcione o no depende por completo de lo que esperabas detectar, que es exactamente el número que nadie ha publicado.