Minimizing LO leakage on bladeRF 2.0 micro (xA4) during IQ replay
Posted: Mon Sep 01, 2025 9:43 pm
I am working on a record–replay setup with a bladeRF 2.0 micro (xA4), and I consistently observe a strong spike at the LO (carrier) frequency during TX. Below is a summary of my setup, experiments, and observations. I’d like advice on best practices to suppress LO leakage when replaying wideband IQ data.
Setup
Device: bladeRF 2.0 micro xA4
TX conditions: ~1000 MHz, 10 MS/s sample rate, 10–40 dB RF gain
Workflow: IQ recorded from another module → replayed via Soapy Sink → bladeRF
Spectrum observed on an external R&S analyzer
Observations
LO spur always present
A prominent spike appears at the LO during every transmit scenario.
Single-tone tests (complex sine at 100 kHz baseband) -> Analyzer shows the expected tone at LO+100 kHz.
A second spur appears exactly at the LO (consistent with LO leakage).
Using int16 → Complex
Increasing RF gain boosts LO and baseband.
Example: 20 dB gain → LO +3 dB; 40 dB gain → LO +23 dB.
Driving TX with int16-based signal sources (IShortToComplex) produces the same LO spur.
Adjusting the amplitude of the single-tone input reflects in the intended tone at twice the set frequency but also at the LO spur.
Recorded IQ replay (Core Application)
When transmitting captured/modulated IQ data from file, the LO spur often dominates, making the spectrum look like “just LO and nothing else.”
During recording (RX side, QT GUI spectrum), this LO spike is not visible.
Higher-order tones
In some tests, additional tones observed at 2×f_tone.
Mitigations tried
cal dc rx before capture (cal dc tx not supported on bladeRF 2.0 micro).
Python preprocessing: subtracting mean from captured IQ.
Enabling tx_dc_offset=true, tx_iq_balance=true in Soapy device args.
Lowering TX gain.
All of the above reduce the spur slightly, but LO leakage remains significant compared to the desired signal.
Questions
Are there calibration routines or register-level settings (beyond cal dc rx + Soapy args) to further reduce LO leakage on bladeRF 2.0 micro?
Is the observed LO spur level fundamentally limited by the LMS7002M’s zero-IF architecture, or can it be substantially improved?
Any recommended workflows for minimizing LO leakage when replaying wideband modulated IQ data from file?
Setup
Device: bladeRF 2.0 micro xA4
TX conditions: ~1000 MHz, 10 MS/s sample rate, 10–40 dB RF gain
Workflow: IQ recorded from another module → replayed via Soapy Sink → bladeRF
Spectrum observed on an external R&S analyzer
Observations
LO spur always present
A prominent spike appears at the LO during every transmit scenario.
Single-tone tests (complex sine at 100 kHz baseband) -> Analyzer shows the expected tone at LO+100 kHz.
A second spur appears exactly at the LO (consistent with LO leakage).
Using int16 → Complex
Increasing RF gain boosts LO and baseband.
Example: 20 dB gain → LO +3 dB; 40 dB gain → LO +23 dB.
Driving TX with int16-based signal sources (IShortToComplex) produces the same LO spur.
Adjusting the amplitude of the single-tone input reflects in the intended tone at twice the set frequency but also at the LO spur.
Recorded IQ replay (Core Application)
When transmitting captured/modulated IQ data from file, the LO spur often dominates, making the spectrum look like “just LO and nothing else.”
During recording (RX side, QT GUI spectrum), this LO spike is not visible.
Higher-order tones
In some tests, additional tones observed at 2×f_tone.
Mitigations tried
cal dc rx before capture (cal dc tx not supported on bladeRF 2.0 micro).
Python preprocessing: subtracting mean from captured IQ.
Enabling tx_dc_offset=true, tx_iq_balance=true in Soapy device args.
Lowering TX gain.
All of the above reduce the spur slightly, but LO leakage remains significant compared to the desired signal.
Questions
Are there calibration routines or register-level settings (beyond cal dc rx + Soapy args) to further reduce LO leakage on bladeRF 2.0 micro?
Is the observed LO spur level fundamentally limited by the LMS7002M’s zero-IF architecture, or can it be substantially improved?
Any recommended workflows for minimizing LO leakage when replaying wideband modulated IQ data from file?