AERIS-10: Inside the Open Source 10.5 GHz PLFM Phased Array Radar

What AERIS-10 Is and Who It Is Built For

AERIS-10 is a pulse Linear Frequency Modulated phased array radar running at 10.5 GHz, published as open hardware and open software. The README names three audiences: researchers, drone developers, and what it calls serious SDR enthusiasts. That list is honest about the level required. This is not a module you wire to a Raspberry Pi and query over SPI. It is a full radar: power management board, frequency synthesizer board, main board with FPGA and microcontroller, antenna array, and for the long-range version sixteen separate power amplifier boards.

The project ships in two configurations. AERIS-10N, also called Nexus, reaches 3 km with an 8x16 patch antenna array. AERIS-10E, also called Extended, reaches 20 km with a 32x16 dielectric-filled slotted waveguide array and adds the sixteen QPA2962 GaN amplifier boards at 10 W each. The same 10.5 GHz frequency and the same beam steering range of plus or minus 45 degrees in elevation and azimuth apply to both. The difference is antenna aperture and transmit power, which is exactly where the cost difference lives.

The stated goal is to let people experiment with beamforming, pulse compression, Doppler processing, and target tracking on real hardware. That is a narrower promise than it first appears. The value is in the signal chain being inspectable at every stage, from chirp generation through to CFAR detection, not in the radar being easy to operate.

The Signal Chain From Chirp to CFAR

The processing pipeline is split across three devices, and understanding the split explains most of the project's constraints.

Waveform generation starts at the DAC, which produces the LFM chirps. Two LTC5552 microwave mixers handle up-conversion on transmit and IF down-conversion on receive. Beam steering is done by four ADAR1000 four-channel phase shifters, which between them control sixteen elements, with sixteen ADTR1107 front end chips providing the low noise amplification on receive and power amplification on transmit.

Everything after the ADC lands on an XC7A50T FPGA. The README lists the stages in order: raw ADC capture, hybrid automatic gain control, I/Q baseband down-conversion, decimation, filtering, forward FFT, pulse compression, then Doppler, MTI and CFAR processing, and finally the USB interface to the host. The AGC loop is described as cross-layer, spanning FPGA, STM32 and GUI. That is an unusual design choice and worth noting: gain decisions are not confined to the FPGA, so tuning AGC behaviour means touching more than one codebase.

Timing is anchored by an AD9523-1 low jitter clock generator, which supplies phase-aligned references to the RX and TX synthesizers (ADF4382), the DAC, the ADC, and the FPGA. The STM32F746 microcontroller handles power-up and power-down sequencing, talks to the FPGA, configures the clock generator, synthesizers and phase shifters, and manages the GPS, IMU, barometer, stepper motor and RF switches. Thermal monitoring runs through an ADS7830 ADC reading eight thermistors, with a single GPIO named EN_DIS_COOLING switching the fans when any channel crosses the threshold.

Installing the Host Software and Running a First Cosim Check

The host software is a Python package named aeris-10-radar, and the repository root contains a pyproject.toml. That file requires Python 3.12 or newer and deliberately declares no runtime dependencies, with the comment that GUI dependencies are optional and listed in requirements_*.txt files for local installs. The development group lists ruff, pytest, numpy and h5py.

Because the runtime dependency list is empty, installing the package alone will not give you a working GUI. The pyproject.toml names the dev packages explicitly:

pip install ruff pytest numpy h5py

The pyproject.toml pins those dev packages as ruff>=0.5, pytest>=8, numpy>=1.26 and h5py>=3.10, so a version-constrained install is also possible:

pip install "ruff>=0.5" "pytest>=8" "numpy>=1.26" "h5py>=3.10"

Ruff is configured with a long and specific lint selection, and several of the rule comments explain why. The T20 rule rejects stray print() calls, ARG rejects unused arguments, ERA rejects commented-out code, and A rejects shadowing builtins. The comments state these were added because generated code tends to leave debug prints, unused parameters and commented alternatives behind. Running the linter is therefore a reasonable first check that your checkout is clean:

ruff check .

The pyproject.toml sets target-version to py312 and line-length to 100, so a clean run means the tree matches those settings. The README does not document a first hardware bring-up sequence, a device enumeration step, or a command that connects the GUI to a board, so treat the lint and test run as the only verifiable first use from the repository files. For the hardware side, the README points to the numbered directories: 3_Power Management for the sequencing spreadsheet, 4_Schematics and Boards Layout for the boards, and 9_Firmware for the firmware.

Where AERIS-10 Gets Hard: Bring-Up, Calibration and Alpha Status

The most concrete limitation is stated by the project itself. The README carries a Status badge reading Alpha and a Features badge reading Work in Progress. That is not modesty. A radar with sixteen transmit channels needs per-channel quiescent current calibration, and the README describes exactly that: two ADS7830 eight-channel I2C ADCs on the main board at addresses 0x48 and 0x4A measure Idq for sixteen PA channels, each sensed through a 5 mOhm shunt on the PA board and an INA241A3 current-sense amplifier with a gain of 50 on the main board. Two DAC5578 eight-channel I2C DACs at 0x48 and 0x49 set Vg for the same sixteen channels, and the README says this loop is closed and calibrated at boot to the target Idq.

That means a failed or interrupted boot can leave the array in an unknown bias state. The README does not document rollback, a recalibration procedure, or a safe-state recovery path. If you are evaluating this for anything beyond a bench, that gap matters more than any specification table.

The release history reinforces the same picture. The three most recent releases are v2.0.0-fft2048, described as a 2048-point FFT plus full timing closure; v2.0.1-reset-fanout, a 400 MHz reset fan-out fix plus ADAR1000 indexing; and v2.0.2-p0-audit, a pre-bringup audit closure plus FT2232H timing relaxation. A reset fan-out fix and a pre-bringup audit are not features. They are corrections to problems that would have prevented the board from working. Anyone building this should expect to be downstream of that class of issue.

How AERIS-10 Differs From a Commercial Radar Module

The obvious alternative is a commercial 24 GHz or 60 GHz radar module from an established sensor vendor, or a software defined radio paired with an external front end. The difference in approach is not price alone. It is where the abstraction boundary sits.

A commercial radar module hands you a detection list or a range-Doppler map over a documented interface, and the vendor owns the antenna, the RF layout, the calibration and the regulatory story. You cannot see the phase shifter settings, and you cannot change the waveform. AERIS-10 does the opposite. The schematics, PCB layouts, firmware and software are all in the repository, the phase shifters are addressable, the chirp comes from a DAC you control, and the FPGA pipeline stages are enumerated in the README. The cost of that openness is that you own the calibration, the bring-up, and the debugging.

Within the open source space, the more practical comparison is to a single-channel FMCW radar built from a development board. Those give you range and Doppler but no electronic beam steering, because steering requires a phase shifter per element and a calibration per element. AERIS-10's four ADAR1000 devices and sixteen ADTR1107 front ends are what buy the plus or minus 45 degree steering in both axes, and they are also what make the board expensive to assemble and slow to debug. If your experiment does not need beam steering, the phased array is cost you are paying for nothing.

Maintenance, Licensing and What the Repository Commits To

The last push to the default branch was on 2026-06-17, and the repository is not archived. The most recent tagged release, v2.0.2-p0-audit, dates from 2026-04-20. There is no published roadmap in the repository, and the README does not describe a support policy or a compatibility guarantee between firmware and host software versions.

Upgrade cost is therefore a real question rather than a formality. The release names show that changes have touched reset fan-out at 400 MHz, ADAR1000 indexing, and FT2232H timing. Those are changes to the FPGA and interface layer, not to the Python package. A host software upgrade and a bitstream upgrade are separate operations with separate risk, and the README does not document how to roll a bitstream back.

On licensing, the repository badges two different licences: MIT for software and CERN-OHL-P for hardware. The repository metadata reports the licence as NOASSERTION, which means the platform could not classify it automatically. The README also links to a Licence file at the repository root and the top-level entries include both Licence and CONTRIBUTING.md. If you intend to build and sell boards, read the actual licence files rather than the badges, and take your own advice on what CERN-OHL-P permits for your product. Nothing here is legal advice.

The practical maintenance signal is the pattern of release names. A project shipping audit closures and timing fixes is still stabilising its hardware, and you should plan to track its tags rather than build against main.

Editorial conclusion

Adopt AERIS-10 if you already work with RF hardware, can read the schematics, and want a documented 10.5 GHz phased array to experiment with beamforming and pulse compression rather than a finished product. Do not adopt it if you need a calibrated instrument, a supported SDK, or a radar that works without bring-up work: the repository marks itself Alpha, and the README does not document rollback, recalibration, or recovery from a failed power-up sequence. Before buying boards, verify the AERIS-10N versus AERIS-10E antenna choice against the range you need, confirm that the 16x QPA2962 amplifier boards are only part of the Extended version, and check the 3_Power Management sequencing file against the STM32F746 firmware in 9_Firmware, because that is the path that decides whether the array powers up in the right order.

Frequently asked questions

Official sources

1. Issues
2. NawfalMotii79/PLFM_RADAR on GitHub
3. README
4. Releases