[Question/Discussion] Beamforming Calibration Strategy & Phase Shifter Initialization Sequence

[Sombra-1]

Hi @NawfalMotii79 — incredible project, one of the most technically ambitious open-source radar builds I've seen on GitHub. A few questions that I think would benefit the whole community:

---

1. Beamforming Calibration

The system uses 4× ADAR1000 phase shifters for electronic beam steering. How are the phase shifter channels currently calibrated for manufacturing-level variations (gain/phase mismatch across channels)? Is there a calibration routine planned or already in the firmware, or is it assumed the antenna elements are closely matched enough to skip per-unit calibration?

---

2. ADAR1000 Initialization Order with the ADF4382 Synthesizers

In the STM32 power-up sequencing, is there a specific initialization order required between the ADF4382 synthesizers and the ADAR1000 phase shifters? I'm asking because if the LO is not stable before the phase shifters are loaded, early chirps could corrupt the Doppler FFT history. Is there a lock-detect gate in the firmware before the FPGA starts processing?

---

3. CFAR Threshold Tuning

For the on-board CFAR (Constant False Alarm Rate) detection — what window size and guard cells are currently being used in the FPGA implementation? Is it a CA-CFAR or OS-CFAR variant? This would be really useful for anyone trying to tune false-alarm rates for their specific clutter environment (e.g., urban vs. open field deployment).

---

4. Simulation / Bring-up Without Full Hardware

Is there a planned software-in-the-loop (SIL) or hardware-in-the-loop (HIL) test mode where someone could feed synthetic chirp data through the FPGA pipeline without having the full RF front-end assembled? This would massively lower the barrier for people (like students or SDR hobbyists) who want to contribute to the FPGA/DSP side before they can afford the full hardware BOM.

---

5. Power Budget for AERIS-10N

Any chance of sharing a rough power budget/consumption estimate for the AERIS-10N (Nexus) version? Total draw at the DC input would help people plan their portable/battery deployments.

---

These are the kinds of details that would make this a truly complete reference design. Happy to help document any of these if you can share the info. Thanks for open-sourcing this!

[JJassonn69]

@Sombra-1 Thank you for you interest in the project. I agree these are very useful information for anyone looking into the project. Since this is an active project most of the things are still being finalized. I will let @NawfalMotii79 chime in about the the specific details in the planned architecture.

[NawfalMotii79]

@Sombra-1 Thank you for the thoughtful questions and the kind words. You have identified several areas that deserve better documentation. Let me answer each one.

---

1. Beamforming Calibration

You are correct that manufacturing variations cause gain/phase mismatch across channels.

Current approach: The ADAR1000 channels are assumed to be sufficiently matched from the factory for proof-of-concept. No per-unit calibration routine is currently implemented.

Planned approach: I intend to add a calibration routine that uses a near-field probe and a known reference signal. The firmware will measure phase and gain differences across all 16 channels and store correction coefficients in EEPROM. This is targeted for the production firmware (post-Crowd Supply).

Community help: If you have experience with calibration algorithms, I would welcome a pull request.

---

2. ADAR1000 Initialization Order with ADF4382 Synthesizers

Your concern is valid. Early chirps with unstable LO corrupt Doppler history.

Current implementation: The power-up sequence is:

• ADF4382 initialization and lock detection
• Wait for lock (LED indicators confirm lock)
• Then ADAR1000 initialization and phase loading
• FPGA is held in reset until after LO lock is confirmed

Lock-detect gate: Yes. The STM32 reads the lock detect pins (ADF4382_TX_LKDET, ADF4382_RX_LKDET) before releasing the FPGA from reset. The FPGA will not begin processing until the STM32 asserts the ready signal.

Code reference: See main.cpp lines approximately 800-900 for the lock detection loop.

---

3. CFAR Threshold Tuning

Current implementation: The FPGA uses a CA-CFAR (Cell-Averaging CFAR) variant.

Parameter	Value
Window size	32 range bins
Guard cells	4 on each side (8 total)
Threshold factor	Configurable via GUI (default 12 dB)
Reference cells	32 – 8 = 24 reference cells averaged

Limitation: OS-CFAR is not implemented. The current CA-CFAR works well for uniform clutter (open field, rural). For urban environments with non-uniform clutter, false alarm rates increase.

Planned improvement: OS-CFAR or a simple adaptive threshold multiplier based on local variance. Community contributions welcome.

---

4. Simulation / Bring-up Without Full Hardware

This is an excellent suggestion. Currently, there is no SIL or HIL mode.

What exists: Raw I/Q data can be captured via USB 3.0 and processed offline in MATLAB/Python. The FPGA pipeline can be simulated in Vivado using testbench with synthetic I/Q data.

What is missing: A simple "loopback mode" where the FPGA generates synthetic targets and processes them through the full pipeline without RF hardware.

Proposal: I can add a compile-time flag SYNTHETIC_MODE that bypasses the ADC and injects synthetic chirp echoes. This would allow FPGA/DSP development without any RF hardware.

Would this meet your needs? I can prioritize this if there is community interest.

---

5. Power Budget for AERIS-10N

Please check: 3_Power Management/Power Management V6.xlsx

---

Summary

Question	Status	Next Step
Beamforming calibration	Planned	Post-Crowd Supply
LO lock sequencing	Implemented	Documented above
CFAR details	CA-CFAR	OS-CFAR planned
SIL/HIL mode	Not implemented	Could add with community input
Power budget	Provided	See corresponding file

---

Thank you again for these questions. They will help me improve the documentation significantly. If you are interested in contributing any of these areas (especially calibration or synthetic mode), please open an issue or pull request.

Best regards,

Nawfal Motii
ABAC INDUSTRY

[jpaj77062-glitch]

@NawfalMotii79 can you clarify the calibration planned approach slightly? Would the calibration route be a physical addition to the board design, or something in the production plan?

Just confused if you are planning on doing a one-time cal at the production of the product, or allow for a in-field self-cal. I haven't worked with a lot phase arrays before, so I dont know what is standard.

[NawfalMotii79]

Beamforming Calibration for AERIS-10

Overview

The AERIS-10 uses 4 ADAR1000 phase shifters controlling 16 channels total (4 channels per device). Due to manufacturing variations, temperature drift, and PCB layout differences, the phase and gain responses vary across channels. Without calibration, these mismatches cause:

• Beam pointing errors
• Increased sidelobe levels
• Reduced gain in the steered direction
• Poor null steering performance for anti-jamming

This document describes the calibration procedure to measure and correct these mismatches.

---

Calibration Philosophy

Approach	Description
Factory calibration	Performed once during manufacturing. Measures per-unit phase/gain errors. Stored in EEPROM.
Temperature calibration	Measures phase drift vs. temperature. Applied during operation based on temperature sensor readings.
Field calibration	Optional user-initiated calibration using a corner reflector or known target.

---

Required Equipment

Equipment	Specification	Purpose
Near-field probe	X-band open-ended waveguide or small horn	Measures phase/gain at each element
Signal generator	10.5 GHz continuous wave (CW)	Provides reference signal
Spectrum analyzer or VNA	X-band capable	Measures amplitude and phase
Positioner (optional)	Manual or automated scanning	Moves probe across array
Thermal chamber	-40°C to +85°C	Temperature characterization

Alternative (simpler): Use a far-field corner reflector and measure beam patterns instead of per-element near-field scanning. This is less precise but requires only a known target at a known distance.

---

Calibration Procedure

Step 1: Baseline Measurement (No Phase Shift)

Set all phase shifters to 0° (broadside). Transmit a CW signal from the array. Measure the combined far-field pattern or use a near-field probe to sample each element.

Goal: Establish the inherent amplitude and phase offsets of each channel.

Step 2: Per-Element Phase Sweep

For each channel (1 to 16):

1. Set the channel to a known phase value (e.g., 0°)
2. Measure the received amplitude and phase at the probe
3. Sweep the phase from 0° to 360° in 22.5° steps (16 steps)
4. Record the measured phase vs. commanded phase

Expected result: A linear relationship with some offset (phase error) and possibly non-linearity.

Phase error calculation:
Phase_error(channel, commanded) = Measured_phase - Commanded_phase - Reference_offset

Step 3: Per-Element Gain Measurement

For each channel:

1. Set phase to 0°
2. Measure received amplitude at the probe
3. Compare to the average amplitude across all channels

Gain error calculation (dB):
Gain_error(channel) = 20 * log10(Measured_amplitude(channel) / Average_amplitude)

Step 4: Temperature Characterization

Place the array in a thermal chamber. Repeat the phase and gain measurements at:

Temperature	Purpose
-40°C	Cold extreme
0°C	Cold typical
+25°C	Room temperature (baseline)
+50°C	Hot typical
+85°C	Hot extreme

For each temperature, measure the phase offset relative to the +25°C baseline.

Temperature coefficient calculation:
Phase_temp_coeff(channel) = (Phase_error(T2) - Phase_error(T1)) / (T2 - T1)

Typical units: degrees per °C.

---

Calibration Data Structure

Store the following in EEPROM:

struct CalibrationData {
    uint8_t version;              // Calibration format version
    uint32_t timestamp;           // Unix timestamp of calibration
    
    // Per-channel gain correction (dB)
    float gain_correction[16];
    
    // Per-channel phase correction at 25°C (degrees)
    float phase_correction_25C[16];
    
    // Per-channel temperature coefficient (degrees/°C)
    float phase_temp_coeff[16];
    
    // Checksum for integrity
    uint32_t checksum;
};

Real-Time Correction
During operation, the STM32 applies calibration as follows:

Phase Correction
For a desired steering phase desired_phase(channel):

corrected_phase = desired_phase(channel)
+ phase_correction_25C[channel]
+ phase_temp_coeff[channel] * (current_temp - 25);

Then quantize to the ADAR1000's 7-bit resolution (0-127, where 128 = 360°):

phase_code = (uint8_t)((corrected_phase / 360.0) * 128) % 128;

Gain Correction
The ADAR1000 has a VGA with 0.5 dB steps. Apply gain correction by adjusting the VGA setting:

vga_setting = default_vga_setting + (int)(gain_correction[channel] / 0.5);

Clamp to valid range (0-31, corresponding to 0-15.5 dB gain).

Simplified Far-Field Method (No Probe)
If you do not have a near-field probe, use this simpler method.

Equipment
Corner reflector (0.1-0.5 m² RCS)

Known distance (e.g., 50-100 meters)

Clear line-of-sight

Procedure
Place the corner reflector at a known bearing (e.g., 0° azimuth)

Measure received power as you steer the beam across angles

Compare the measured beam pattern to the ideal theoretical pattern

Adjust phase corrections iteratively to minimize beam pointing error and sidelobe levels

This method is less precise but requires no special RF test equipment beyond the radar itself.

// Calibration data loaded from EEPROM at startup
CalibrationData cal;

// Apply calibration to a desired phase
uint8_t applyPhaseCalibration(uint8_t channel, float desired_phase_deg, float current_temp_c) {
    // Add static correction
    float corrected = desired_phase_deg + cal.phase_correction_25C[channel];
    
    // Add temperature correction
    corrected += cal.phase_temp_coeff[channel] * (current_temp_c - 25.0f);
    
    // Normalize to 0-360
    while (corrected < 0) corrected += 360.0f;
    while (corrected >= 360.0f) corrected -= 360.0f;
    
    // Convert to 7-bit code (0-127, where 128 = 360°)
    uint8_t phase_code = (uint8_t)((corrected / 360.0f) * 128.0f) % 128;
    
    return phase_code;
}

// Apply gain calibration
uint8_t applyGainCalibration(uint8_t channel, uint8_t desired_vga_setting) {
    int corrected = desired_vga_setting + (int)(cal.gain_correction[channel] / 0.5f);
    
    // Clamp to valid range (0-31)
    if (corrected < 0) corrected = 0;
    if (corrected > 31) corrected = 31;
    
    return (uint8_t)corrected;
}

When to Recalibrate

Event	Action
Factory production	Full calibration (phase + gain + temperature)
Annual maintenance	Spot-check with far-field method
After repair or modification	Full recalibration required
User-initiated	Optional field calibration using corner reflector

Expected Results After Calibration

Parameter	Uncalibrated	Calibrated
Beam pointing error	±2° to ±5°	<0.5°
Peak sidelobe level	-10 to -12 dB	-13 dB (theoretical)
Gain variation across channels	±2 dB	<0.5 dB
Phase variation across channels	±20°	<5°

Future Improvements

Automatic calibration routine where the FPGA generates test signal; STM32 measures and adjusts

Temperature compensation table with Non-linear correction for extreme temperatures

Calibration GUI – A Python tool to walk users through the calibration process

Temperature characterization data – If you have access to a thermal chamber, please share results

Alternative calibration methods – Phase retrieval without a probe (e.g., rotating element electric vector (REV) method)

[jpaj77062-glitch]

Nice, that reads like a solid plan. I will review what I have learned on phased array calibrations, but I am thinking a little bit about the physical implementation of this.

I am going to review the BOM though for DFT issues, just incase some of the components aren't specified for the range provided.

However, it would also be worth noting in the initial review of the temperature data what the delta between the external temperature (I assume you are referencing the ambient area outside of the DUT for the temperature calibration) and the internal "dead" air temperature of the DUT, as that might also affect DFT and product reliability, since the difference might put a device into a temperature its not rated for. This would really only affect the upper margins of the temperature range, as it should be warmer than the ambient.

Also, where is the sensor you are using to measure the temperature in-field placed? Sorry I haven't been able to look at the physical layout yet, and I am kinda throwing this out there, but if the sensor is inside the enclosure, will it matter if there is an offset between what it reads and the outside ambient? I would think so, and as such does there need to be a coefficient for the temperature offset between the ambient and the sensor?

[Sombra-1]

Great discussion; a few follow-up thoughts across three areas:

---

1. Temperature Sensor Offset — Responding to @jpaj77062-glitch

This is a valid and important point. The thermistors in the AERIS-10 are placed on the Main Board (as mentioned in the README: U10 reads 8 thermistors for thermal monitoring). Since these are board-mounted sensors inside the enclosure, they measure PCB/junction-adjacent temperature, not external ambient.

The good news: for phase calibration purposes, this is actually preferable. The ADAR1000 phase drift is driven by its own junction temperature, not the outside air. So calibrating the phase correction against the board thermistor reading (as applyPhaseCalibration() already does via current_temp_c) is the right approach — no external ambient sensor needed.

However, @jpaj77062-glitch raises a real concern for component reliability (not calibration accuracy). At high ambient temperatures, the internal enclosure temperature will be higher than ambient due to self-heating. This means:

• At +85°C ambient, internal board temp could exceed component ratings if thermal management is insufficient
• • The cooling fans (controlled by EN_DIS_COOLING) help, but a worst-case thermal budget should be documented
    Suggested action: Add a note in the calibration doc clarifying that current_temp_c should always use the thermistor nearest the ADAR1000 devices — not a barometer or external GPS module reading. This avoids any future ambiguity in the firmware.

---

2. SYNTHETIC_MODE — API Proposal

@NawfalMotii79 proposed a compile-time SYNTHETIC_MODE flag. Here is a suggested minimal API for what that mode should expose to be useful for FPGA/DSP contributors:

// Synthetic target parameters (configurable via UART or hardcoded at compile time)
typedef struct {
    float range_m;         // Target range in meters (e.g., 500.0)
    float radial_vel_mps;  // Radial velocity in m/s (positive = approaching)
    float rcs_dbsm;        // Radar cross section in dBsm (e.g., 10.0 for car)
    float azimuth_deg;     // Target azimuth angle in degrees
    float snr_db;          // Desired SNR at ADC input (controls injected noise floor)
} SyntheticTarget;

The FPGA would generate a delayed, Doppler-shifted version of the transmitted chirp, scaled by RCS and range law (R^4), and inject it directly at the ADC input stage bypass point. This lets contributors test the full pipeline — pulse compression, Doppler FFT, MTI, CFAR — without any RF hardware.

A secondary benefit: this would make regression testing much easier, since expected detection outputs for a known synthetic target can be pre-computed and compared automatically in CI.

---

3. BOM Temperature Range — Items Worth Checking

Following up on @jpaj77062-glitch's BOM review suggestion, a few components worth specifically verifying for the -40°C to +85°C range:

• ADAR1000 — rated -40°C to +85°C (junction), but verify PCB thermal pad connection for adequate heat sinking
• • ADF4382 — check PLL lock time and phase noise specs at temperature extremes; lock acquisition time can increase significantly at cold
• • • QPA2962 GaN PA (AERIS-10E only) — gate bias voltage (Vg via DAC5578) will need temperature-compensated Idq targeting since GaN Vth shifts with temperature
• • • • AD9523-1 clock generator — verify phase noise and output specs at -40°C; clock jitter budgets are often tighter than expected at cold extremes
        Happy to help cross-reference the BOM against datasheets if the component list from 4_Schematics and Boards Layout/4_7_Production Files is accessible.

[hcm444]

"Happy to help cross-reference the BOM against datasheets if the component list from 4_Schematics and Boards Layout/4_7_Production Files is accessible."

You are an AI developer correct? Do you have experience in radar engineering?

[jpaj77062-glitch]

@NawfalMotii79 I noticed in your write up that you utilize the sensor readout for the calibration value, but you want to normalize the current temperature to 25C, while implying the ambient is at 25C. I couldn't find where this code in the repository, so I couldn't verify if I am just missing something.

In my experience, the sensors will read hotter than the ambient. For a 40W 2x2 small cell, there was a 15C increase between the ambient and the internal temperature within the RU. I think you should provide a temperature calibration point instead of a static 25C for the phase calibration, as the data I referenced was not the sensor, which might be different from each sensor.

corrected += cal.phase_temp_coeff[channel] * (current_temp_c - 25.0f); -->
corrected += cal.phase_temp_coeff[channel] * (current_temp_c - ambient_cal_temp);

With ambient_cal_temp being added to the CalibrationData struct. I can create another PR for this, but once again, I didn't find where in the repository this CalibraitonData struct or applyPhaseCalibration function is. If it is in the repository, let me know, as it likely means I missed something when setting it up.

[NawfalMotii79]

@jpaj77062-glitch The calibration process would be added once we receive the new PCBs, since we need to merge the phase calibration routines with the RF PA temperatures and the cooling system control.