PLFM_RADAR picked up 145 GitHub stars today. Its own engineering site still labels the AERIS-10 project as "Pre-Hardware Readiness." The repository has enough detail to manufacture boards and inspect the signal-processing code, but its maintainers have not yet published the first physical bring-up described in their current readiness package. Ordering boards now means joining the bring-up effort before a verified machine exists.
The attention is substantial. GitHub currently shows about 25,600 stars, 5,900 forks, 348 commits, eight open issues, and seven pull requests. Those figures make AERIS-10 unusually visible for an RF hardware project. They measure interest and participation, though. They do not measure antenna performance, detection range, or whether the assembled system survives first power-on.
What the repository gives builders
AERIS-10 is presented as a 10.5 GHz pulse linear frequency modulated phased-array radar. The main repository includes schematics, PCB layouts, bills of materials, Gerber and manufacturing files, FPGA logic, STM32 firmware, a Python interface, simulations, mechanical drawings, and component documentation. The README also says there is no standalone assembly guide in the tracked tree, so builders must work from the schematics and production outputs. That is a meaningful amount of source material, but it assumes experience with PCB assembly, RF systems, and AMD's Vivado tools.
The published specifications describe two versions. The AERIS-10N uses an 8 by 16 patch array, about 1 watt across each of 16 transmit channels, and a claimed maximum range of 3 kilometres. The AERIS-10X uses a 32 by 16 slotted-waveguide array and 16 ten-watt GaN amplifier channels, with a claimed 20-kilometre maximum. Both designs call for electronic steering across plus or minus 45 degrees and a stepper motor for a full mechanical sweep. These are design targets published by the project, rather than results verified by an independent field test.
The design's component map explains why this is more involved than a software-defined radio tutorial. It uses an AD9523-1 clock generator, ADF4382 frequency synthesizers, LTC5552 mixers, ADAR1000 beamformer chips, and ADTR1107 front ends. An Artix-7 FPGA is assigned chirp generation, I/Q down-conversion, filtering, pulse compression, Doppler processing, moving-target indication, and constant false-alarm-rate detection. An STM32F746 handles power sequencing and peripheral control. Our review of PLFM_RADAR covers the setup reality for readers deciding whether the repository matches their bench and skills.
Pulse compression is central to the proposed system. The transmitter sends a pulse whose frequency changes through the chirp, then the FPGA's matched filter compresses the returned signal in time to separate range bins. The processing chain compares chirps to estimate Doppler, suppresses stationary clutter with a two-pulse moving-target canceller, and applies a locally adjusted CFAR threshold before reporting detections. The Build 25 implementation notes say the design processes 32 chirps per frame and 64 range bins. Each step can pass a simulation while the full chain still fails because of noise, timing, RF coupling, or calibration on the assembled boards.
The digital work is unusually inspectable
The repository is strongest where normal software verification applies. Its implementation log calls Build 25 the current production baseline for the FPGA design. It reports positive setup and hold margins, 9,252 lookup tables, 17 block RAM units, 142 DSP slices, and estimated power of 0.753 watts. The same log records 23 passing FPGA regression suites, 29 standalone moving-target-indicator checks, and three exact matches in a real-data co-simulation. Those results are reported by the project and concern the digital design, not a complete radar operating over the air.
A separate April release shows how specific the work has become. Version 2.0.2-p0-audit corrected an FT2232H output-delay constraint that had been overstated by roughly eight nanoseconds, added minimum timing constraints so hold time was analysed, and removed an STM32 control path that could bias the power amplifier and low-noise amplifier together. The published build reported zero failing timing endpoints. It also used 112 of the target FPGA's 120 DSP blocks, leaving far less room there than its lookup-table count might suggest.
That level of disclosure gives another engineer something concrete to challenge. A failed timing build remains in the log alongside the fix, and the current bring-up plan names the expected evidence for each gate. The project also separates its licensing: hardware files use CERN Open Hardware Licence Version 2 Permissive, while the firmware, FPGA code, and Python tools use MIT terms. The README spells out that split, including the obligation to distribute modified hardware designs in source form under the same hardware licence.
The repository says where proof stops
The most important document is the project's hardware bring-up plan. It describes checks to run before the first FPGA module and carrier board arrive, then lays out the board-day sequence. The operator is supposed to inspect power defaults, start with RF transmission disabled, record current draw, verify JTAG programming and reset behaviour, and bring up the clock and local-oscillator chain before testing the data path. Power-amplifier bias and higher-risk RF operation come only after those checks pass.
The same plan lists unresolved risks in unusually plain terms. Local-oscillator synchronisation, phase behaviour, and beamformer control still need physical validation. The active FPGA design passes its regressions, yet some radar functions still need confirmation with real I/O. Power-amplifier calibration has not been proven on devices, and the carrier, rails, clocks, and connectors retain integration unknowns until the first assembly is tested. These are ordinary risks for complex hardware. Their presence means the 3-kilometre and 20-kilometre range figures should remain labelled as project claims.
The abort criteria are equally revealing. Engineers are told to stop for unexpected rail current, unstable regulators, abnormal temperature rise, failed beamformer readback, or inconsistent USB framing. If clock presence or reset sequencing is ambiguous, the plan calls for falling back to a minimal heartbeat image. This is careful preparation for hardware that may expose faults simulation cannot see, from power integrity trouble to phase errors in the RF chain.
Why 145 new stars still tell us something
A GitHub star cannot validate a microwave front end, but the day's 145-star increase points to demand for open RF engineering material. Most developers can download a database or an editor and judge it in minutes. A 10.5 GHz phased array asks for fabricated boards, specialised components, suitable measurement equipment, and permission to transmit under the rules that apply where it is operated. The repository's prerequisites start with radar knowledge and PCB assembly experience, which places it well outside a casual weekend build.
The appeal lies in access to the unfinished engineering record. The repository exposes production files and source code, then adds timing reports, known risks, test expectations, and a printable board-day worksheet. That lets an RF engineer review a clock tree, an FPGA developer inspect the CFAR implementation, or a lab plan a replication before buying parts. The project's own checklist should also make faults easier to locate and discuss in public when an assembled system reaches the bench.
The next evidence should come from the bench. Watch for logged supply currents, clock and synthesizer lock results, phase-shifter readbacks, raw ADC captures, and measured antenna data from the first assembly. After that, repeatable target tracks and an independent build would give the range claims a firmer basis. Until those artifacts appear in the bring-up record, AERIS-10 is best understood as an unusually detailed open radar design awaiting its hardest test: turning the boards on.